Identity is half the problem

Most teams running AI agents in production can already answer one question cleanly: which agent did this? A service account, an API key, or a signed credential ties an action back to the process that took it. That is genuine progress over the early pattern of one shared key passed between every script in a pipeline, and it is where most identity work in this space has focused.

It is also only half the problem.

Knowing which agent acted tells you who to hold accountable after the fact. It does not tell you, at the moment the agent reaches for a tool, whether that specific action was something it should have been allowed to do. A coding agent with read access to a repository and a coding agent with write access to its main branch can hold the exact same identity. An agent that is meant to draft a pull request and an agent that is meant to merge one are, in most setups today, indistinguishable once you are only asking “who is this?”

The gap between identity and authority

The distinction matters because the two questions fail differently. An identity check fails by letting an impersonator in: someone who should not be able to act, acting under a name that is not theirs. An authority check fails by letting the right actor do the wrong thing: an agent that is unambiguously itself, correctly identified, doing something nobody intended it to be able to do.

A thirty-agent deployment, each agent doing something narrow such as reviewing pull requests, filing tickets, or summarising logs, does not have an impersonation problem most of the time. It has an authority problem. The agent that reviews pull requests should never be able to push to main, not because its identity is in doubt, but because reviewing and merging are different actions and only one of them should ever be open to it. If the system only checks identity, that boundary exists as a convention, in a runbook or a comment, rather than as something enforced at the moment the tool is called.

This is not a hypothetical gap. It is the shape of the question practitioners actually ask once they move past a handful of agents: tie identity to a role, tie the role to permissions at the level of individual tool actions, read versus write versus replace, a reviewer that may comment on a pull request but never merge one, decided the same way every time, and checkable before the tool call happens rather than reconstructed afterwards from a log.

Why “per agent” permission does not scale

The natural first answer is to give each agent, or each class of agent, a fixed set of permissions when it is provisioned. That works for a handful of agents and starts to strain as soon as the roster grows past what one person can hold in their head. Two problems show up quickly.

The first is drift. An agent provisioned for one task picks up a broader set of tools over time, because someone added a connector it needed for a one-off job and nobody removed it afterwards. The permission the agent holds stops matching the job it is actually doing, and nothing in the system notices, because the check at the identity layer never asked what the agent was about to do, only who it was.

The second is that a fixed permission set per agent does not compose. A real deployment has agents that delegate to other agents: an orchestrator that spins up a worker for a sub-task, a reviewer that asks a narrower checker to look at one file. If delegation exists at all, the question of what the child agent is allowed to do has to be answered in terms of what the parent was allowed to do and chose to pass on, not as a separately maintained list that someone has to keep in sync by hand.

Deciding per action, not per agent

The alternative is to decide authority at the point a tool is actually called, not once at provisioning time. That means three things have to be true.

First, the vocabulary of actions has to be closed and specific enough to mean something. “This agent can write” is not a decision a reviewer can audit; “this agent can write to a pull request branch but not to the default branch” is. A permission model that is a free-text string, filled in differently by whoever wrote the integration that week, cannot be checked consistently, because the thing being checked against does not mean the same thing twice.

Second, delegation has to be able to narrow permission and nothing else. When one agent spins up another, or hands a sub-task to a worker, the child’s authority should never be able to exceed what the parent held. This has to be enforced at the point delegation happens, not left to the good judgement of whoever wrote that particular integration, because the integrations are exactly where the shortcuts get taken under deadline pressure.

Third, the decision has to be made at the moment the tool is called, inside the path the agent cannot route around, not inside the model’s own reasoning. A model can be told not to merge to main in its system prompt, and most of the time it will listen. “Most of the time” is not the same guarantee as a check that sits between the agent and the tool and returns a plain allow or deny before the call goes through. The difference only shows up on the day a prompt is misread, a model is updated, or someone points a slightly different harness at the same tools, and by then the point of having a check at all was to not be depending on that day going well.

What this changes in practice

None of this argues against strong identity. A verifiable, signed identity is the foundation the rest of this stands on: you cannot decide what an action is allowed to do if you cannot first be sure which agent is asking. The point is that identity is a precondition for the decision, not the decision itself. Once you can verify who is acting, the next question, and the one that actually governs what happens in production, is what that identity’s badge says it may do, checked against the specific action it is attempting, every time, before the tool runs.

Teams that are serious about letting agents touch production systems are already asking this question in exactly this shape: identity, tied to a role, tied to permissions at the level of individual tool actions, decided deterministically, and checkable through one call any harness can make before the agent’s next move. Getting the identity half right is necessary. Getting only the identity half right is not enough.