This paper is written for the people who have to answer for what an AI agent does. The security leader who secures it, the identity leader who governs its access, the board member who carries the risk, and the engineer who builds it. It answers one question. When an agent takes an action, can you say which agent did it, on whose authority, and what else that agent was allowed to touch.
The Agent Identity Gap, Shadow Agency, the Agent Trust Lifecycle, Revocation Lag, Standing Agency, and the Agent Identity Index are original constructs of this work, published under the license on the back cover. They build on prior work on multi-agent governance [5] and on published research into how tool-using agents behave under attack [2][3][4]. Every quantitative claim is cited to a named source or labeled directional, without exception.
For twenty years the hardest question in enterprise security was simple to state. Who is this, and what are they allowed to do. We built an entire discipline to answer it for people and for the services they run. Then we gave software the ability to act on its own, and the question came back, unanswered, at a scale we have not built for.
An agent is not a feature inside an application. It is an actor. It holds credentials, it reaches into systems, it takes actions that carry consequences, and increasingly it creates other agents to help it. Each one is a new actor in your environment. Most programs still manage them the way they manage code, with a review and a deploy, when the honest comparison is to a new hire who never sleeps, signs in thousands of times a day, and can bring on assistants of its own.
This paper is my answer to the question I am now asked in every security review. Not whether to use agents, everyone is, but how to govern the identities they carry, so that every action traces to an actor, every grant is scoped to a task, and any agent can be cut off the moment it should be. The constructs are original work. The numbers are cited or labeled directional, without exception. I hold this to the standard of the rooms it will be read in.
The enterprise just added a new class of actor that acts without being asked, authenticates constantly, and can create more of itself. The question of who is doing this and what are they allowed to touch is an identity question, and most programs are answering it for agents the way they answer it for code. Five findings follow.
An agent is an actor, not a feature. The moment software can take actions on its own, which agent did it, on whose authority, and what else it could reach become identity questions. Governing an agent like a piece of code answers none of them.
An agent's authority can be commandeered. In a published benchmark of tool-using agents, an agent obeyed an instruction hidden in the data it read in 24 percent of attempts [2]. When that happens, your agent is doing someone else's work, with your permissions and your identity. The vector is demonstrated against real applications [3], and current defenses do not fully close it [4].
The gap is structural, and it grows. With organizations using AI past 78 percent [1], agents are added faster than identities are issued for them, and agents spawn sub-agents that inherit reach. The distance between the actors you can name and the agents actually acting is the Agent Identity Gap. The ungoverned part of it, running on borrowed, shared, or absent identity, is Shadow Agency.
The fix is a lifecycle, not a gate. The Agent Trust Lifecycle gives every agent a distinct identity (Issue), a grant scoped to its task (Scope), proof of what it is and may do (Attest), a live watch on its actions (Monitor), and a fast off switch (Revoke). Identity becomes a function that runs, not a checkbox at deploy.
You can close the gap in one quarter. A single program can move its highest-reach agents from shared credentials to distinct, scoped, monitored identities with a fast revoke path in about one quarter, with a small team. The work starts with an inventory of who is already acting.
For people, the enterprise knows the drill. Every person has one identity, a set of permissions scoped to their role, a manager who owns the account, and a way to switch it off the day they leave. Agents break every part of that model. One agent may run under a key shared with ten others. Its permissions are whatever the service account happened to have. Often no single person owns it. And when it misbehaves, there is rarely a clean, fast way to cut it off.
The risk is not theoretical. A tool-using agent takes its next action from whatever text lands in front of it, including text an attacker planted in a document, a web page, or an email it was asked to read. In a published benchmark, agents obeyed these injected instructions in 24 percent of attempts [2], and the same class of attack has been demonstrated against real applications [3]. When it works, the action runs under the agent's own identity, and the log shows the agent acting normally.
You stopped managing only the people who use the system. You now manage the software that acts inside it.
Every obeyed injection is an action taken under your agent's identity by someone who is not you. Exhibit 2 shows why the exposure widens over time rather than holding still.
Shadow Agency is not one problem. It is six recurring forms, each common, each fixable, and each closed by a stage of the lifecycle in Section 03. Naming them is the first step, because you cannot govern an actor you cannot see.
Many agents, and sometimes people, act under one key. No action traces to a single actor, so accountability dissolves.
The agent holds far more reach than its task needs. That is Standing Agency it will never use, but an attacker who takes the agent can.
The agent still acts, but no named person owns it or answers for it. When something goes wrong, there is no one to call.
There is no fast, clean way to cut the agent off. The Revocation Lag runs long, and the agent keeps acting while you scramble.
The agent acts, but the record cannot say which agent, on whose behalf, or under what grant. You cannot investigate what you cannot attribute.
The agent spawns helpers that inherit or widen its reach, uncounted and ungoverned, extending the perimeter without anyone deciding to.
Govern an agent the way you govern a person. Give it one identity, scope that identity to the task, make it prove what it is and may do, watch what it does, and keep a fast way to shut it off. Run the five together and they form a loop, because an agent changes over its life and its grant has to change with it.
| Stage | What it establishes | Shadow Agency it closes |
|---|---|---|
| Issue | A distinct identity for each agent, separate from people and from other agents | Shared Credential, Untraceable Action |
| Scope | A grant sized to the task, and to the agent's sub-agents, nothing more | Over-Scoped Grant, Sub-Agent Sprawl |
| Attest | A dated statement of what the agent is, who owns it, and what it may do | Orphaned Agent |
| Monitor | A live record of every action, the identity behind it, and the grant it used | Untraceable Action |
| Revoke | A fast, clean way to cut the identity off and confirm it is gone | Unrevocable Access |
The loop is what makes this a function rather than a checklist. Monitor is not the end. What it sees feeds back into Scope, narrowing a grant that turned out too wide, and into Revoke, cutting off an agent that has drifted from what it was attested to do. An identity issued once and never revisited becomes the Over-Scoped Grant of tomorrow.
The economics of agent identity are not about licenses. They are about three costs that only appear when something goes wrong, and that a governed identity turns from open-ended into bounded. The first is the reach an attacker inherits, set by how wide the grant was. The second is the time the agent keeps acting after you decide to stop it, the Revocation Lag. The third is the hours spent reconstructing which agent did what, paid in full when actions are untraceable.
You do not re-identity the whole estate at once. You start with the agents that act with the widest reach, bring them onto distinct scoped identities with a working off switch, and then extend the loop. The first phase is an inventory, because you cannot govern an actor you have not found.
Not every agent needs the full lifecycle. A read-only assistant and an agent that moves money are not the same risk. Four variables place any agent on one of four postures.
Does it act, or only advise? The moment it acts, identity stops being optional.
How many systems can its identity touch? Reach sets the blast of a single compromise.
Can it create or delegate to sub-agents? Spawning extends the perimeter on its own.
Can its actions be undone? The harder to reverse, the faster the revoke path must be.
The through line is simple. An agent that only advises needs little more than a named, scoped identity. One that acts, reaches widely, and spawns helpers needs the whole lifecycle. Match the posture to the agent, and you spend governance where the agency is.
The Agent Identity Gap is the distance between the actors you can name and the agents actually acting. The ungoverned part of it, running on borrowed, shared, or absent identity, is Shadow Agency.
| Probe | Question | Yes | No |
|---|---|---|---|
| 1 IDENTITY | Does every agent act under a distinct identity, separate from people and other agents? | ||
| 2 SHARED | Have you eliminated shared credentials across your acting agents? | ||
| 3 SCOPE | Is each agent's grant scoped to its task, not to whatever the account could do? | ||
| 4 SURPLUS | Do you know, per agent, the reach it holds but never uses? | ||
| 5 OWNER | Does every deployed agent have a named human owner accountable for it? | ||
| 6 ATTEST | Can you produce a dated statement of what each agent is and may do? | ||
| 7 SPAWN | Do sub-agents inherit a scoped grant, not their parent's full reach? | ||
| 8 TRACE | Does every action record which agent, on whose behalf, and under what grant? | ||
| 9 REVOKE | Can you cut any single agent off fast and confirm its access is gone? | ||
| 10 DRIFT | Do you re-scope or revoke when an agent drifts from what it was attested to do? |
The Agent Identity Index places you on the Agent Trust Lifecycle of Section 03. The stage you land on is the stage to finish before you climb.
This paper is a conceptual contribution. The Agent Identity Gap, Shadow Agency, the Agent Trust Lifecycle, Revocation Lag, Standing Agency, and the Agent Identity Index are original constructs of this work. They apply published findings about how tool-using agents behave, that an agent will obey instructions injected through the data it reads [2], that the attack works against real applications [3], and that current defenses do not fully close it [4], and they build on prior work on how authority and reach propagate across multi-agent systems [5]. Adoption figures are from the cited index [1].
Every exhibit is marked. Solid fill is cited data. Hatched fill is directional illustration, shown to make a mechanism legible, not to assert a measured value. Red marks ungoverned agency. The one hard rate in the paper, the share of attempts an agent obeyed an injected instruction, is cited to a named benchmark [2].
Arjun Jaggi, The Agent Identity Gap, Enterprise AI Research, White Paper No. 06, arjunjaggi.com, October 2026.
Arjun Jaggi writes and advises at the intersection of enterprise AI strategy, security, and governance. His work turns the hardest questions of running AI at scale into named frameworks that a board can decide on and a team can execute. Engage at arjunjaggi.com.