The Agent Governance Stack: Why Authority Comes Before Capability.
Ten layers, and capability is the fourth. Most teams start at the fourth and infer the other nine from whatever the integration happened to need.
The stack
An agent governance stack has ten layers:
identity → purpose → authority → capabilities → policy → memory → evidence → action → verification → escalation
Identity. Who this agent is, and on whose behalf it acts. Not a service account shared by four workflows. A distinguishable principal, because everything downstream is attribution.
Purpose. What it exists to do. This bounds scope before permissions are discussed at all, and it is the cheapest constraint available.
Authority. What it may decide alone, what it must escalate, what it may never touch. Written down before any tool is connected.
Capabilities. The tools it may invoke. This is layer four, and it is where nearly every implementation actually begins.
Policy. The rules in force at the moment it acts, versioned, so that "which rule applied" has an answer months later.
Memory. What it retains, for how long, and who can see it. Every retention decision is a liability decision taken on behalf of a future legal team.
Evidence. What it leaves behind. Generated as it runs, not assembled afterwards by somebody preparing for a review.
Action. The effect on the world. The only layer most monitoring watches.
Verification. Confirmation the action was correct, performed by something that cannot be influenced by the actor. Verification you can influence is not verification. It is a second opinion from yourself.
Escalation. Where it stops and hands to a named human, with context attached, rather than proceeding on a best guess.
Why the order matters
Capability demos well. Authority does not demo at all, which is why it loses every prioritisation argument it enters.
So the sequence in practice runs backwards. Somebody wires the agent to a tool, discovers it needs credentials, grants whatever the integration asks for, and the authority model becomes an accident of the integration's requirements. Nobody decided the agent could read the whole customer table. It simply could, because that was the credential to hand.
What that produces is not an agent. It is an unbounded principal with a very good interface.
Designing in stack order costs a day at the start. Discovering the boundary during an incident costs considerably more, and you do not choose the date.
The test
Three questions, and you can answer them about any agent already in production.
What may this agent decide alone? If the answer is a paragraph rather than a list, it is not a boundary.
What must it escalate? If the answer is nothing, there is no escalation path, only a failure path.
What may it never touch regardless of how confident it sounds? If nobody can name that set, the agent's authority is whatever its credentials happen to permit.
An organisation that cannot answer those does not yet have an agent governance problem. It has an agent authority problem, and it becomes a governance problem the first time the agent is wrong.
What this is not
It is not a maturity model, and it is not sequential in the sense of finishing one layer before starting the next. Real systems iterate.
It is an argument about which decisions are load-bearing. Identity, purpose and authority constrain everything below them. Get them wrong and the remaining seven layers are implemented against the wrong boundary, correctly and expensively.
Capability is what it can do. Authority is what it is permitted to decide. Only one of those is yours to set, and it is the one that decides what the day after looks like.
© 2026 Nabeel Khan. The Agent Governance Stack: Why Authority Comes Before Capability is published under CC BY-NC-ND 4.0. Quote it, cite it, do not repackage it.