Brokers

The broker is the only component that can use your provider credentials. It runs where you choose (a server, a VM, a container, a laptop) and is the security boundary agents cross.

What a broker does

• Generates and holds the custody keypair. Credentials are sealed to its public key; only its private key opens them.
• Pulls policies, sealed credentials and identity settings from the control plane, and polls emergency state every 5 seconds.
• Serves the agent API (/v1/actions, /v1/authorize) and published endpoints (/e/{id}).
• Pushes one audit record per request.

The custody key

New keys use a hybrid post-quantum scheme: X25519 combined with ML-KEM-768 (NIST FIPS 203) through HKDF-SHA256, with AES-256-GCM. A sealed credential stays confidential as long as either primitive holds, which protects stored ciphertext against "harvest now, decrypt later". Older X25519-only keys keep working.

./pastkeys keygen --out custody.key       # new hybrid key
./pastkeys custody rotate                 # add a new key, keep the old one for opening

Rotation is lazy: credentials sealed to the previous key are re-sealed to the new one the next time they are used. Keep the key file readable only by the broker's user; the broker refuses an insecure key file unless BROKER_ALLOW_INSECURE_KEY_PERMS=1.

Status

The dashboard shows a broker as online when it has called the control plane in the last 3 minutes. ./pastkeys doctor reports platform, mode, identity, custody key, providers and break-glass state, and exits non-zero on a security problem.

Running in production

• Bind to a private address (--addr 127.0.0.1:8080) or put it behind your network controls.
• Run it under a service manager as an unprivileged user, with the custody key outside version control.
• Set BROKER_NAME to label it in the dashboard, and BROKER_LOCKDOWN_FILE to arm the local kill switch.