One page
The Authorization Layer, on a single page
What it is, when to use it, and the one action it produces. v1.0, July 2026. The same text as this page, laid out to print or share.
Foundational layer
The Authorization Layer
The layer beneath the stack.
The operational stack covers inventory, data, access, model assurance, oversight, and audit. Each layer assumes someone has already decided that an AI system may act, defined what it may do, and accepted accountability. The Authorization Layer is that decision and its record, beneath the operational controls. It gives those controls something clear to govern; it does not replace risk assessment, fairness, security, oversight, or compliance.
Foundation layer
Operational controls need an authorization record underneath them.
Inventory, data, access, model assurance, oversight, and audit all assume the same prior decision: this system was authorized to operate.
Read the framework abstract
Most AI governance frameworks manage what happens after a system is approved. Each operational layer, covering inventory, data foundation, data security and access, model assurance, human oversight, and compliance and audit, assumes that someone already decided the system was allowed to operate, defined what it was permitted to do, and accepted responsibility for its outputs. That decision is itself a layer, it sits beneath all the others, and in most organizations it was never designed. This framework library defines the authorization layer as a sequence of design decisions and records that must exist before the operational layers have anything to govern. The sequence moves from naming the risk, through diagnosing the gap between deployment and authorization, to authorizing the system, operating the record, and preserving evidence. Fifteen artifacts are compiled here, including diagnostic instruments, authorization frameworks, operating controls, and the Agent Authorization Document that turns the decision into examiner-ready evidence. The library extends control structures regulated organizations already run rather than standing beside them: the intake gate operates inside existing change management, the disposition protocol extends the incident management runbook, and the authorization record is control evidence in the GRC system of record. Runtime enforcement tools encode authorization decisions; this library governs the decision those controls enforce.
CITE OR DOWNLOAD
The compiled framework library.
About this publication
All fifteen artifacts in this library are compiled into a single citable document, The Authorization Layer: The Enterprise AI Agent Governance Framework Library, v1.0, published on Zenodo under DOI 10.5281/zenodo.21245690 (CC BY 4.0, July 2026).
Suggested citation
Roy, S. (2026). The Authorization Layer: The Enterprise AI Agent Governance Framework Library, Version 1.0. Zenodo. https://doi.org/10.5281/zenodo.21245690
Operational stack
What most frameworks govern.
Read the layer-by-layer explanation
01 · AI inventory.
What AI systems exist, who owns them, and how risky each one is.
02 · Data foundation.
Where the data comes from, whether it is accurate, and whether it carries bias.
03 · Data security and access.
Who can reach the data and under what controls.
04 · Model assurance.
Whether the model performs, stays fair, and holds up over time.
05 · Human oversight.
When a person reviews, escalates, or overrides what the system does.
06 · Compliance and audit.
Whether the whole arrangement satisfies the regulators and leaves a trail.
The common model of AI governance is a stack of operational layers. Each one answers a real question and each one matters. Run all six well and the organization still cannot answer one question: who decided this system should operate at all, and where is that written down.
Assumption
The decision every layer assumes.
The operational layers tell you the system is behaving. The authorization layer tells you it was ever allowed to.
Read the full explanation
Model assurance assumes someone defined what the model is for. Human oversight assumes someone decided which choices require a person. Compliance assumes someone accepted accountability for the outcome. Each operational layer is built on a decision that happened, or should have happened, before the layer was designed.
In most enterprises that decision is missing. The closest thing to it is a procurement approval that cleared the system to be purchased. That approval rarely defines what the system is allowed to do or who answers when it does the wrong thing. The record is necessary and not sufficient: the operational layers of governance remain obligations in their own right. Without the record, none of them can show the system was ever allowed to act. Access was granted. Authorization was assumed.
This is the pattern across regulated AI deployment. The operational controls are mature and the authorization record does not exist. A monitoring dashboard can have every alert configured, with no document naming who approved the agent to act in the first place. The remediation costs months. The original decision would have taken under an hour to write down.
View the companion illustration
Assumed decision
Controls can be mature while the original decision is missing.
The difference is not more monitoring. It is whether accountability was recorded before the system began acting.
RUNTIME ENFORCEMENT
A note on enforcement.
Read the enforcement note
A growing class of tools enforces authorization policy at runtime: execution boundaries, pre-action checks, admissibility gates, and control specifications such as Microsoft's Agent Control Specification, published June 2, 2026, which enforces policy at five checkpoints in the agent lifecycle: input, model call, state transition, tool execution, and output. Those controls are necessary and this library assumes they will mature. They also assume something. An execution boundary is the encoding of an authorization decision. If the decision was never made and recorded, the boundary enforces a policy nobody approved, and the examiner's first question still has no answer. The frameworks on this site govern the decision the runtime controls enforce, upstream of the enforcement layer.
Layer contents
What this layer is made of.
The authorization layer is a sequence of design decisions and records that have to exist before the operational layers have anything to govern. The framework library on this site is the design work for that layer, organized in the order the work happens.
Sequence
Why this comes first.
Read why the order matters
An organization can build the full operational stack and still fail the first question a regulator asks. The controls may be strong, but they govern a system no one formally authorized. Authorization comes before the operational layers are running. It is the decision the operational layers exist to enforce. Build it first and every layer above it has something real to govern. Skip it and the rest is a well-instrumented record of a decision nobody made.
CONTROL STACK
Where this sits in what you already run.
Read how the integrations work
This library extends control structures most regulated organizations already run; it does not stand beside them. The intake gate operates inside existing change management: an agent deployment is a change, and the authorization record is the evidence the change advisory board files. The Disposition Protocol extends the incident management runbook with AI-specific triggers, clocks, and decision windows. The Agent Authorization Document is control evidence in the GRC system of record, on the same shelf as model risk documentation, carrying a control identifier, with the agent's risk tier feeding the deploying business unit's entry in the enterprise risk register. An organization that builds this library as a separate governance universe has misread it.
Revision history
What changed in this framework
Framework library
Start with the layer the stack assumes.
The framework library turns authorization from an assumption into a record, a sequence, and a governance habit.