Some questions come in waves. No one’s asking, and then suddenly the same question is everywhere. Right now, the wave is about identity and access control for agents, and whether we’re trying to govern 2030 infrastructure with 2015 architecture. We explored identity in a previous post. This one goes deeper on access, and what happens when the thing you’re governing starts making its own decisions about what to reach for.
Why Least Privilege Gets Complicated Fast
We understand least privilege. It’s a cornerstone principle. Give every identity the minimum access needed to complete its task, nothing more.
The problem with agents is that “minimum access” isn’t always obvious until the agent is running.
A traditional service account behaves deterministically. You can enumerate its access requirements in advance. Read from this database, write to this queue, call this API. You scope those permissions before deployment and they hold.
An agent is different. Part of its access needs emerge at runtime, because part of its decision-making emerges at runtime. The model decides which tools to call and which data to retrieve based on the task in front of it, assembled from user input, context, memory, and retrieval. You can’t fully predict that access surface at provisioning time the way you could with a service account.
What that creates in practice is a predictable anti-pattern: teams grant broad permissions upfront so the agent can “handle whatever comes up,” intending to tighten them later. Later rarely comes.
The result is familiar. An identity with standing privilege, broad reach, and unclear boundaries. The difference is speed. An over-permissioned agent can act faster and at greater scale than any human ever could. Research from BeyondTrust reports a 466.7% year-over-year increase in AI-driven identities and automation inside enterprises. Most of that growth is almost certainly outpacing the governance being applied to each new deployment.
The Confused Deputy, Now at Machine Speed
There’s a specific failure mode that emerges from over-permissioned agents that deserves more attention: the confused deputy problem, now operating at machine speed. The classic confused deputy is a system with legitimate, broad permissions that gets manipulated into using those permissions for something it never should have done.
In an agentic context, the manipulation vector is data. An agent retrieves a document from a knowledge base, processes an email, or pulls context from a ticket. That content includes a hidden or embedded instruction. It might direct the agent to summarize information and send it externally, retrieve additional data, or call a tool that was never part of the original intent. The agent continues operating under its full credential set. The permissions are legitimate. The intent has been hijacked.
Nothing “breaks” in the traditional sense. The logs show valid access. The credentials are correct. The action is authorized. It’s just not what anyone intended.
That’s the challenge for defenders. We’re no longer only defending against unauthorized access. This aligns with OWASP’s characterization of prompt injection as a failure to separate instructions from data. We’re defending against authorized actions executed under manipulated intent.
How this Changes the Risk Model
There’s a natural instinct to model agent risk as a set of conditions. If an agent has access to sensitive data, processes untrusted input, and can take action externally, risk is high. Remove one of those conditions and you reduce exposure.
That framing is useful. It’s also incomplete. Focusing on conditions misses what actually drives impact. Two out of three can still be enough to cause significant damage. In some cases, one is.
The better question isn’t just what properties this agent has. It’s how much damage it can do when something goes wrong.
OWASP’s LLM06:2025, Excessive Agency, identifies three root causes of dangerous agent behavior that map directly to this problem: excessive capabilities, excessive autonomy, and excessive permissions. Our research team built on that foundation to develop No Excessive CAP (capabilities, autonomy, permissions), which Gal Moyal detailed in a recent post.
What capabilities does the agent have, and how powerful are the actions it can take? How much autonomy does it have to execute decisions without human intervention? What permissions does it operate under, and how broad or persistent are they?
Each of these is a dial, not a binary condition. And the risk compounds across all three. An agent with moderate capabilities but maximum autonomy and broad permissions has a very different risk profile than one where all three are held low.
When all three are excessive, the blast radius isn’t theoretical. It’s immediate, and often irreversible. But the more important insight is that you don’t need all three to be in play.
We saw this in the Replit incident last year: the agent deleted an entire production database during a code freeze. No attacker, no prompt injection. Just excessive capabilities meeting excessive autonomy with no human checkpoint in the path. An agent with excessive permissions can amplify even a small mistake into a systemic incident.
This shifts the design question. It’s not whether the agent meets a set of risk conditions. It’s how far a bad decision can travel once it’s made. That’s the architectural lens that matters.
What Traditional IAM Wasn’t Built For
There’s a deeper structural issue underneath this.
OAuth 2.0, OIDC, and SAML were designed for a world where applications behave predictably, sessions are bounded, and you’re managing a single principal at a time. Agents violate all three assumptions. They make decisions dynamically. They operate across loosely bounded sessions. They act on behalf of multiple principals, or spawn sub-agents that do the same.
That creates ambiguity in accountability. When something goes wrong, it’s not always clear which identity should appear in the audit log, who approved the access being used, or who is responsible for the action taken. These aren’t edge cases. They’re the natural byproduct of delegation chains in agentic systems.
In February 2026, NIST’s Center for AI Standards and Innovation (CAISI) launched the AI Agent Standards Initiative specifically to address agent identity and authorization as an open challenge. The NCCoE concept paper treats prompt injection not as a model quality issue but as a security control design problem, and asks directly how existing identity standards should extend to govern autonomous agents. The standards are catching up. In the meantime, we have to design with the gaps in mind.
What a Hybrid Governance Model Looks Like in Practice
The identity model still matters. It’s just not sufficient on its own.
From human identity governance, agents need ownership, accountability, and lifecycle management. Someone has to approve what they do, review what they’ve done, and retire them when they’re no longer needed. From service account governance, they need dedicated machine identities, non-interactive authentication, and secrets managed outside of code. Least privilege still applies.
But neither model handles the runtime problem. Because agents make decisions at runtime, access control has to be evaluated at runtime as well.
The practical approach is just-in-time, task-scoped access. Credentials are issued per session, scoped to a specific task, and expire when that task completes. Not standing privilege. Not reusable API keys that persist across sessions.
Even that isn’t the whole answer. An agent may have broad access by design, but not every task it performs requires all of that access simultaneously. The principle isn’t to give the agent less access overall. It’s to give the agent only what the specific task requires in that moment. Task-scoped, not just time-scoped.
AWS framed this clearly in their response to NIST’s January 2026 RFI: applying least privilege to access management in an agentic context is as important, if not more so, than in traditional systems, because agents operate at greater scale and speed. An over-permissioned agent can do much more unintended damage, much faster.
Visibility Is the Prerequisite
None of this works if you don’t know what’s already running. Most organizations already have agents in production. Some are formal deployments. Others are embedded in tools, scripts, or workflows that never went through security review. Shadow AI is real. And shadow agents inherit credentials.
Delinea’s 2025 AI in Identity Security research found that 56% of organizations report that they experience shadow AI issues at least monthly. If you don’t have a clear inventory of every agent, every credential it holds, every system it can reach, and every tool it can call, you don’t have an accurate picture of your access surface. Inventory isn’t a governance checkbox. It’s the foundation for everything that follows: posture management, JIT access controls, runtime enforcement, blast radius analysis.
Access Control Is Not Enough
Access controls define what an agent is allowed to do. They don’t determine whether what the agent is doing in a specific moment is appropriate. An agent operating entirely within its allowed permissions can still be compromised if its decision-making is manipulated. Governance has to move closer to execution. You need enforcement that evaluates what the agent is trying to do and whether that action makes sense in the context of the task, before the action runs, not just after it’s logged.
Enforcement can’t rely solely on the agent’s own harness. It needs to sit externally as well, as a control plane that evaluates intent before execution.
Access governance constrains blast radius. Runtime enforcement constrains behavior. They’re not competing priorities. They’re the same control plane, applied at different layers.
The Question to Bring to Your Next Architecture Review
Identity governance defines what an agent is allowed to do. The harder problem is what it can be manipulated into doing with that access. So the question isn’t just what the agent can access. It’s whether the agent has excessive capabilities, autonomy, or permissions, and what happens if it makes the wrong decision. If the answer points to high autonomy, powerful actions, and broad standing access, you don’t have a theoretical risk. You have a live attack path.
Start by knowing what you have. Scope access to the task, not the identity. Move away from standing privilege. And make sure there’s an enforcement layer between decision and execution.
We’ve spent years hardening who can access what. Agentic systems are forcing us to harden how decisions get made in the first place. That’s not a replacement for identity governance. It’s what comes next.
