Credential broker & modes

When the data plane routes a call to a backend, it needs a credential. The credential broker resolves one at the edge based on policy and the bound credential — and the secret never leaves the broker. It is not returned to the agent and never appears in logs, fixtures, or audit events.

The five credential modes

Mode	Who the call authenticates as
none	No credential — the upstream is open or handles auth itself.
service_account	A shared service identity owned by the server.
user_delegated	The end user, via delegated OAuth — the agent acts as the human.
agent_scoped	A credential scoped to the specific agent.
workload_mapped	A workload identity mapped to the upstream.

Policy decides which mode is allowed for a given principal, tool, and context — so the same tool can require user_delegated from an external surface but allow service_account internally.

Credential bindings

A credential binding ties a credential (referenced in a secret manager, never inlined) to a server or operation under a mode. Bindings move through approval, and support rotate, disable, and revoke — each an auditable transition. See Create a credential binding.

Secrets never transit the boundary

The broker resolves secrets from a Vault‑compatible source and injects them into the upstream call only. Nothing secret crosses back to the agent or into audit — audit records the mode that was used, not the value.

See it illustrated See the credential broker resolve a secret at the edge — without it ever reaching the agent — illustrated.