AI Agent Identity: The 4 Critical Risks of Shared Credentials

An identity answers one question: who did this?

For humans, the answer comes from a username, a session, an MFA challenge. For traditional software, it comes from a service account or an API key. Both models assume the actor is predictable — a person following a policy, or a process running fixed code.

AI agents break that assumption. They decide at runtime which tools to call, in what order, against which systems. Two runs of the same agent against the same input can take different paths.

AI agent identity is the practice of giving each agent its own cryptographically verifiable identity, with scoped permissions, a defined lifecycle, and an audit trail that survives delegation across multiple systems.

The alternative — and the current default — is to hand the agent a credential that already belongs to something else. A developer’s OAuth token. A shared service account. An API key checked into a config file.

That shortcut is where the exposure begins.

Key Takeaways

• When an agent runs on a borrowed credential, every action it takes is forensically attributed to whoever owns that credential. Attribution is the foundation every other control sits on.
• Reported machine-to-human identity ratios range from 17:1 to 144:1 across vendors — an eight-fold spread that says more about measurement immaturity than about any single number.
• 93% of AI agent projects still use unscoped API keys, and 78% of organisations have no documented policy for creating or removing AI identities.
• The Salesloft Drift and Vercel breaches both ran on stolen OAuth tokens rather than novel AI attack techniques. The credential was the vector.
• Workable standards exist: SPIFFE for workload identity, OAuth Token Exchange for delegation. Neither is complete on its own, and the gap between them is where most implementations fail.

---

Quick Navigation

---

Why Shared Credentials Break AI Agent Identity

When an agent authenticates as a human user, three things become true simultaneously, and all three are bad.

Every action becomes that person’s action. Not approximately. In logs, in forensic reconstruction, and in most compliance frameworks, the agent’s activity is indistinguishable from the credential owner’s activity.

The agent inherits everything that person accumulated. Human permissions grow by accretion over years — a project here, a temporary escalation there, an old system nobody revoked. An agent handed that credential gets the whole pile, not the slice it needs.

The only off switch also switches off the human. Revoking the credential to stop a misbehaving agent locks out the employee. In practice, that means teams hesitate, and hesitation during an incident is expensive.

The same logic applies to shared service accounts, with an extra failure mode: when twelve agents share one account, disabling it to contain one of them breaks the other eleven.

OWASP classifies this pattern under ASI03, Identity and Privilege Abuse, in its Agentic Security Initiative work. It is not an edge case. It is the default configuration of most agent deployments running today.

---

The Four Things You Lose Without AI Agent Identity

Here is the part worth internalizing: shared credentials do not just create one problem. They disable four controls at once, and each depends on the one before it.

Loss 1 — Attribution. You cannot determine which agent took an action. This is the root loss, because everything else requires knowing who acted.

Loss 2 — Selective revocation. Without attribution, you cannot revoke one agent’s access without revoking everything sharing that credential. Containment becomes all-or-nothing.

Loss 3 — Scope minimization. You cannot apply least privilege to an identity that serves many purposes. The credential must carry the union of every consumer’s needs, which is the definition of over-permissioning.

Loss 4 — Lifecycle control. You cannot deprovision an agent that has no distinct identity to deprovision. It persists until someone remembers the shared credential exists.

This cascade explains a finding that otherwise looks strange. Research from Teleport found that access scope predicted security outcomes better than model sophistication, industry, or organisational maturity — a 76% incident rate for over-privileged AI versus 17% under least privilege.

Least privilege is not achievable without distinct identity. Loss 1 makes Loss 3 structurally impossible. The single most effective control in the field depends entirely on the one most organisations skip.

The distinction that makes this urgent — systems that act versus systems that merely generate text — is set out in our comparison of agentic AI and generative AI.

---

Counting the AI Agent Identity Population

Ask how many non-human identities a typical enterprise runs and you will get wildly different answers. This is worth showing honestly rather than picking the most dramatic figure.

Source	Ratio	Scope
Palo Alto Networks, 2026 Identity Security Landscape	109 : 1	Enterprise average
Entro Security	144 : 1	Cloud-native environments
Cloud Security Alliance	45 : 1	All enterprise environments
Composite of published figures	~79 : 1	Median 77 : 1

That is an eight-fold spread between the lowest and highest published ratios. Anyone quoting one of these as the number is overstating what the field actually knows.

Treat the direction as reliable and the magnitude as contested. Entro’s figure rose from 92:1 in the first half of 2024 to 144:1 — a 56% increase in the ratio itself within a year.

The growth projections are more consistent. Palo Alto’s data indicates organisations expect AI agent identities to grow 85% over the next twelve months, against 77% for machine identities overall and 56% for human identities. Agents are the fastest-growing identity class, and roughly 72.5% of machine identities are already attributable to AI agents.

Set against that, the governance figures are stark. 78% of organisations have no documented policy for creating or removing AI identities. More than 16% do not track the creation of AI-related identities at all.

---

What Recent Breaches Reveal About AI Agent Identity

Two incidents make the abstract concrete, and neither involved a novel AI attack technique.

Salesloft Drift. Between 8 and 18 August 2025, threat actor UNC6395 used compromised OAuth tokens belonging to the Drift application to reach customer Salesforce instances via API. Salesloft disclosed on 20 August 2025.

The attacker systematically exported support case text, contact records and account data — including plain text AWS keys, Snowflake tokens, VPN credentials and passwords that customers had pasted into support tickets. Investigations by Google’s Threat Intelligence Group and Unit 42 found the stolen tokens also reached Slack, Google Workspace, Amazon S3, Azure and OpenAI integrations. Hundreds of organisations were affected.

No Salesforce vulnerability was exploited. The attack abused the trust relationship the OAuth tokens were designed to establish.

Vercel. Disclosed 19 April 2026, with the timeline later corrected. The intrusion began at Context.ai around February 2026 via Lumma Stealer malware, with roughly two months of dwell time before detection.

The attacker used a compromised OAuth token belonging to a Vercel employee who had signed up for Context’s service — Vercel itself was not a Context customer. Environment variables not explicitly marked as sensitive were readable within compromised team scopes.

The pattern connecting them is the reason both appear here. Attackers compromise a smaller AI or SaaS vendor, steal the OAuth tokens that vendor holds on behalf of its customers, and use them to reach hundreds of downstream enterprises. Security researchers have started describing OAuth as the new lateral movement, and the description fits.

Agentic AI intensifies this because agent platforms sit at the centre of a hub of OAuth grants with expansive scopes, frequently at young companies without mature security programmes. This is one layer of the broader exposure map covered in the five hidden layers of the AI attack surface.

---

Secrets Sprawl and the Credential Supply Problem

Attackers do not need to steal a credential if one is already published.

GitGuardian detected 28.65 million new hardcoded secrets on public GitHub during 2025, a 34% year-over-year rise and the largest single-year jump recorded. Credential leaks specifically related to AI services grew 81.5%.

Two details make this worse than the headline. First, 64% of secrets confirmed valid in 2022 remained exploitable as of January 2026 — leaked credentials are not self-expiring. Second, surrounding AI infrastructure leaks roughly five times faster than core model providers, and 28% of secrets incidents now originate outside code repositories entirely.

The supply side is expanding fast. Agent framework packages — LangChain, LangGraph, CrewAI, the OpenAI Agents SDK, LlamaIndex, PydanticAI and others — recorded 483 million downloads in May 2026 alone.

Meanwhile, 93% of AI agent projects still use unscoped API keys and 74% of practitioners report their agents end up with more access than needed. Separately, 73% of secrets held by non-human identities carry excessive permissions, and more than 5.5% of AWS machine identities hold full administrative privileges.

When an agent inherits a credential at that privilege level, the distance between authorized to do its job and authorized to do anything collapses to nothing.

---

AI Agent Identity in Multi-Agent Systems

One complication deserves separate treatment, because it is where identity models fail fastest.

Roughly 25.5% of deployed agents can create and task other agents. Once that happens, the identity question stops being “which agent acted” and becomes “which agent, spawned by which agent, on whose original authority.”

Most organisations cannot answer that. Only 24.4% report full visibility into which agents communicate with each other.

The failure is specific and worth naming. When agent A spawns agent B and hands over its credential, agent B’s actions appear in logs as agent A’s. If agent A borrowed a human’s token to begin with, the chain now attributes agent B’s behavior to a person two hops removed who never knew agent B existed.

Every hop erodes attribution further, and attribution was already the control everything else depended on.

The IETF’s workload identity work addresses this directly by requiring that each participant in a delegation chain hold its own identity, scoped to its specific role. The audit record should then show the root agent, each sub-agent, the resource accessed, and the trust domain that issued each identity.

Two practical rules follow. Never pass a credential down a delegation chain — issue a new, narrower one at each hop. And make permissions intersect rather than accumulate: a sub-agent should hold the overlap of what its parent may do and what its own task requires, never the union.

Without those two rules, a multi-agent system converts a single over-permissioned credential into an untraceable one.

---

AI Agent Identity Standards That Exist Today

The encouraging part: this is not a problem waiting on new invention. Working standards exist.

SPIFFE and SPIRE. SPIFFE issues short-lived cryptographic identities (SVIDs) bound to workloads rather than people. An SVID encodes the workload’s origin, deployment path and trust domain, and SPIRE rotates them automatically — commonly hourly. Critically, identity is tied to runtime attestation: an agent not started by an authorized orchestrator cannot obtain a valid SVID even if it can read the config files.

OAuth 2.0 Token Exchange (RFC 8693). For actions taken on a user’s behalf, token exchange with the act claim preserves the delegation chain, so an audit record can show which human authorized which agent to do what.

IETF WIMSE. The workload identity architecture draft (draft-ietf-wimse-arch-08, July 2026) classifies AI intermediaries as a special case of delegated workloads that inherit an upstream principal’s security context. It also requires that autonomous actions not attributable to a specific upstream principal be clearly distinguished — via separate workload identities or token scopes.

Regional guidance. Singapore’s Cyber Security Agency addendum on securing agentic AI designates identity spoofing and impersonation as a named threat, and calls for a trusted agent registry with verifiable credentials and short-lived tokens.

The CNCF’s 2026 recommendation for internal service-to-service authentication summarizes the assembly cleanly: SPIFFE for identity, OAuth 2.0 for access delegation, OPA for policy.

---

Where SPIFFE Stops and OAuth Begins

Most implementation failures happen at the seam between these two standards, so it is worth being precise about what each does not do.

SPIFFE names software, not permissions. An SVID tells the enforcement point which agent is calling. It says nothing about which of twelve available tools that agent may use. You write that policy yourself.

SPIFFE has no human in it. There is no subject claim for a person, no consent record, no delegation chain. For an agent acting on a user’s behalf, that information has to come from somewhere else.

OAuth carries scope but not attestation. A token proves possession. It does not prove the possessor is the workload it claims to be, started by the orchestrator that should have started it.

The two are complements, not alternatives. SPIFFE answers what is calling; OAuth token exchange answers on whose authority. An architecture using one without the other has a gap, and the gap is usually invisible until an incident forces someone to reconstruct a delegation chain that was never recorded.

A production reference pattern circulating in mid-2026 wires SPIRE as the workload identity authority with hourly SVID rotation, a relationship-based authorization service holding the permission graph, and a gateway that intercepts every tool call to check authorization before forwarding it.

---

Building an AI Agent Identity Program

A workable sequence, ordered by dependency rather than difficulty.

Inventory first. Find every agent, including ones a team stood up without telling security. You cannot govern an identity population you cannot enumerate, and 16% of organisations do not track AI identity creation at all.

Give each agent a distinct identity. One agent, one identity, one named human owner. This unlocks the other three losses described earlier.

Eliminate static credentials. 67% of organisations still rely on them. Replace long-lived keys with short-lived, automatically rotated credentials tied to workload attestation.

Scope per task, not per agent. An agent that summarizes tickets does not need write access to the ticket system. Permissions should reflect the operation, not the agent’s broadest possible use.

Log the delegation chain. Record which human authorized which agent to call which tool against which resource. Per-call logging without chain context will not reconstruct an incident.

Test revocation. Run a tabletop on a compromised agent and measure how long containment takes and what else breaks. Research indicates 60% of organisations cannot terminate a misbehaving agent mid-action, and 33% lack audit trails entirely.

Where enforcement automation is not yet in place — and only 3% of organisations have automated controls governing AI behavior at machine speed — human-in-the-loop approval gates remain the practical fallback for high-privilege operations.

---

Primary sources

• Cloud Security Alliance — Non-Human Identity and Agentic AI Governance
• Palo Alto Networks 2026 Identity Security Landscape, via Help Net Security
• Unit 42 — Salesloft Drift threat brief
• IETF WIMSE workload identity architecture
• SPIFFE project

---

Frequently Asked Questions

---

Keep reading

Here are the latest posts from the blog.