Identity, Authorization & Agentic Payments
An agent acts. The moment it does, three questions become unavoidable: who is acting, what are they allowed to do, and — increasingly — how do they pay? Human identity systems assume a person at a keyboard; agents break that assumption. They are autonomous, numerous, and act on behalf of users and of each other. Getting identity and authorization right is the foundation of every other trust guarantee in the platform.
15.1 Workload identity: every agent is a verifiable principal
An API key in an environment variable is not an identity — it is a bearer secret that anything holding it can replay, with no cryptographic proof of who is calling and no easy rotation. At platform scale, with many agents and services calling one another, you need each workload to prove what it is. SPIFFE (Secure Production Identity Framework for Everyone) defines a standard verifiable identity — the SPIFFE ID, e.g. spiffe://platform/agent/refund-bot — issued as a short-lived, automatically rotated cryptographic document (an SVID, typically an X.509 cert or JWT). SPIRE is its reference implementation, which attests workloads and issues these identities without long-lived secrets. The payoff: mutual TLS between services, fine-grained policy keyed to real identities, and no static credentials to leak.
15.2 Authorization and the confused-deputy problem
Identity answers who; authorization answers what they may do. The subtlety with agents is that an agent almost always acts on behalf of a user — and it must act with that user's permissions, never with its own broader ones. An agent that holds powerful credentials and is tricked (by prompt injection, Ch. 16) into misusing them on an attacker's behalf is a classic confused deputy: a privileged intermediary fooled into exercising its privilege for someone else. The defense is delegated, scoped authority: the user delegates a narrow, time-bounded permission to the agent — via OAuth 2.0 flows and token exchange (RFC 8693) — so the agent's downstream calls carry the user's identity and exactly their scope, not a god-mode service token.
An agent should never hold standing power broader than the task in front of it. Give each workload a verifiable identity (SPIFFE), and have it act with the delegated, scoped, expiring authority of the user it serves — never with ambient super-credentials. The blast radius of any compromise is then bounded by that scope.
15.3 Agentic payments
As agents begin to transact — buying data, calling paid APIs, settling between themselves — they need a way to pay that doesn't involve handing a model your credit-card number. An emerging pattern revives HTTP 402 Payment Required: the x402 protocol lets a server respond to a request with a 402 and payment terms, the agent pays programmatically (typically a stablecoin transfer), and the request succeeds — enabling pay-per-call and machine-to-machine micropayments without accounts or human checkout. The architectural requirement is the same as everywhere in this chapter: payments are a high-consequence action, gated by scoped authority, hard budget ceilings (Ch. 20), and — for anything material — human approval (Ch. 5). Autonomy over money demands the tightest controls in the platform.
An agent that can pay can, in a loop or under injection, pay repeatedly and ruinously. Never grant payment capability without a per-run and per-period budget enforced outside the model's control, idempotent settlement (Ch. 4) so retries don't double-pay, and approval gates above a threshold. The model proposes a payment; the platform decides whether it happens.
15.4 Secrets and credential management
Identity (§15.1) proves who a workload is; it does not hold the API keys, database passwords, and provider tokens the workload still needs at runtime. Those secrets are a distinct concern, and the rule is that they live in a dedicated secrets manager (Vault, a cloud KMS or secret store) and are fetched just in time with a short lifetime, scoped to the specific workload and tenant — never baked into a container image, a prompt, or a sandbox snapshot (Ch. 9, 24, where secrets are injected only after a microVM resumes). Rotation is automatic, so a leaked credential expires quickly; where a tenant requires it, keys are customer-managed (BYOK, Ch. 26).
For the model's own actions, the pattern of Chapter 22 generalizes: the gateway and tool layer broker upstream credentials, attaching them to outbound calls from a vault so the agent — and the model's context — never sees them. This matters because anything that enters the context window can leak: through a trace (Ch. 18), an output, or an injection (Ch. 16).
Never place a credential in a prompt, a tool description, or run state. The model may echo it into an output, it is captured verbatim in traces and logs, and an injected instruction (Ch. 16) can exfiltrate it. Keep secrets in a manager, inject them at the boundary outside the model's view, scope and rotate them — and the blast radius of any single leak stays small.
15.5 Agent identity: the agent as a first-class principal
Workload identity (§15.1) answers "what process is this." It does not answer the question agentic systems increasingly force: which agent is this, who owns it, what is it entitled to, and on whose behalf is it acting. Those are properties of the agent itself, not of the pod it happens to run in — so a third identity has emerged alongside the human principal and the workload. An agent identity is durable across runtimes and sessions, attestable, bound to an owner or publisher, and scoped to a set of capabilities; it is the identity you authorize, audit, and revoke at the level of the agent. The three compose: the human principal authorizes an action, the agent identity carries who is acting and what it may do, and the workload identity (SPIFFE) attests where it runs. Every consequential action should be attributable to all three.
This matters most in delegation. The multi-hop chains of Chapter 12 — a human asks an agent, which calls a sub-agent, which invokes a tool — must carry identity at every hop, so authorization is least-privilege per agent and the audit trail (Ch. 17) records not "a request happened" but "agent A, acting for user U, running as workload W, did X." The token-exchange and on-behalf-of machinery of §15.2 is how that delegation is represented on the wire; AG-UI (Ch. 13) is where the human principal authorizes the agent in the first place.
This has moved from concept to platform primitive: the major clouds now issue managed agent identities — Microsoft Entra Agent ID, AWS Bedrock AgentCore Identity, and Google Cloud's agent-identity work — the signal that "give the agent its own identity" is becoming as standard as giving a service account one. Treat an agent identity like any other principal: least-privilege scopes, short-lived credentials (§15.4), auditable use, and prompt revocation when an agent is retired or compromised.
Distinguish the human principal (who authorized it), the agent identity (which agent, owned by whom, entitled to what), and the workload identity (where it runs). Authorize and audit at the agent level, carry all three through every delegation hop (Ch. 12), and make every consequential action attributable to the full chain — not merely to a process.