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	One registered agent named by the binding’s immutable agentSubject.
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.

For agent_scoped, select an approved agent when you create the binding. The gateway reads the agent and optional instance only from signed token claims, checks registry status, surface, environment, and instance rules, then requires an exact match with agentSubject. A person signing in without a signed agent identity uses user_delegated. Read Agent-scoped credentials for the customer model, runtime sequence, enforcement outcomes, and incident boundary.

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.