01
AI inventory. What AI systems exist, who owns them, and how risky each one is.
Foundational layer
The Authorization Layer
The layer beneath the stack.
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.
Most AI governance frameworks manage what happens after a system is approved; the Authorization Layer asks who approved it to operate in the first place.
Inventory the systems.
Govern the data.
Control access.
Assure the models.
Keep humans in oversight.
Audit against the regulations.
The frameworks are good and the layers are real. They share one assumption. Each layer takes for granted that someone already decided this system was allowed to operate, defined what it was allowed to do, and accepted responsibility for what it produces. That decision is a layer too. It sits underneath all the others, and in most organizations it was never designed. Naming this layer does not demote the others. Risk assessment, fairness, robustness, data governance, and incident management are first-class obligations in their own right; this library supplies the decision record those functions assume, and substitutes for none of them.
CITE OR DOWNLOAD
The compiled framework library.
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.
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.
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.
Assumption
The decision every layer assumes.
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.
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.
The operational layers tell you the system is behaving. The authorization layer tells you it was ever allowed to.
RUNTIME ENFORCEMENT
A note on enforcement.
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.
Authorization sequence
The layer is a sequence, not a slogan.
The work moves from naming the risk to diagnosing the gap, authorizing the system, operating the record, and preserving evidence.
01Core concepts
Name the risk.
The language that makes the authorization failure visible before it becomes an incident.
02Diagnose frameworks
Diagnose.
Measure the gap between what is deployed and what was actually authorized.
03Authorize frameworks
Authorize.
Make and record the decision before go-live.
04Operate frameworks
Operate.
Keep authorization current as the system and the organization change.
05Agent Authorization Document
Keep the record.
Turn the decision into the evidence an examiner reads.
Sequence
Why this comes first.
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.
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
v1.2, July 2026: added Zenodo publication of The Authorization Layer, DOI 10.5281/zenodo.21245690.
v1.1, July 2026: Added runtime enforcement, control stack placement, and clarification that the Authorization Layer supplies the decision record other governance functions assume.
v1.0, July 2026: Original publication.
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.