The AI Authority Layer: Who Decides What an Agent May Do

The layer nobody built

Enterprise architecture has clear answers for two of the three questions an agent raises.

Who is this? The identity layer. Mature, well-understood, decades of practice, an entire industry. Identity providers, directories, federation, lifecycle management.

What data exists and who may see it? The data-governance layer. Also mature. Catalogues, classifications, access reviews, lineage.

Who decided this agent may take this action? Silence. There is no layer, no owner, no register, and usually no artefact recording the decision — because in most cases no decision was made.

This is not an oversight so much as a novelty. Software has not previously needed one. A conventional application does what it was programmed to do, and the authority question collapses into a code review. An agent decides at runtime, from content that arrived at runtime, which means the question of what it may decide has to be answered separately from what it was built to do.

Three ways authority accumulates by accident

Nobody sits in a meeting and grants an agent the power to move money. It arrives sideways, through decisions that were each locally reasonable.

The common feature: in each route, the authority is real and the grant is absent. When something goes wrong, the question “who authorised this?” has no answer — not because records were lost, but because nobody ever made the decision that would have been recorded.

Four questions the layer answers

A functioning authority layer answers these for any agent action, in one query. They are also a reasonable audit script.

Who granted it, and did they have standing?

A named person, not a team, and one who actually held the authority they delegated. A platform engineer cannot grant an agent the power to issue refunds beyond their own limit — that is not delegation, it is invention. Standing is the check nobody performs.

Within what bounds?

Scope: which operations against which systems. Magnitude: how much, how many, how far. Both stated, and both narrower than the granting human’s own authority.

For how long?

An expiry. Authority with no end date is permanent authority held by software nobody reviews. Renewal is a two-minute conversation; the renewals nobody can justify are precisely the finding you want.

Who can withdraw it, and how fast?

A named party and a mechanism that works without a deployment. If revocation requires a release, it is not revocation — it is a change request with better branding.

The standing question is the one that turns this from bookkeeping into governance. In most estates, authority is configured by whoever has infrastructure access, which correlates poorly with who holds the business authority being delegated. Asking “did the granter have this authority to give?” surfaces that mismatch before an incident does.

Why authority cannot live in the model

There is a persistent hope that this resolves itself: models get better, become more reliable, and can be trusted to observe their own limits. It is worth saying plainly why that does not work, independent of how capable models become.

A component that can be argued with cannot hold the decision about its own limits. This is not a claim about current capability. It is structural: an agent’s usefulness comes from responding to information, and an instruction is information. Any component that updates its behaviour based on what it reads can have that behaviour updated by what it reads.

There is a second, quieter reason. Authority is a social fact, not a technical one. It concerns who in an organisation is answerable for an outcome. A model can be told about that structure; it cannot participate in it. When a payment goes wrong, the question is who is accountable, and a model cannot be accountable in any sense the organisation can act on.

So the authority layer sits outside the model necessarily, not provisionally. Better models make agents more useful and more trustworthy in practice. They do not move the location of the authority decision, any more than a more experienced employee removes the need for spending limits.

Assembling the layer from what you have

This is not a product to buy so much as a set of connections to make. Most of the pieces already exist somewhere in the estate; what is missing is that they are joined and owned.

The practical sequence is short. Pick your five highest-consequence agent capabilities. For each, write down the four answers — and where an answer does not exist, that is the work. Expect two or three of the five to have no identifiable granter, which is the finding rather than a failure of the exercise.

Then make the grant the mechanism: the entitlement is created by recording the grant, not documented after the fact. Coupling them is the only thing that keeps the record true, exactly as coupling registration to routing is what keeps a registry true.

The one-question test

Pick a single high-consequence action your agents can take. A payment, a deletion, an access grant, a customer-visible message. Ask one question: who authorised this agent to do that, and when?

Four possible answers, and only one of them is good.

“Nobody — it came with the credential.” This is the most common answer, and it means the authority is implicit. The capability is real and the decision was never made.

“The engineer who set it up.” Better, and it usually fails the standing test. An engineer configuring an integration is rarely the person who holds the business authority to move money.

“It is in a ticket somewhere.” A record exists but is not connected to the entitlement, so nothing keeps them in agreement, and they will diverge.

“This person, on this date, within these bounds, expiring then, revocable by that person.” That is an authority layer, and if you can produce it for every high-consequence capability you are ahead of nearly everyone.

The value of the test is that it takes five minutes and the result is usually uncomfortable enough to start a real conversation — which is more than most governance initiatives achieve in a quarter.

Glossary

AI authority layer

The architectural layer recording and enforcing who granted an agent its authority, within what bounds, for how long, and who may withdraw it.

Implicit authority

Capability an agent holds because of how it was configured, rather than because anyone deliberately granted it.

Authority grant

An explicit, recorded decision that a named agent may take a class of action within stated bounds, made by a named person with the standing to make it.

Standing

Whether the person granting authority actually holds the authority they are delegating — you cannot grant what you do not have.

Withdrawal path

The mechanism and named party able to revoke an agent’s authority immediately, without a deployment.

Sources and further reading

Governance and delegation frameworks are cited below for the general principles. The authority-layer framing, the four questions and the implicit-accumulation analysis are our own, and this is a category argument rather than a description of established practice.

1. 01 · NISTNIST SP 800-207 — Zero Trust Architecture ↗The policy decision point / policy enforcement point split this architecture borrows directly.
2. 02 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
3. 03 · NISTNIST AI Risk Management Framework ↗Govern-map-measure-manage; the vocabulary most enterprise AI risk programmes are written against.
4. 04 · ISOISO/IEC 42001 — AI management systems ↗The management-system standard auditors increasingly map AI governance evidence against.
5. 05 · EU AI Act (unofficial consolidated text)EU AI Act — full text ↗Obligations around logging, human oversight and traceability for higher-risk systems.
6. 06 · ISACACOBIT 2019 Framework ↗Governance and management objectives, including segregation of duties.
7. 07 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
8. 08 · OWASP GenAI Security ProjectOWASP Agentic AI — Threats and Mitigations ↗Threat taxonomy specific to tool-using agents rather than to chat completions.

Last reviewed 2 September 2026. External links open in a new tab; we do not control their content.