Agents Are Becoming an IAM Workload, and Your Service Accounts Aren't Ready

Let me give the incumbent view its best case first, because it's not stupid. Service accounts and API keys have carried machine workloads for two decades. They're understood, they're audited, every cloud and every SaaS tool supports them, and the security team already has a spreadsheet of them. When someone says agents need a new identity category, the reasonable response is: we already have one, it's called non-human identity, get on with it.

Here's why that stops working. A service account is an answer to the question "which system is calling?" An agent forces a harder question: "which agent is calling, on whose behalf, towards what goal, and who can revoke it in the next thirty seconds?" The IAM industry's own numbers say non-human identities now outnumber humans by an order of magnitude, and the 2026 Verizon DBIR warned that service and machine accounts are the ones to watch as agentic AI arrives, per Token Security's reading of the report. This is a briefing on why the mapping fails, what's being built to replace it, and what the failures already look like.

Key Takeaways - Service accounts and API keys assume a stable, deterministic caller. Agents are ephemeral, non-deterministic and delegate to each other, which breaks the audit, revocation and least-privilege assumptions baked into shared credentials. - The standards direction is per-agent workload identity: the IETF WIMSE working group is being pushed to require that agents be distinguishable by identity, not just by token scope, with SPIFFE-style per-agent identifiers for policy, audit and revocation. - The incidents are already concrete: compromised OAuth tokens in the Salesloft Drift ecosystem were used to pivot into enterprise Salesforce environments, and Hugging Face's July breach was executed by an autonomous agent end to end. - Implementation guidance is converging: dedicated identity per agent, short-lived task-scoped credentials issued outside the model's context, and audit trails keyed to the agent, not the shared role. - If your agents authenticate as one shared service account, your logs cannot tell you which agent did what. That's the test to apply this week.

What happened

Two things converged in the first weeks of August. First, the standards conversation got specific. An issue on the IETF WIMSE architecture draft, filed on 4 August, argues that the draft's current language on AI intermediaries is too weak: it allows "separate workload identities or token scopes" to distinguish autonomous agent actions, and the issue makes the case that token scopes don't do the job. Scopes restrict what a token may do; they don't change who the token is. Multiple agents sharing one credential stay indistinguishable in audit logs, revocation systems and per-agent policy no matter how the scopes differ. The proposed fix: managed agent platforms should assign each agent a unique workload identifier, carried in a dedicated claim, used as the stable key for policy, audit and revocation. Google's agent identity design, which gives each deployed agent a SPIFFE-based identity tied to its agent resource, is cited as the working example.

Second, the incident drumbeat kept time. Mid-July's Hugging Face breach was the first public named-company intrusion run by an autonomous agent start to finish: code execution in the dataset pipeline, credential harvesting, lateral movement across internal clusters, thousands of actions over a weekend. Earlier in the year, Moltbook, a social network for AI agents, leaked 1.5 million API tokens from a misconfigured database within days of hitting 1.5 million agent accounts, per Studio Global's roundup. And the DBIR's recurring example of non-human identity attacks, the Salesloft Drift OAuth token compromise used to reach Salesforce environments at major enterprises including Google, Cisco and Zscaler, is exactly the shape of credential agents depend on.

In August 2026, an IETF WIMSE issue proposed that agent actions must be distinguished by separate workload identities, not token scopes, with per-agent identifiers as the stable key for policy, audit and revocation. It followed the July Hugging Face agent-run breach and a January incident where the Moltbook agent platform leaked 1.5 million API tokens.

Why service accounts and API keys don't map onto agents

The mismatch has four edges, and it's worth naming them separately because the fixes differ.

Shared identity destroys attribution. Service accounts are designed to be shared, static and broadly privileged. Ten agents under one account and your audit log shows one actor, as Cockroach Labs' field write-up puts it: you can't tell which agent touched which data, rotation means coordinating across every agent, and the account's permissions drift to the union of everything any agent ever needed. Their anonymised example is one I've heard variants of from client teams: a support agent running for three months under an account with read access to the entire customer database, scoped that way in development and never narrowed before go-live.

Agents are ephemeral; keys are not. An agentic workflow might authenticate to a model provider, a vector store, three APIs and cloud storage in seconds, then disappear. Long-lived API keys assume a persistent caller worth rotating on a schedule. The mismatch produces sprawl: keys minted for agents nobody remembers, still valid, still broad.

Delegation breaks the "on behalf of" chain. An agent acting for a user and an agent acting autonomously should look completely different to your policy engine. With a shared service account they look identical. OAuth delegation handles the user case reasonably; the autonomous case needs the agent's own identity, and multi-agent delegation needs each hop to narrow, not widen, the authority passed down.

The model must never hold the secret. This one is structural, not configurational. Credentials passed into the context window are exposed to the model and to anything that can manipulate it: prompt injection can exfiltrate them through the agent's own outputs. The fix is short-lived, scoped credentials issued at task time by a token service and held by the tool-execution layer, so the model triggers calls without the secret entering its context. Cockroach Labs makes this point well, and it matches what I tell clients building on self-hosted agent stacks: the harness holds the keys, the model holds the intent.

Shared service accounts break agent attribution (one actor in the logs), outlive ephemeral agent workloads, blur the line between user-delegated and autonomous action, and tempt teams to pass credentials through the model's context where prompt injection can reach them, per Cockroach Labs and miniOrange's comparison.

What vendors and standards bodies are building

The emerging shape has three layers, and the encouraging thing is that vendors and standards people are converging on roughly the same one.

Per-agent workload identity. The WIMSE direction above is the standards version: each logical agent gets a unique, stable identifier (a SPIFFE URI is the suggested form), distinct from any shared execution role, and that identifier is what policy, audit and revocation key on. Platform-managed agents that share an execution credential would need to supplement it with a per-agent claim. This is the single most important shift: identity per agent, not per deployment.

Federation instead of stored secrets. Descope's walkthrough of workload identity federation for agents shows the pattern: the agent's platform identity (an AWS IAM role, a Kubernetes service account via IRSA) is exchanged for a scoped, short-lived token from the identity platform, which also creates a directory record for the agent so audit trails persist beyond the token's lifetime. No long-lived key to leak, and the identity record outlives any single credential.

Discovery and governance as a market. On the commercial side, the non-human identity vendors (Reco, Token Security, Oasis, Aembit and friends) are repositioning around agents: discover every agent credential, map it to an owner, flag over-privilege, and revoke cleanly. The Reco framing is the practical one: match identity type to the agent's role (delegated OAuth for user actions, dedicated workload identity for autonomous ones) and review permissions as responsibilities grow, because agents accumulate privilege the way staff accumulate keys to the building. OWASP's Top 10 for Agentic Applications, published in December 2025, names Identity and Privilege Abuse as a first-class risk category, which gives security teams shared vocabulary for the audit findings. Where this lands in your wider stack is a governance question as much as a tooling one; I cover the organisational side in AI agent governance.

The emerging architecture: per-agent workload identities (SPIFFE-style identifiers keyed for policy, audit and revocation, per the WIMSE discussion), federation of platform identity into short-lived scoped tokens with persistent agent directory records (per Descope), and a vendor market for discovery and least-privilege governance of non-human identities.

When agent identity goes wrong

Three incidents, three different failure modes, all instructive.

Hugging Face, July 2026: the attacker's identity problem was the defender's too. The agent-run intrusion harvested cloud and cluster credentials from a code-execution worker and moved laterally, which is the classic over-privileged workload story: a data-processing component held credentials worth stealing. The less reported detail is the forensic asymmetry Hugging Face disclosed: the attacking agent was bound by no usage policy, while the company's own forensic work was initially blocked by the guardrails of the hosted models they tried, so they ran forensic analysis on an open-weight model (GLM 5.2) on their own infrastructure. Identity and access failures on both sides of the same incident.

Salesloft Drift, the DBIR's cautionary tale: tokens as skeleton keys. Compromised OAuth tokens from one vendor ecosystem were used to pivot into the Salesforce environments of major enterprises. No passwords, no phishing of humans: non-human credentials, broadly trusted, quietly reused. Every agent you connect to a SaaS tool with a long-lived OAuth grant is this shape of risk, and the mitigation is the same shape too: short-lived, narrowly scoped, per-agent, revocable.

Moltbook, January 2026: agent platforms aggregate identity risk. A platform for agent accounts leaked 1.5 million API tokens plus email addresses and inter-agent messages from a misconfigured database, per the Studio Global account. When you centralise agent identity, you centralise its blast radius. Worth saying I'd treat some of the incident details in circulation as reported rather than audited; the Hugging Face disclosure itself is primary, the Moltbook numbers come from secondary coverage.

Documented agent-identity failures include the July 2026 Hugging Face breach (an autonomous agent harvesting cloud and cluster credentials and moving laterally, per Waxell's analysis), the Salesloft Drift OAuth-token pivot into enterprise Salesforce tenants (per Token Security on the 2026 DBIR), and the Moltbook leak of 1.5 million agent API tokens.

What to do now

1. This week: enumerate your agents' credentials and apply the attribution test: pick any agent action from your logs and ask whether you can tell which agent did it, on whose behalf, and whether you could revoke just that agent without touching the others. If the answer is no, you have a shared-identity problem, and it's the finding to fix first.

2. This month: move one autonomous agent off its long-lived credential onto short-lived, task-scoped tokens issued by a token service or identity platform, held in the tool-execution layer and never in the model's context. Start with the agent holding the broadest access; that's usually the one somebody scoped "temporarily" in a hurry.

3. This quarter: give each logical agent its own stable identity (a SPIFFE ID where you have the machinery, a unique service account per agent where you don't), key your audit and alerting to it, and write the revocation runbook before you need it. If you're earlier in the journey and still deciding where agents should run at all, the local versus cloud agents trade-off shapes how much of this you can own.

FAQ

What is agent identity in IAM terms?

A distinct, verifiable identity assigned to an individual AI agent, separate from the platform it runs on and the users it acts for. It's used as the stable key for authentication, authorisation policy, audit trails and revocation, the way a workload identity identifies a microservice, but tuned for callers that are ephemeral, non-deterministic and able to delegate to each other.

Why can't agents just share a service account?

They technically can, and most do today. The failures: audit logs show the shared account rather than the acting agent, so you lose attribution; the account's permissions grow to the union of every agent's needs; revoking one agent means rotating credentials for all of them; and you can't distinguish user-delegated actions from autonomous ones. It works until the first incident, then you have no way to reconstruct what happened.

What are standards bodies doing about agent identity?

The IETF WIMSE working group is extending workload-identity architecture to AI intermediaries, with an active proposal to require per-agent identifiers (SPIFFE URIs are the suggested mechanism) rather than relying on token scopes. OWASP published a Top 10 for Agentic Applications in December 2025 with identity and privilege abuse as a named category, and the Cloud Security Alliance has an agent identity governance framework recommending unique identity per agent.

Should agent credentials ever appear in the model's context?

No. Anything in the context window is visible to the model and exfiltrable by prompt injection. The accepted pattern is credentials issued at task time by a token service, held by the tool-execution layer between the model and the API, scoped to the task and short-lived. The model requests the action; the harness holds the secret.

The bottom line

Identity people have a saying that identity is the control plane, and agents are about to test it harder than microservices ever did. The direction is clear enough that you can start building towards it today: identity per agent, secrets outside the model, tokens that expire faster than incidents spread, and audit that can answer "which agent, whose behalf, what goal". The organisations that got burned this summer weren't running exotic setups; they were running shared credentials and hoping. That's the gap to close, and it's closable with technology that mostly exists.

If you're mapping agent identity onto an existing IAM estate and want a practitioner in the room, that's work I do. Get in touch.

Sources

• IETF WIMSE WG, draft-ietf-wimse-arch issue #139, "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (filed 2026-08-04, retrieved 2026-08-29)

• Cockroach Labs, "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (published 2026-07-17, retrieved 2026-08-29)

• Token Security, "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (published 2026-05-20, retrieved 2026-08-29)

• Descope, "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (published 2026-06-22, retrieved 2026-08-29)

• miniOrange, "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/ (published 2026-05-20, retrieved 2026-08-29)

• Reco, "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents (published 2026-07-20, retrieved 2026-08-29)

• Waxell, "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (published 2026-07-17, retrieved 2026-08-29)

• Studio Global, "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (published 2026-08-17, retrieved 2026-08-29)