How it works

Every agent request passes through the same fail-closed pipeline inside the broker. The agent sends an intent; the broker decides, acts, and records. A provider credential is used only inside the broker and never returned.

The request lifecycle

1. Authenticate. Verify the agent's identity: a workload-identity JWT or an agent token. Single-use platform tokens are replay-protected.
2. Lockdown check. If the account or this broker is in lockdown, refuse.
3. Guardrails. Account-wide deny rules (policy agent *) refuse matching operations for every agent.
4. Policy. The agent's default-deny policy must explicitly allow the provider, resource and action, with any constraints satisfied.
5. Break-glass grant. Only if the policy denied, an active emergency grant may allow it.
6. Approval. If the rule requires it, the request waits for a human decision.
7. Quota. The plan's agent and monthly operation limits are enforced.
8. Credential. The broker opens the sealed root credential and, where the provider supports it, mints a scoped, short-lived one for this operation.
9. Execute. The operation runs against the provider with a deadline.
10. Audit. Exactly one secret-free record is written, whatever the outcome.

Deployment modes

Mode	Set with	Use it for
Control-plane (API) mode	BROKER_CONTROLPLANE_URL + BROKER_TOKEN	The normal setup: a broker in your environment managed from the dashboard
Database mode	BROKER_DB_DSN + BROKER_ACCOUNT_ID	A broker co-located with a self-hosted control plane
Local mode	neither	Development: policies from files, memory or file audit

What the control plane can and cannot see

Can see	Cannot see
Which providers you configured, your policies, agent IDs, audit records, broker public keys	Any provider token: we store only sealed ciphertext and hold no key that opens it

See the zero-access model for how that boundary is enforced by cryptography rather than policy.