The Identity Paradox: Why Agentic AI Breaks IAM by Design

TBDCyber | Agentic AI Security Series

In our previous article, The 45 Billion Identity Problem Nobody Is Talking About, we discussed how agentic AI is proliferating a new class of non-human identities that require governance.

There is a tempting assumption embedded in most enterprise responses to agentic AI: that the identity governance challenge is essentially a scaling problem. More agents means more identities to manage. The solution is better tooling, more comprehensive discovery, tighter lifecycle processes. The same discipline applied at higher volume.

That assumption is wrong, and understanding why it is wrong matters more than almost anything else in the agentic AI security conversation.

The challenge is not that existing IAM frameworks are being applied inadequately to agentic AI. It is that agentic AI was designed, structurally and necessarily, to violate the foundational principles on which those frameworks were built.

This is what we call the Identity Paradox, and it has no clean resolution.

What IAM Was Built For

Enterprise identity and access management rests on a set of assumptions so foundational they are rarely stated explicitly. Identities are stable: a human employee, a service account, an API key. Their behavior is predictable: access patterns can be baselined; anomalies can be detected. Their scope is bounded: a role definition, a permission set, a token with defined scopes. And the relationship between a credential and the entity presenting it is reliable: if the credential is valid, the entity is who it claims to be.

These assumptions underpin the three pillars of IAM (authentication, authorization, and auditing) and every significant enterprise security control built around them. They do not hold for agentic AI; they break all three simultaneously.

How Agents Break All Three Pillars Simultaneously

Authentication assumes that a valid credential reliably represents a known, authorized entity. For a service account or an API key, this generally holds. The credential maps to a registered identity. Presenting it successfully is sufficient to establish who is acting.

An agent's credential is only one component of its identity. Its model version, system prompt, tool configuration, and task context are equally constitutive of what it is and how it will behave. Two agents presenting identical API keys but running different system prompts are, in any operationally meaningful sense, different entities. Authentication answers "is this credential valid?" It cannot answer "is this the agent I authorized, running the configuration, I approved?" That gap cannot be closed by stronger credential management. The problem is not credential strength; it is that the credential is an inadequate representation of the agent.

Authorization assumes that granting a defined scope of access yields a predictable, bounded set of actions. Traditional OAuth was built on this assumption: the resource owner approves specific scopes, the client application faithfully represents their intent, and the authorization server issues a token that governs what can be done.

Agentic AI breaks this in two distinct ways. First, because agents reason dynamically, a token granted for Goal A may be used to execute Action B, even when technically within the token's scope, thereby violating the user's original intent. The interpretive autonomy that makes an agent useful is structurally incompatible with the deterministic scope constraints that secure authorization requires. Second, agents can chain individually authorized tools in sequences that produce effective privilege levels beyond any single permission grant. The combination of read access to a financial report and write access to a communication channel is, in the hands of a reasoning agent, a potential data exfiltration path, regardless of whether either permission, in isolation, looks unreasonable.

Auditing assumes that a human identity performs a discrete, attributable action that can be logged, reviewed, and defended. For an autonomous agent, none of those assumptions hold cleanly. A conventional log can confirm that an action occurred and record the credential used to perform it. It cannot explain why the agent chose that action, reconstruct the reasoning that led to it, establish which human instruction authorized the sequence, or distinguish between an action the agent was intended to take and one it arrived at through emergent reasoning that no one anticipated.

The result is an audit record that is technically complete but legally difficult to defend. It is capable of confirming facts but incapable of establishing intent, authority, or accountability as regulators and courts require.

The Structural Tension

The Identity Paradox can be stated precisely. To function as intended, an effective autonomous agent requires:

• Broad and persistent access to tools, data, and systems

• The authority to make decisions and take actions without continuous human approval

• The ability to spawn sub-identities and delegate tasks dynamically

  
  

These are precisely the characteristics that the principles of least privilege, just-in-time access, zero standing privilege, and deterministic authorization were designed to prevent.

The more capable and autonomous the agent, the more completely it violates the assumptions on which enterprise IAM was built. This is not incidental. It is definitional. An agent that cannot reason, act, and delegate autonomously is not doing what agents are meant to do.

Organizations deploying agentic AI are not facing a governance problem that can be solved by applying existing frameworks more rigorously. They are facing a governance model that was designed for a fundamentally different kind of actor.

Where This Manifests in Practice

The Identity Paradox is not an abstract architectural observation. It surfaces in specific, concrete ways that security teams are already encountering.

Delegation chains without human checkpoints. When a user delegates a task to an orchestrator agent, which breaks it into sub-tasks delegated to specialized sub-agents, the final service performing the work receives a request from an agent it has never authenticated, carrying a token that has been exchanged multiple times. If these delegation chains lack cryptographic provenance, the lineage of authority is lost. A database cannot distinguish between a legitimate request and a request from a compromised agent in the middle of a chain it has no visibility into.

Citizen developer credential inheritance. When a finance manager builds a Power Automate workflow that accesses the ERP, they have created a non-human identity carrying their full access rights. That identity is only useful because it carries those rights. It is dangerous for the same reason. The Identity Paradox operating at the business user level: governance cannot be achieved without undermining the utility the business user was trying to capture.

Vendor-embedded agents with ungovernable scope. The integrations that make a Salesforce Agentforce deployment valuable are precisely the ones that make its access footprint ungovernable under standard IAM controls. Restricting the agent's access to enforce least privilege directly reduces the value it delivers. The Identity Paradox is particularly acute in vendor-embedded deployments because the organization has limited technical ability to constrain an agent whose access scope was defined by a procurement decision.

What This Means for Security Leaders

If the Identity Paradox is structural rather than configurable, the appropriate response is not to look for a solution that resolves the tension. There is not one available, and vendors claiming otherwise should be pressed hard on the specifics. The appropriate response is to develop governance approaches that are honest about the tradeoffs involved and manage the tension deliberately rather than pretending it away.

In practice, that means several things.

First, treat the auditing disruption as the highest-priority architectural gap of the three pillars. Authentication and authorization failures create risk. Auditing failures ensure that when something goes wrong, the organization cannot prove what happened, cannot demonstrate it acted appropriately, and cannot satisfy the evidentiary requirements of regulators and courts. For each significant agentic deployment, the question worth asking now is: if this agent caused a material incident today, could we reconstruct what it did and why with sufficient fidelity to satisfy a regulator?

Second, stop expecting deterministic authorization to work for non-deterministic systems. The goal is not to eliminate the authorization gap as it cannot be eliminated for reasoning agents. Rather, minimize it through compensating controls: tool-level policy enforcement rather than API-level enforcement, human-in-the-loop gates at defined risk thresholds, and behavioral monitoring calibrated to agent rather than human activity patterns.

Third, explicitly update the threat model. Prompt injection, where malicious content in data processed by an agent overrides its system prompt and weaponizes its legitimate credentials, is not a variation of existing attack categories. It is a new class of identity attack with no equivalent in the pre-agentic threat landscape. It requires specific detection logic, specific resilience engineering in system prompt design, and specific constraints on which data sources agents are permitted to process.

***

The Identity Paradox does not have a clean resolution because it is not a problem in the conventional sense. It is a persistent structural tension between two legitimate design requirements (autonomous capability and governed security) that cannot both be fully satisfied simultaneously.

The organizations that navigate this most effectively will be the ones that understand it clearly, govern it deliberately, and are honest about where the residual exposure lies.

This is the second article in TBDCyber's Agentic AI Security series. Our full research report goes deeper into why the Identity Paradox can't be resolved by tightening existing controls. Read the complete analysis here.

The next article examines the Shadow AI problem in detail, including citizen-developer agents, no-code platforms, and agents within your licensed enterprise tools.

TBD Cyber advises security leaders on identity governance, agentic AI security, and emerging threat architectures. To discuss what this means for your organization, contact us.