AI agents are the new certificate problem

An agent needs to read a ticket and post a comment. The ticketing API has no concept of a workload, so the agent gets a service account. Eighteen months later that account has write scope across four systems, its key sits in a CI variable, and nobody can say which of the forty agents using it performed a given action.

This is not a failure of agent design. It is the failure the certificate world had in 2015: manual issuance, long validity, no inventory, a shared credential everyone agreed was temporary. The difference is speed, and that many agents are built by teams outside the security organization.

Agents inherit whatever your systems accept

The path of least resistance is well defined: an API key in an environment variable, a shared service account, a personal access token borrowed from the engineer who built the integration, a long-lived OAuth client credential with its secret in a deployment repository. None of these were deliberate decisions. The API accepted the credential, the agent worked, and the alternative required changing an identity provider nobody on the team owned. That is how certificate sprawl happened, and it produced the same result: credentials that exist outside any lifecycle process.

The result is over-privileged, unattributed non-human identity

The symptoms repeat across organizations.

Credentials with lifetimes measured in years, often with no expiry at all.
One credential shared by many agents and sometimes by humans, so revocation is an outage.
Scope set to the maximum the integration needed on the day it was built, and never reduced.
No owner in the identity provider, no ticket trail, no offboarding path when the agent is retired.
Audit logs that record the service account, not the agent, the task, or the user on whose behalf it acted.

The consequence is narrow and severe. You cannot answer “what did this agent do” or “what can it reach,” which are the first two questions in any incident review. Every other control depends on those answers.

Workload identity gives the workload a name

Workload identity replaces a secret with an attestation. SPIFFE and SPIRE are the reference design: each workload gets a SPIFFE ID such as spiffe://prod.example/payments/agent, attested by the platform via a Kubernetes service account, node attestor, or cloud instance identity document, and receives a short-lived SVID, either an X.509 certificate or a JWT.

Cloud providers offer the same shape under different names: instance roles, pod identity, managed identities, and workload identity federation. In every case the platform asserts the identity and your code stops shipping a secret.

One caution. Identity is not authorization. A SPIFFE ID proves which workload is calling. It says nothing about what that workload may do. Teams that stop at identity end up with strong attribution and no reduction in blast radius.

Delegation needs token exchange, not credential copying

When an agent acts for a user, the common shortcut is to hand it the user’s token or a copy of a broad service credential. Both destroy attribution.

OAuth 2.0 Token Exchange, specified in RFC 8693, is the better pattern. The agent presents a subject token, requests a token for a specific target audience with narrowed scope, and receives a token carrying an actor claim that identifies the agent. The downstream service then sees both who the work was for and what performed it.

Pattern	What it preserves	What it fails to prevent
Static API key	Nothing	Nothing
Shared service account	Coarse grouping	Cross-agent attribution
Token exchange with actor claim	User, agent, audience, scope	Nothing by itself; needs policy
Workload identity plus policy	Workload, environment, version	Lateral movement after compromise

The last row is the useful combination. Workload identity establishes who is calling. Token exchange narrows what the call can do. Policy decides whether it should happen at all.

Short-lived credentials only work if issuance is boring

An SVID that lasts an hour turns your certificate authority into a production dependency with an availability target. That is a good trade, but only if you operate it like one.

Rotation has to be automatic and uneventful. Clock skew will break more deployments than cryptography ever will. An agent that cannot reach the CA at startup is down, so issuance needs the same redundancy as the service it serves.

The benefit is that revocation becomes mostly unnecessary: a stolen one-hour credential has a one-hour window, which beats a revocation list that propagates on a schedule nobody can state. The exception is caching. Agents that persist tokens to disk recreate the long-lived credential you were eliminating, in a place your inventory does not look.

Policy as code keeps scope from drifting

Encode the rules where they can be reviewed and tested: which SPIFFE IDs may call which services, which scopes an agent may request for a given task, which data classes are in bounds, which actions need human approval. Enforce at the mesh or API gateway and again at token issuance, because policy at one layer is a suggestion. Keep it in the agent’s repository and test it in CI, so a manifest granting wildcard scope fails the build.

Attribution belongs in the same commit. Every action log should carry the agent identity, its version, the invoking user, the task identifier, and the credential used. Revocation should be surgical: you need to kill one agent, or one version of it, without disabling the platform, by revoking its registration entries, parent ID, OAuth client, and cloud role session. If any step needs a ticket and a meeting, the control does not work at the speed of an incident.

Post-quantum migration makes this harder, not easier

Every agent credential is a cryptographic decision in disguise: TLS to the API, a JWT signed with RSA or ECDSA, an mTLS SVID with an elliptic-curve key, a cloud session token, a signed container image. Under Executive Order 14412, federal key establishment moves by December 31, 2030 and signatures by December 31, 2031. NIST IR 8547, still an initial public draft, proposes deprecating classical public-key algorithms after 2030.

Each of those paths changes, and each change has to be found before it can be planned. If your non-human identity inventory is a spreadsheet maintained by one person, you cannot scope the work. If agents hold undocumented credentials, the migration will find them at the worst possible moment, in production, during a change window.

Workload identity has its own version of this problem. An X.509 SVID signed with ML-DSA requires every verifier in the path to accept ML-DSA, including TLS libraries baked into agent frameworks you do not control. Short-lived certificates help, because re-issuance is routine. Long-lived ones turn the algorithm change into a fleet replacement.

Start with an inventory of credentials, not agents

The inventory that matters lists credentials, not processes. For each one: issuer, lifetime, scope, owner, and what it can reach.

Enumerate every key, token, certificate, and role session an agent can obtain, including the ones issued at runtime.
Map each credential to an owner and a business process. Unowned credentials are the finding, not the exception.
Rank by blast radius: what this credential can reach, and whether reaching it crosses a data boundary.
Replace the top of the list with workload identity and token exchange before migrating any algorithm, or you will migrate the bad design into a post-quantum one.
Put the credential in your CBOM, using the same schema as the rest of your cryptography, so expiry and algorithm appear in one place.

The certificate problem took a decade to fix because nobody owned the inventory until auditors forced the issue. Agents are accumulating faster than certificates did. The organizations that start with the inventory will find the migration tractable. The ones that start with the algorithm will find out how many credentials they have when the first one fails to verify.