A New Crisis in Agent Identity Governance

Ask a typical security team how many AI agents are running inside their environment right now, and the honest answer is usually a guess. Ask them to trace a specific agent action back to the human who authorized it, and the guess gets worse. Research published by the Cloud Security Alliance in the summer of 2026 put numbers behind that uncertainty, and the numbers describe something closer to a structural gap than a maturity curve. In a January 2026 survey of 228 IT and security professionals, sixty-eight percent said they could not clearly separate agent actions from human activity in their own systems, and only twenty-eight percent said they could trace an agent's action back to a human sponsor at all.

That is not a logging problem that a better dashboard fixes. It is what happens when an organization grants an operational actor the ability to act, decide, and move between systems, then never builds the identity infrastructure that would let anyone answer basic questions about what that actor did. Enterprises spent two decades building identity and access management around a simple assumption, a person logs in, holds a role, and keeps that role until someone changes it. AI agents break every part of that assumption. They spawn on demand, delegate authority to other agents, collect credentials from several providers across a single task, and often get decommissioned without anyone formally revoking what they could reach.

The gap this creates is not abstract for the reader a compliance officer or general counsel has to answer to. When a regulator or an auditor asks for evidence that a specific data access was authorized, by a specific person, for a specific purpose, an organization running ungoverned agent identities cannot produce that evidence on demand. It can produce a credential log, at best, and a credential log tells you which token was used. It does not tell you who was accountable for the decision to use it.

Regulators are not waiting for enterprises to resolve this on their own timeline. Data protection authorities already expect an organization to document the lawful basis and human accountability behind any automated processing of personal data, and an agent that acted under a shared credential nobody can trace to a specific sponsor cannot meet that expectation no matter how sophisticated the underlying model is. The accountability gap this research describes is therefore not only an operational risk. It is a compliance finding waiting to happen the first time an agent's action becomes the subject of an inquiry.

Key Takeaways

  • Most organizations cannot attribute agent actions to a human. Cloud Security Alliance research found that only twenty-eight percent of surveyed security professionals can trace an AI agent's action back to the human who sponsored it, which means most organizations cannot answer a basic accountability question on demand.
  • Nearly half of incidents take over five hours to contain. Among organizations that confirmed an AI agent security incident in the prior year, fifty-eight percent needed five hours or more to detect and contain it, a window that gives an ungoverned agent substantial time to act.
  • Unsanctioned agents often outnumber sanctioned ones. Among organizations running more than one hundred approved agents, over half report an equal or larger population of agents nobody formally approved.
  • Standards are landing, but adoption is early. Enterprise-Managed Authorization for the Model Context Protocol launched in mid-2026 with early identity provider support, alongside new government-led initiatives on agent identity, but most enterprises have not yet adopted either.
  • Identity answers who, not whether a request should proceed. Even a well-governed agent identity program tells you which agent made a request. It does not evaluate whether that specific request, at that specific moment, matched the task the agent was actually assigned.

The Numbers Behind the Authorization Crisis

The Cloud Security Alliance's AI Safety Initiative described the scope of the gap in detail. Beyond the attribution problem, the same January 2026 survey found that seventy-four percent of respondents said agents routinely receive more access than their assigned tasks need, and credential practice was scattered across the board. Forty-three percent of organizations rely on shared or generic service accounts for their agents, thirty-one percent run agents under delegated human identities, and only thirty-six percent have built dedicated agent identities at all. Ownership of the problem was just as fragmented. Security teams claimed the function in twenty-eight percent of organizations, development owned it in twenty-one percent, IT in nineteen percent, and nine percent of organizations had no named owner whatsoever.

A separate 2026 survey, run with Zenity and covering a different population of security professionals, found that forty-seven percent of respondents had a confirmed AI agent security incident in the prior twelve months. Of those organizations, fifty-eight percent took five hours or more to detect and contain the incident once it started. A companion survey of 445 security professionals found that only thirty-one percent of organizations have formally adopted agent governance policies, and half of those policies are only partially documented or inconsistently applied in practice. Among organizations running more than one hundred sanctioned agents, more than half reported an equal or larger number of agents that nobody had formally approved. Kiteworks' own research into the shadow AI identity gap reaches a parallel conclusion from a different angle, finding that access control built around named human power users simply was not designed to account for software that can act with comparable privilege and far less oversight.

Credential Accumulation and Attribution Collapse

Two failure modes recur across this body of research, and both trace back to the same root cause, which is that agent identity was bolted onto existing identity infrastructure rather than designed for how agents actually operate. The first is credential accumulation. An agent provisioned for one task often keeps the permissions from that task long after the task ends, because nobody owns the job of reviewing and revoking agent-held access the way an offboarding process would for a departing employee. Kiteworks' research into agents that outlive revoked credentials, drawn from lessons security researchers presented at Black Hat and DEF CON in 2026, found that agents built on tested foundation models kept functioning access well after the human who requested that access had moved on or the access had technically been revoked elsewhere in the stack.

The second failure mode is attribution collapse. Most monitoring tools were built to answer which credential made a request, not which chain of delegation produced that request or why. Separate Kiteworks research found that most AI agents are logging in as humans, through static API keys and shared service accounts rather than agent-scoped credentials built for the purpose, which means the audit trail that exists often cannot distinguish a legitimate agent action from a compromised one using the same stolen key. When an agent holds credentials sourced from four or more separate trust domains for a single task, as the Cloud Security Alliance's research describes, no single system has a complete view of what that agent is actually authorized to do across all of them combined.

Shadow Agents and the Multi-Credential Trust Gap

Shadow agents compound both problems at once. These are agents that acquire credentials through informal channels, a personal OAuth grant a developer approved during a demo, a shared token left in a configuration file, a service account created for one project and never cleaned up, rather than through any sanctioned provisioning process. Because they were never formally approved, they also never show up in the governance program built to track sanctioned agents, which is exactly how organizations with more than one hundred approved agents end up with an equal or larger unapproved population running alongside them.

Kiteworks' broader survey work on agents reaching data nobody approved found the same pattern from the data access side rather than the identity side, with purpose binding and kill switch controls named repeatedly as safeguards that exist in policy far more often than in a tested, working form. The overlap between that finding and the Cloud Security Alliance's credential research is not a coincidence. An agent that was never inventoried cannot be purpose bound, and a kill switch cannot stop an actor the governance program does not know exists. Research into governed orchestration among the enterprises actually winning with AI agents points at exactly this discipline as the differentiator, narrow scope, attribute-based access, and human checkpoints at defined points, applied consistently rather than only to the agents that happened to go through a formal request process.

Standards Are Arriving, Enforcement Is Not

The industry is not standing still. Enterprise-Managed Authorization for the Model Context Protocol launched in mid-2026, giving enterprises a way to bind an identity provider's own authorization policy to MCP-based agent tool calls rather than relying on a static token the agent carries indefinitely. Early identity provider support and early adoption among major AI platforms are genuine progress, and Bonfy's own analysis of the MCP OAuth flaw described exactly the gap this kind of enterprise-managed authorization is meant to close, an agent trust model that assumed good behavior rather than enforcing it at the protocol layer.

Government-led efforts followed a similar timeline. A National Institute of Standards and Technology concept paper proposed a demonstration project specifically on agent identity and authorization in early 2026, and a broader AI agent standards initiative followed within weeks. None of this changes the fact that most enterprises have not adopted any of it yet, and standards adoption inside a single organization typically trails a standard's publication by years, not months. An enterprise waiting for the standards landscape to settle before building its own agent identity program is choosing to spend that waiting period with the same attribution gap the Cloud Security Alliance's survey already measured.

The practical lesson from watching standards and incidents arrive on parallel tracks is that a standard changes what is possible, not what is already deployed. Enterprise-Managed Authorization for MCP gives an organization a cleaner way to bind agent tool calls to policy once it adopts the standard, but every agent already running on a static, long-lived credential keeps running that way until someone goes back and migrates it. The Cloud Security Alliance's own maturity guidance treats this as a staged problem for exactly that reason, starting with an inventory and credential hygiene immediately, then building toward dedicated agent identities and standards adoption over a longer horizon, rather than waiting for the destination architecture before taking any action at all.

Why Identity Governance Alone Will Not Close the Gap

Even a mature agent identity program, one with dedicated credentials, short lifespans, clean attribution, and full standards compliance, answers a narrower question than most security teams assume it does. It tells you which agent, acting under whose delegated authority, made a given request. It does not evaluate whether that specific request, at that specific moment, actually belonged to the task the agent was invoked to perform. Bonfy's research on identity versus data context frames this precisely, identity answers who is asking, and traditional data controls answer what is being requested, but neither one on its own answers why this request, right now, should be allowed to proceed.

That third question is where trust boundaries actually get enforced or fail to, and it requires a different kind of visibility than identity management was built to provide. Bonfy's work on relationship-aware governance makes the case that an agent's identity and its credential scope are necessary inputs to that decision but not sufficient ones. The same credential can be entirely legitimate for one request and completely out of scope for the next, and no identity system evaluates that distinction on a per-request basis, because identity systems were built to answer a slower, more static question. Bonfy's broader framing of trust boundaries in AI governance argues that an enforcement layer closer to the point of data access, one that can weigh identity, context, and purpose together at the moment of the request, is what actually makes a governance program defensible rather than aspirational.

What a Defensible Agent Identity Program Looks Like

The immediate work does not require a finished identity strategy to start. It starts with an honest inventory, including the shadow agents nobody formally approved, because a program that only governs the agents it already knows about will keep missing exactly the population the Cloud Security Alliance's research says is often as large as the sanctioned one. From there, the fix follows a familiar shape, dedicated identities instead of shared service accounts, credential lifespans measured in hours rather than left indefinite, and a single named owner for the function rather than the split-four-ways ownership the research found in most organizations today.

None of this requires an enterprise to wait for its agent population to stop growing before it starts, and the sequencing matters more than the pace. An inventory completed this quarter, covering even a portion of the known agent population, produces more usable governance than a comprehensive policy document that never gets implemented. The ownership question deserves the same urgency. A program split across security, development, and IT with nine percent of organizations naming no owner at all, as the Cloud Security Alliance research found, is not a program. It is a gap waiting for an incident to expose it, in the same way the forty-seven percent of organizations that already had a confirmed agent security incident in the prior year discovered theirs.

None of that, done well, closes the third gap on its own. An agent with a clean, dedicated, properly scoped identity can still make a request that has nothing to do with its assigned task, and a program that stops at identity hygiene will have solved attribution without solving authorization. Bonfy's agentic data security use case, built specifically for agents working through the Model Context Protocol, addresses that remaining gap directly, evaluating each request against the requesting entity, the data involved, and the purpose behind the request in real time, rather than trusting that a well-governed identity automatically implies a well-governed action. That combination, clean identity plus real-time, purpose-aware enforcement at the point of data access, is what produces the evidence a compliance officer can actually hand a regulator. A credential log alone only produces a list of what happened. It takes both layers together to produce a defensible record of what happened, who was accountable for it, and why it was allowed.

Frequently Asked Questions

1. What is AI agent identity sprawl?

AI agent identity sprawl describes the uncontrolled growth of credentials, service accounts, and delegated permissions that AI agents accumulate as organizations deploy them across more workflows, without a corresponding identity governance program to track, scope, or retire that access. Cloud Security Alliance research found that most organizations cannot clearly separate agent activity from human activity in their own systems, which is the clearest symptom of the sprawl.

2. Why can most organizations not trace an agent action back to a human?

Agent credentials are frequently shared, generic, or borrowed from a human identity rather than issued as a dedicated, agent-specific identity. Cloud Security Alliance survey data found that only twenty-eight percent of security professionals could trace an agent's action back to the human who sponsored it, largely because the underlying credential and logging infrastructure was never built to preserve that chain of delegation.

3. What are shadow agents?

Shadow agents are AI agents that acquire access through informal channels, such as a personal OAuth grant, a shared development token, or a leftover service account, rather than through a sanctioned provisioning process. Because they bypass formal approval, they also bypass the governance program meant to track and constrain agent access, which is why organizations with large sanctioned agent populations often have an equally large unsanctioned one running alongside it. They are usually not malicious in origin. A developer testing a workflow, or a team standing up a quick automation, rarely intends to create a governance blind spot, but the agent they stood up persists long after the original purpose is forgotten.

4. Does adopting Enterprise-Managed Authorization for MCP solve this problem?

It closes an important piece of it by binding agent tool calls to an identity provider's own authorization policy rather than a static, long-lived token, and early adoption among major platforms is a meaningful step forward. It does not, on its own, evaluate whether a specific request at a specific moment matches the agent's assigned task, which is a separate, data-layer question that identity and authorization standards are not designed to answer.

5. What should a security team prioritize first?

Start with an honest inventory that includes agents nobody formally approved, since that unsanctioned population is often as large as the sanctioned one. Move shared service accounts to dedicated, short-lived agent identities, name a single accountable owner for the function, and pair that identity work with a control that evaluates each request against the agent's actual task at the moment the request happens, rather than relying on identity and credential hygiene alone. Treat the first ninety days as discovery and quick containment rather than a finished program, since a partial inventory acted on immediately produces more real governance than a comprehensive plan that waits for full agent coverage before anything changes.

To learn more about AI agent governance, schedule a demo.