If an organization is deploying AI agents, someone has probably proposed giving them an identity of their own, with a registry, a console, and a lifecycle to manage. It is a reasonable instinct. A new kind of actor seems to need a new kind of identity, and the stories of agents going rogue make it feel urgent.
It is also one more system to run, for teams that already have too much. And it gives agents the model people already have, which is not doing well even for people: security has been IT’s biggest concern for more than ten years, and still attackers are winning, and multi-factor authentication (MFA) fatigue is widespread. The better answer is not a second system; it is fixing what identity means, once, for everyone.
Rogue agents are not an identity problem
The rogue stories are real, but they are not about identity. In the cases that made the news, an agent went beyond what anyone wanted, starting from the access it had been given. Identity answers one question: who is acting, and there the answer was right. As far as identity is concerned, it is the same as an employee who goes rogue, and it gets the same kind of answer: least privilege, monitoring, audit.
Two things are different. An agent can be far more powerful than an employee. And unlike an employer, the company running an agent can know when it goes rogue: one large AI company already watches its own agents’ actions and stops some of them, though that is hard. Neither is something identity can address.
What is new, what is old
The plumbing is new: agents reach tools and data through the Model Context Protocol (MCP), and each other through agent-to-agent protocols. The proving is not. The standards bodies adapt what they already have: under MCP’s authorization specification, the agent obtains an access token from an authorization server through an OAuth 2.1 flow and presents it on later requests. That method was built for people.
The machine world settled this long ago. A workload proves itself with a cryptographic key, inside the channel, on every connection, and open standards such as SPIFFE made that routine. Machines, unlike people, can do cryptography.
The online world is a machine world
A person cannot be on the wire; only a machine can. So, identity systems prove a person with a gesture, such as a password, a code, or a tap, and then issue a token that speaks for them for hours, because nobody can be asked on every request. The token was a remedy for human friction, and the agent stack brought the remedy without the friction.
Would any organization give a trusted employee access from a laptop it knows is compromised? None would. So, identity online was never only the person: it is the actor, the platform it acts from, and the conditions under which the action is legitimate.
The industry only ever checked the user, and got away with it because a person stood behind the assumption and would notice when something went wrong. An agent removes that person.
Checking at the moment of access
What has to be checked is all three, at the moment of access. A token cannot: it is past tense, a record of a check made earlier that works for whoever holds it, wherever they are. A shorter lifetime moves the check closer, but never makes it a check made now.
Nor can the identity provider, which checked once, at login, and has not looked since. Nor can the server at the far end: it can verify what arrives signed, but not the state of the machine that sent it, or whether the conditions behind the request still hold. The check has to happen on the machine the actor works from.
Where the check can happen
For a person, that machine is the laptop or phone they work from. It is the one place that sees all three together, at the moment of access.
It can become an identity machine: it proves all three inside every connection, with a key that exists only there and only while the conditions hold. When one fails, the key no longer exists and access ends on the spot, with no message sent and no timer to wait for. For the person, it is also less work: after logging in to their own device, they see no more login prompts.
In identity terms, an AI agent is a person: it is the actor. Wherever it runs, the machine it runs on is its platform, and that machine can do the same job. Platforms that vouch for agents today do it when they issue a credential, which then works until it expires; an identity machine vouches at every connection and ends the agent’s access when a condition fails.
What is still open
People have always handed work to other people. What is new is the chain: a task can pass from one actor to the next, person or agent, each on its own platform, at machine speed, in many copies at once, along a path nobody chose in advance.
Each actor in the chain can prove its own three. What the model does not yet carry is the chain itself: when a condition fails for an actor earlier in the chain, say the one that started the task, every actor after it has to learn that in time, and today that takes a message to each one. That part is open, and the three-part identity will need refining to cover it.
Agents do not need an identity of their own
They need the definition of identity to be right: the actor, the machine it acts from, and the conditions under which the action is legitimate, proven together at the moment of access. The place to fix that is the machine the actor works from, and fixing it there covers employees, workloads, and agents alike. A second system for agents changes none of that; it keeps the old definition, with agents bolted on.
