Pull the audit log for the last purchase order your agent placed.

Whose name is on it?

In most enterprises running agents today, the answer is a person. Sometimes a person who was on vacation that week. Sometimes a service account created in 2019 by an engineer who has since left. Occasionally an integration user with a name like svc-erp-prod that nobody can account for and nobody dares disable.

What the log will not say is: an agent did this. Because as far as your identity system is concerned, no agent did anything. Agents do not exist in it.

Agents are not a principal type

Every enterprise identity model recognizes two kinds of actor. There are humans, who authenticate, hold roles, and are accountable. And there are service accounts, which are non-human identities that let systems talk to systems, and which are deliberately broad because they were designed to be plumbing, not decision-makers.

An agent is neither of these, and that is the whole problem.

It is not a human. It does not authenticate, it does not have a manager, and it cannot be held accountable in any meaningful sense. But it is also not plumbing. It makes decisions. It selects a supplier, sets a quantity, judges whether a return is resaleable. A service account moving a file between systems is not exercising judgment. An agent placing a purchase order is doing very little else.

So when a team deploys an agent, they face a practical question with no good answer: what does it act as? And the path of least resistance is always the same. Give it a service account, or let it act on behalf of a human who has the permissions it needs.

That is borrowing. And it is the default, not a mistake. Nobody decided to do this. It is simply what happens when you deploy a new kind of actor into a model that has no category for it.

What borrowing actually costs you

Three consequences follow, and they compound.

Authority becomes all-or-nothing. Permissions in an identity model are shaped around roles, because roles were designed for people. A procurement analyst can acknowledge purchase orders, modify order terms, add suppliers to the approved list, and initiate returns, because a human in that job needs all of those, and a human exercises judgment about which one is appropriate. Hand that role to an agent and the agent inherits every one of those capabilities, in every situation, whether or not its workflow calls for it.

The agent that was deployed to acknowledge routine POs can now modify order terms. Not because anyone granted that. Because nobody drew a smaller box.

Attribution breaks. This is the one that surfaces in the audit log. If an agent acts through a borrowed credential, every action it takes is recorded as an action by the credential's owner. Your log is not wrong, exactly. It is just describing a world that no longer exists, one in which the entity that clicked and the entity accountable are the same entity.

Now ask what happens when something goes wrong and someone has to reconstruct it. You cannot filter for what the agent did, because the agent is not a thing in the data. You cannot tell an agent's action from a human's. You cannot answer the first question any regulator, auditor, or incident review will ask, which is who did this, and you cannot answer the second one either, which is who authorized them to.

Revocation gets slow. When an agent's authority needs to change, either tightened after a near-miss or widened after it proves out, how is that change made?

If the agent's authority is a property of a borrowed role, then changing it means changing the role, which means changing what a human can do, which means a conversation with the people who own that role, and probably a ticket, and probably a release. Meanwhile the agent keeps acting. The gap between we should narrow this and this is narrowed is measured in sprints.

An authority you cannot revoke quickly is not a control. It is a hope.

The escalation nobody watches

There is a fourth consequence, and it is quieter than the others.

Agents invoke other agents. They invoke tools. They call downstream systems. And in most deployments, when agent A calls agent B, nothing constrains agent B to the authority that agent A was operating under. B has its own credential, which may be broader, and it will happily do the thing it was asked to do.

You have granted agent A a narrow scope. Agent A, entirely within its scope, asks agent B for something. Agent B, with a wider scope, does it. The action that lands in the system is one that agent A was never permitted to take, and no rule was broken anywhere in the chain.

This is privilege escalation through composition, and it does not look like an attack. It looks like a working system.

What the fix actually is

Make agents a principal type. Not a workaround, not a naming convention on a service account. A first-class, distinct kind of actor in the identity model, with its own credentials, its own scope, and its own name in the log.

Once an agent is a principal, three things become expressible that were not expressible before.

Authority scoped per workflow, not per role. The question stops being "what can this agent's role do" and becomes "what may this agent do in this workflow." The same agent, running an inventory replenishment task, gets a different grant from the one it gets running a supplier communication task. Roles cannot express this, because roles are about people, and a person carries the same permissions from task to task and uses judgment to decide what is appropriate. An agent has no such judgment, so the boundary has to be in the grant.

Three boundaries, drawn per workflow. For every workflow an agent touches, exactly three things need deciding:

  • What may it execute autonomously, with no human in the loop
  • What must it propose for approval, with a human confirming inside a defined window
  • What must it escalate, where no autonomous action is permitted regardless of urgency or volume

This is a small model, and it is deliberately small. Most teams, asked to define agent governance, produce a document. Asked instead to fill in three columns for each of their live workflows, they produce something enforceable, and they usually discover in the process that they cannot agree on where the lines go, which is itself the finding.

Two delegation patterns, and they are not interchangeable. An agent can act in one of two modes, and conflating them is a common and expensive error.

User-delegated: the agent acts on behalf of a specific person, and its authority is bounded by that person's authority. It can never exceed what its principal could have done directly. The human is present in the chain, and accountability flows to them.

Tenant-owned: the agent acts for the organization, not for any individual. Its authority is granted directly, to it, and it does not inherit from anyone. Accountability flows to whoever configured the grant.

Both are legitimate. They are appropriate in different places. What is not legitimate is being unclear about which one you are running, because the accountability chain is entirely different in each, and you will discover which one you were actually running at the worst possible moment.

And the grant is evaluated at action time. Authority checked once at deployment and then assumed is not authority. It is a memory of authority. The check belongs at the moment of the action, against the current grant, so that a change to the grant is a change to what the agent can do, immediately, without a deploy.

Why this is the first control, not one of many

There is a reasonable objection here, which is that authorization is one of several things an agent program needs, alongside data quality, observability, escalation design, and incident response. That is true. It is also the wrong way to sequence them.

Authorization is the control that bounds every other risk.

An agent cannot take an action it lacks the authority to take. So the blast radius of any failure, including failures in the other controls, is capped by the grant. A model that hallucinates a supplier cannot onboard one if onboarding is escalate-only. A data error that produces an absurd reorder quantity cannot commit if the quantity exceeds the execute threshold. Bad data plus bounded authority is a caught error. Bad data plus borrowed authority is a purchase order.

Everything else in a governance program tells you what happened, or helps you decide what should happen. Authorization is the only control that determines what can happen. It is the one that has to come first, and it is the one that is almost always deferred, because it touches the identity system and the identity system is owned by a team that did not ask for any of this.

Which brings us back to the audit log.

Someday, someone is going to pull it. It might be a regulator. It might be an auditor. It might just be you, at 2am, trying to work out how a thing happened. And when they ask which of your agents did this, and under what authority, you will either be able to answer, or you will be explaining that the log says a person did it, and the person was on vacation.

The question is not whether the agent had permission. It is whether you can say whose permission it was using.