The authority gap: why finding your AI agents is not the same as governing them

Every security wave of the last twenty years has started the same way: with an inventory. Directory cleanup projects. Privileged account discovery. SaaS shadow IT scans. Secrets scanning across repositories. And now, agent discovery. The pitch is always some version of the same sentence: you cannot govern what you cannot see.

That sentence is true. It is also the most expensive half-truth in the industry, because it lets an organization stop at the point where the real work begins.

The inventory reflex

The reason the inventory keeps coming first is not laziness. It is that inventory is the part of the problem that produces a deliverable. You run the scan, you get a number, you put the number on a slide, and the number goes down over the next two quarters. Everyone can point at progress.

With human identities, stopping at the inventory was tolerable for a long time, and it is worth being clear about why. At the other end of every human credential was a person with a manager, a job description, and something to lose. Authority was implicit. Nobody wrote down that the accounts payable clerk could approve invoices under a certain amount, because the clerk knew, the manager knew, and if the clerk got it wrong there was a person to have the conversation with. The access system only had to answer one question: does this login map to a real employee who should have this entitlement? The accountability question was answered elsewhere, by the organization itself.

Service accounts strained that arrangement, and the non-human identity market grew up to deal with the strain. But a service account executes fixed instructions, the same way, every time. If you know who owns it and what it can reach, you know most of what matters.

Agents break the arrangement completely. And discovery tools, however good they get, are built on the old assumption.

Permission is not authority

Once an agent is discovered, the next instinct is familiar to anyone in identity: make sure it has the right permissions. Those permissions may be inherited by associating the agent with a human identity, or they may be assigned directly to the agent. Either way, the permission becomes the ceiling of what the agent is technically allowed to do. If the agent has permission to issue refunds, access customer records, approve transactions, or modify an account, the control model is working as designed when it stays within those permissions.

The problem is that permission defines capability, not decision authority. A refund agent may legitimately have permission to issue refunds, but the business may only intend for it to refund up to a certain amount, remain under a daily limit, avoid accounts under fraud review, or escalate certain cases to a human. The credential and entitlement do not understand those boundaries. They simply determine whether the agent can call the refund function. As long as the action falls within its permission ceiling, the identity layer considers it authorized.

That creates a dangerous gap. An agent can make a series of individually permitted decisions that, collectively or contextually, exceed what the organization ever intended to delegate. Every API call can be valid, every entitlement can be correct, and every identity control can pass while the resulting decision is still unauthorized. Permission defines what an agent can do. Authority defines what it is allowed to decide, or better yet, what it is NOT allowed to do.

Why this matters now and did not before

Three things about agents make the gap dangerous in a way it was not for service accounts.

The first is that agents choose. A service account runs a script. An agent is given a goal and selects the actions it takes to reach it. The set of things it might do is not enumerated in advance, which means the set of things you need to constrain is not enumerated in advance either. You cannot govern a chooser by listing the scopes it holds, because the scopes describe the ceiling of what is technically possible, not the boundary of what was intended.

The second is that agents delegate. Increasingly, the thing calling your API is an agent that was invoked by another agent that was started by a workflow that a person kicked off at nine in the morning. Every link in that chain is a hop in an authority delegation, and every hop is a place where the authority can quietly widen. If you cannot trace a decision back to the human who authorized the chain, then nobody authorized it. The inventory will show you the last agent in the chain. It will not show you the first human.

The third is speed and volume. The traditional control for a human who might exceed their authority is review after the fact. Someone reads the report, notices the pattern, and has a conversation. Agents operate at a rate where the pattern is complete before anyone opens the report. Review after the fact still matters for accountability, but as a control it arrives too late to be one.

What governing actually requires

This is where I should be clear about what is established and what is my position. The three points above describe how agents differ from earlier machine identities, and I do not think they are controversial. What follows is my argument about what closing the gap requires. Reasonable people in this field weight the pieces differently.

Governing an agent, in my view, means four things that discovery does not do.

First, the agent's decision rights have to be derived from a human's. Not assigned to the agent as if it were an employee, but delegated from a person who holds that authority and remains accountable for it. If the chain of delegation cannot be traced back to a human, the agent should not be deciding.

Second, the constraints on those rights have to carry state across a run. A per-action check is necessary and nowhere near sufficient. The daily total, the cumulative exposure, the number of times a particular class of decision has been made in this session all have to be tracked as ledgered ceilings, so that the tenth refund is evaluated against the nine before it and not in isolation.

Third, escalation has to be defined before execution, and it has to go to an accountable human, not to a queue. When the agent reaches the edge of its authority, the system needs to already know who the decision belongs to and route it there. An escalation policy that is written after the incident is a post-mortem, not a control.

Fourth, every decision needs a record of its own. Not a log line saying an API was called, but a record of what was decided, under whose delegated authority, against which ceiling, and with what outcome. This is the artifact that makes accountability possible. Without it, when something goes wrong, the investigation ends at the identity and the answer is "the agent did it," which is not an answer anyone should accept.

Conclusion

Inventory, registration, and entitlement management is not full governance. It only governs what you know and, to the extent that the human-associated permission allows, what the agent can technically reach. It does not govern the authority for that decision.

Finding your agents is the first step. It was always only the first step. The industry has a habit of stopping there because the first step is the one that produces a number. Authority is harder to count. It is also the thing that actually matters.