Agent Identity and Non-Human Authentication

Human authentication and authorization are well-trodden ground: a login proves identity, a session carries it forward, and a policy check decides what the session may do on each request. What's easy to overlook is that a human also supplies an implicit control that never shows up in any diagram — judgment before the click. Nobody automates approving their own six-figure payout at 3 a.m. That judgment call is part of the security boundary even though no code enforces it.

Agents remove that judgment call by design. invoice-agent might process forty invoices in a shift, each ending in a call to POST /v1/payouts, with no person reviewing any individual one. That means the credential it presents has to do work a human's session never had to do alone: prove which workload is calling (authentication), constrain what that call may do (authorization), establish whose authority it's acting under (delegation — is it acting as itself, or on behalf of the accounts-payable team that queued the invoice?), and ideally prove which specific task and code produced this exact call (attestation). A shared static API key answers the first question weakly — "someone who holds the key" — and effectively nothing else, because rotating a narrower key per task is operationally annoying enough that teams default to one broad, long-lived secret.

The replacement for a standing shared secret is workload identity: an identity the platform issues to the running process itself — a container, a service account, an attested build — rather than a string checked into config or an environment variable. There is nothing to leak from a file, because there is no long-lived secret sitting in one. invoice-agent's orchestrator holds this kind of identity and uses it, not to call the payments API directly, but to authenticate to a token service.

From there, delegated OAuth token exchange (the token-exchange grant defined in RFC 8693) mints the credential that actually reaches the payments API. The orchestrator exchanges its own workload identity for a narrow token: audience restricted to payments-api, scoped to payouts:write, carrying claims for the exact task id, vendor, and amount ceiling, with a TTL measured in minutes instead of months. The payments API validates those claims before it executes anything — a call for the wrong vendor, past the TTL, or over the ceiling is rejected regardless of whether the bearer token is otherwise well-formed, because the boundary lives in the token's claims, not in an internal allowlist somewhere else.

None of these models is free, which is exactly why static keys survive as long as they do. A shared secret is operationally the simplest thing to build — one string, no token service, easy to debug when something breaks — and that simplicity is why early agent deployments default to it. A per-agent service principal is a modest upgrade: invoice-agent gets its own identity, so revoking a compromised credential doesn't take down an unrelated support-agent sharing the same key. But the credential itself is still valid indefinitely and still authorizes every call the agent will ever make, forever, until someone remembers to rotate it.

Workload identity paired with token exchange is the model actually replacing shared keys in production agent systems, because it fixes both axes at once: blast radius shrinks to one agent (service principal) and to one task (short TTL, task claim). Attestation goes further still — a signed statement about which code and which task produced a call, so the resource server can refuse not just "wrong scope" but "not a genuine invoice-agent run at all." The cost is real: a token service becomes a dependency the payments API must trust, and claim-checking means the payments team, not only the platform team, has to validate audience and task claims on every call. Reach for attestation when an agent can move money or touch regulated data; a read-only reporting agent rarely needs it.

Trigger. invoice-agent originally authenticated with one long-lived API key, provisioned at deploy time and read from an environment variable. A staging deployment mirroring production traffic for debugging left request logging turned one level too verbose, and a full Authorization header — the static key included — landed in a log aggregator several engineers could read. Symptom. Two weeks later, the payments team notices payouts to a vendor no invoice ever referenced, issued at 3 a.m. when no invoice-processing job was scheduled to run.

Root mechanism. The payments API had no way to distinguish that call from a legitimate one, because nothing about it could. invoice-agent's key authorized any vendor, any amount, indefinitely, with no claim tying a given call to a specific invoice or task. Whoever read that log line could replay the exact bearer token invoice-agent uses for every real payout — the key was the entire authorization boundary, and it drew no line between "invoice-agent processing INV-4471 right now" and "anyone with a copied header, at any time."

Diagnostic. The on-call engineer pulls the payments API audit log filtered by the leaked key's client id and diffs it against the orchestrator's task queue; any payout with no matching task record is suspect. Recovery. Revoke the compromised key at the identity provider immediately, so future replays fail outright, then reconcile every payout issued under that key during the exposure window — flag and reverse the ones with no legitimate task behind them. Prevention. Move invoice-agent to workload identity and per-task token exchange: a leaked token now expires in minutes, is scoped to one vendor and one amount ceiling, and carries a taskId claim, so a payout with no matching task is rejected at the payments API instead of discovered afterward in an audit log.