The agentic identity crisis represents a fundamental misalignment between how enterprises are building AI systems and how their security frameworks are designed to protect them. Traditional security architectures assume a perimeter defense model: humans authenticate to applications, applications authenticate to backend services, and identity is managed through relatively static role assignments. AI agents violate every assumption in this model.
An AI agent is not a user. It doesn’t have a persistent session. It doesn’t have a defined set of permissions it knows in advance. It executes code that was written days ago by humans who can’t predict exactly what that code will do when fed novel inputs. It scales to thousands of instances, each operating independently. It chains multiple API calls together in ways that weren’t explicitly authorized at request time. It can assume different identities mid-execution based on its own decision-making. Your security framework was built to prevent this, not to facilitate it.
The crisis emerges in three dimensions. First, visibility: most organizations don’t actually know what identity their deployed agents are using or what permissions those identities hold. Second, authorization: the principle of least privilege breaks down when you don’t know what the agent will need to do. Third, auditability: by the time you see a suspicious log entry, the agent has already moved on to three more actions using three more identities.
The technical problem is that agent behavior is not deterministic. A human user will perform a known set of tasks. An agent performing a coding task might need to read dozens of repositories, analyze dependencies, check version control history, and modify files—none of which can be perfectly predicted. Giving an agent “just enough” permissions requires understanding all possible execution paths, which is computationally intractable.
Worse, the incentives are inverted. Security teams want to minimize permissions. Development teams want to move fast and give agents broad access to avoid failures. Once an agent gains a permission, it can use that permission in ways the developer never intended. The security framework doesn’t distinguish between “legitimate agent use” and “agent compromise by injection attack.”
Solving this requires rethinking identity from the ground up. Rather than assigning static permissions to agentic identities, organizations need runtime verification frameworks that can make per-action authorization decisions based on the actual execution context. This means cryptographic verification of code provenance, continuous re-authentication rather than one-time token issuance, and real-time monitoring of what identities are actually being used and why.
Source: The New Stack