Organizations investing in identity and access controls for AI agents must also make the decisions those controls are supposed to enforce:
- why an agent exists,
- within which bounds it may act,
- and who answers for it.
Technology can register, authorize, audit, and stop agents with increasing reliability. It cannot decide who is accountable for them. Organizations that stop at the technical layer will end up with excellent enforcement of decisions that nobody can explain or defend.
The accountability gap
The gap shows most clearly after an incident. Our Advisory Note When AI Agents Break the Security Model names four questions any auditor will ask:
- what did the agent run,
- what did it access,
- who authorized the agent and its access,
- and what did it do.
A well-built control plane can answer three of them from its own records. The question of authorization is of a different kind, and most organizations cannot answer it with confidence today.
The usual answer is the owner field in the agent management platform. In practice, that field contains the person who created the agent, typically a developer, a platform engineer, or the owner of the platform it runs on. This person knows how the agent works, but rarely why it exists in the sense in which a manager knows why a role exists in the organization. The owner field tells you whom to email when something breaks. When that developer changes teams, it points to nobody, and the agent keeps running.
The owner field tells you whom to email when something breaks. It does not tell you who answers for what the agent does.
Token-based delegation does not close this gap either. Token exchange can carry the acting party and even a nested delegation chain, and well-designed chains narrow authority at every hop. That chain, however, starts with whoever initiated a request. The person accountable for the agent’s business purpose, a service owner, a department head, or a risk owner, is rarely that initiating actor and therefore does not appear in the token. Neither does the decision that this agent may hold that authority in the first place.
Enforcement requires a decision
A policy engine can enforce a boundary, but it cannot decide who is accountable for setting it. Consider an agent that may place orders of up to EUR 10,000 per run. The control plane can enforce that limit perfectly. It cannot tell an auditor who decided on EUR 10,000, who may approve an exception, or who answers if the limit was wrong. A perfectly enforced policy can still rest on a decision that nobody actually made or owns.
A policy engine can enforce a boundary. It cannot decide who is accountable for setting it.
Closing the gap is organizational work, and none of it requires a new product category:
- A business-side owner who accepts responsibility for how an agent, or a class of identical agents, is used. One owner per class is sufficient only where the instances share purpose, authority, and risk. The same agent deployed in two business contexts may well need two owners.
- Purpose and bounds defined before the first credential is issued. Provisioning either establishes accountability or skips it, and retrofitting it later is considerably harder.
- A lifecycle tied to purpose. Nobody resigns on an agent’s behalf. The end of an agent’s purpose has to become the offboarding trigger, and the control plane has to enforce it through to delegated credentials, child agents, and queued actions.
Figure 1: Closing the accountability gap
A capable identity registry can hold this information. The demanding part is the governance process that produces it and keeps it current, and that process is human work.
Why the control plane alone is not enough
None of this diminishes the progress on the technical side. Vendors, standards bodies, consultancies, and analysts have published blueprints for agent identity that are largely coherent. Our whitepaper From AI Agents to Trusted Digital Workers describes the core capabilities: registering every agent as a first-class identity, issuing short-lived credentials per task, evaluating authorization at runtime and close to the action, maintaining an immutable audit trail, and stopping an agent that deviates from its expected behavior. Standards such as Rich Authorization Requests, DPoP, and token exchange are maturing in parallel. Organizations that build to such a blueprint are ahead of most.
These blueprints, however, assume a clean start: one platform, one identity provider, every agent registered at birth. Enterprises carry years of service accounts, scripts, RPA bots, pipelines, and OAuth grants in SaaS tenants, spread across subsidiaries, outsourced operations, and regulatory regimes. Most organizations were never particularly good at governing these existing non-human identities. Agents do not arrive in an empty room, and they inherit every accountability gap that already exists.
Figure 2: Key elements of an agent control plane
The question to start with
The control plane will keep improving, and organizations should continue to invest in it. The next real advance in agent governance, however, will come from decisions only the organization can make. Ownership and accountability stay human, even for agents that are numerous and short-lived, while enforcement can and should be automated. The first step is to review the agents already in production. For every new agent, one simple rule applies: no runtime credentials are issued until its purpose, its bounds, and an accountable owner are documented.
Organizations that stop at the technical layer will end up with excellent enforcement of decisions that nobody can explain or defend.
One question sums this up. Every employee has a manager who knows what they are there for, can tell them to stop, and notices when they leave. Who is your agent’s manager?
