AI Agents Don't Have Identity. That's the Problem.

The identity security industry spent the last decade building increasingly sophisticated ways to answer one question: is this human who they say they are? Multi-factor authentication, behavioral biometrics, risk-based access, continuous authentication — all of it is optimized for the problem of a human presenting credentials and a system deciding whether to believe them.

The next decade's problem is different. The entity presenting credentials is not a human. It's an AI agent — an autonomous system running tasks, accessing APIs, reading and writing data, making decisions that have real consequences. And the identity infrastructure that was built for humans is almost entirely unprepared for it.

What makes AI agent identity different

A human has a persistent identity that exists independently of any particular session. You are the same person whether you're logged into your work laptop or your personal phone, whether it's Monday morning or Saturday night, whether you're acting normally or acting suspiciously. The goal of identity verification is to confirm that the entity presenting credentials corresponds to that persistent human identity.

An AI agent has no equivalent. It is instantiated for a task, executes the task, and ceases. There is no persistent entity that corresponds to "the agent" the way there is a persistent entity that corresponds to "the employee." The agent that ran your data pipeline at 2 AM is not the same instantiation as the agent that will run it tomorrow night, even if both use the same credentials.

This creates a fundamental mismatch with how identity infrastructure works. Identity systems are built around the assumption of persistence — that the entity you're authenticating today is the same entity you authenticated yesterday, that anomalies from baseline behavior are meaningful signals, that context about past behavior informs present trust decisions. None of those assumptions hold for AI agents.

"The identity infrastructure that was built for humans is almost entirely unprepared for entities that have access but no continuous self."

The accountability gap

When a human takes an action in an enterprise system, there is a chain of accountability. The human has a manager. The manager approved the access. If something goes wrong, there is a person who can be asked: why did you do this? The accountability is imperfect — humans act outside their sanctioned roles, credentials get compromised — but the chain exists.

When an AI agent takes an action, the accountability chain is murkier. The agent was authorized by someone — an engineer who set up the automation, a product manager who approved the workflow, a security team that granted the permissions. But the agent acts autonomously, making decisions in context that none of those authorizers anticipated specifically. If the agent takes an action that causes harm, who is accountable? The engineer who built it? The manager who approved it? The vendor whose model it runs on?

This is not a hypothetical problem. Organizations are deploying AI agents right now with access to production systems, real data, consequential APIs. The access governance for those agents was designed for service accounts — static credentials, documented purpose, periodic review. It was not designed for entities that make contextual decisions, that behave differently in different circumstances, that can be manipulated through the inputs they process.

Prompt injection as an identity attack

The most novel security problem that AI agents introduce is prompt injection — the ability for malicious content in the agent's environment to redirect its behavior. An agent browsing the web on your behalf might encounter a page that contains instructions designed to look like legitimate task guidance. An agent reading emails might process one that attempts to redirect it toward unauthorized actions. An agent analyzing documents might be handed one that tries to exfiltrate the other documents it has access to.

This is, at its core, an identity problem. The agent is supposed to act on behalf of the authorizing human, within the scope that human intended. Prompt injection attempts to substitute a different principal — the attacker — for the intended one, using the agent's own processing as the attack vector. The agent's identity, in terms of whose interests it's acting for, gets compromised through its inputs rather than through its credentials.

Current identity infrastructure has no model for this. You cannot put a prompt injection attack in a SIEM and get a useful alert. You cannot write an access policy that distinguishes between "agent acting for authorized principal" and "agent acting for injected instructions." The attack surface is entirely new.

What needs to change

The identity security industry needs to develop a model for AI agent identity that accounts for what agents actually are — ephemeral, context-dependent, acting on behalf of human principals but not themselves human. That model needs to address several things that current frameworks don't.

Scoped, time-limited credentials that expire when a task completes rather than persisting indefinitely. Audit trails that capture not just what an agent did but what it was reasoning about — the context in which each action was taken, the inputs that informed it, the alternatives it considered. Behavioral baselines that account for the inherent variability of agent behavior rather than treating all deviation as anomalous. Detection mechanisms for prompt injection and other forms of principal substitution.

None of this is impossible. Some of it is being worked on. Most organizations deploying AI agents are not waiting for it to be solved — they are deploying now with the governance frameworks they have, which were built for a problem that doesn't quite match the one they're facing.

The gap between the identity infrastructure we have and the identity infrastructure we need for a world full of AI agents is one of the more interesting problems in security right now. It is also one of the most consequential. The organizations that figure it out first will have a meaningful advantage. The ones that don't will eventually learn from a breach why the old frameworks weren't enough.