The Authorization Gap

Why AI governance is an enforcement problem, not a monitoring problem.

Authorization requirements are often addressed through monitoring or observability. Systems are watched. Logs are kept. Behavior is sampled, summarized, and reviewed. None of this prevents an AI system from taking a consequential action. Monitoring records what happened. Observability describes what is happening. Neither makes a decision before the fact.

FERZ treats the authorization problem as an enforcement problem. A non-bypassable runtime authorization layer evaluates each AI action against encoded policy before execution. Decisions are deterministic. The authorization gate is structurally independent of the system it governs. Each verdict is represented in a tamper-evident authorization artifact. The corresponding vendor-neutral evidence object in 5TS is a Proof-Carrying Decision. When governance conditions are not met, execution is blocked rather than allowed to proceed.

This framework was developed by FERZ in a corpus of published papers, beginning with On the Impossibility of Observability-Based Authorization (Meyman, 2026).

The Three Problems

Three distinct problems are routinely conflated under the heading of AI governance: visibility, alignment, and authorization.

Visibility concerns what an AI system is doing. It is addressed by monitoring and observability tools.

Alignment concerns whether an AI system is pursuing the right objectives. It is addressed by training-time and design-time work.

Authorization concerns whether an AI action is permitted to occur. FERZ addresses this problem through a non-bypassable runtime authorization boundary.

These categories are not interchangeable. A consequential deployment whose requirements call for all three needs each addressed on its own terms. Confusing them is a recurring source of category error: governance programs that measure visibility or alignment and conclude that authorization has been handled.

Position

Three positions sit at the foundation of the FERZ framework.

The Result

It might be tempting to assume that with enough monitoring data, enough patterns recognized, enough behavior baselined, a monitoring system could approximate authorization. The impossibility result rules this out structurally. The argument does not depend on the volume of data, the precision of the model, or the latency of the alert. It depends on what a decision is.

The impossibility result formalizes the structural limitation: an observation-class system cannot, by itself, produce an authorization-class decision. The full argument is in On the Impossibility of Observability-Based Authorization (Meyman, 2026). The summary is short.

Authorization is a decision about whether an action may execute. The decision must precede the action; otherwise it is a record, not a decision. The decision must be reconstructable from policy, action specification, and governed state; otherwise it is an assertion, not an authorization. And the decision must hold even when conditions are uncertain; otherwise it is a guess that happened to be right.

Observation-class systems do not meet these conditions. They watch. They sample. They aggregate. They alert. None of these operations resolves the question of whether a proposed action is permitted, because none of them produces a verdict before execution. A faster monitoring system is a faster monitoring system. A more accurate monitoring system is a more accurate monitoring system. The architectural class does not change.

In regulated environments, the relevant demand increasingly becomes ex-ante evidence: evidence, before the fact, that an AI action was authorized. Monitoring-class architectures cannot supply that evidence through monitoring alone, not because monitoring is useless, but because monitoring is not the category of system that emits authorization verdicts.

The accountability question follows from the result. When an AI action goes wrong, who decided it could happen? In a monitoring-class architecture, the answer is unsatisfying: the architecture supplies no pre-execution authorization verdict. The system was watched and the action was logged, and whatever decision was made lives implicitly in the gap between what the monitoring tool saw and what the operator did about it. In an authorization-class architecture, the answer is concrete: a verdict was emitted, a policy was applied, an artifact records both. Accountability has a referent because the decision has an artifact.

The Diagnostic

The impossibility result has a practical consequence. Any architecture claiming AI-action authorization can be evaluated against two structural conditions, formalized in The Authorization Artifact Test (Meyman, 2026). The test is regime-neutral, derived from the impossibility result, and does not depend on which vendor or stack is being evaluated.

Prong One: Pre-Execution Verdict. Does the runtime authorization boundary emit a verdict before the proposed action executes? If the verdict arrives after execution, it is a record of what happened, not a decision about what was permitted. The temporal ordering is structural.

Prong Two: Independent Reconstruction. Can an independent third party reconstruct that verdict without access to the governed system? If reconstruction requires running the original system, the record is the system's assertion about itself, not evidence a third party can confirm. The authorization artifact represents the verdict and carries the bound material necessary for reconstruction: the verdict is independently reconstructable from the bound inputs, the policy and version state that applied, the authority chain, and the proposed action, and the origin of the inputs on which it rests is established. Reconstructability is what separates authorization artifacts from logs.

An architecture is an ex-ante authorization architecture only if both prongs are satisfied. Architectures that satisfy one prong but not the other are not partial authorization. They are something else: monitoring with timestamps, or replay infrastructure without policy, or alert pipelines with audit retention. Useful, but not authorization.

The test is silent on quality. An architecture can satisfy both prongs and still encode bad policy, miscalculate state, or have an unreliable evaluator. The test is silent on quality because it is structural: it answers whether the architecture is the kind of system that emits pre-execution verdicts represented in reconstructable authorization artifacts, not whether the policy those verdicts apply is good. Quality is a separate question, addressed by the work of policy encoding, state modeling, and evaluator implementation.

The test exists because the question “is this AI governance?” admits too many answers in current practice. The test is what FERZ uses to position itself against adjacent categories. It is what the comparison pages apply systematically.

The Architecture

FERZ implements AI-action authorization as a runtime authorization boundary at the AI action proposal point. The architecture has six commitments. None is configurable; each is part of what the architecture is.

Action canonicalization. Before a proposed AI action can be evaluated by policy, it must be canonicalized: transformed into a stable, structured representation that uniquely identifies the operation, its parameters, and its context. Without canonicalization, the same semantic action expressed in different surface forms would yield different verdicts. The formal treatment is in Versioned Meaning, Auditable Records, Stable Ontologies (Meyman, 2026).

Governed state. Policy does not evaluate actions in isolation; it evaluates them against the state of the governed system. The governed state is structured, versioned, and carried in the resulting artifact. Policy evaluation takes the canonicalized action specification and the governed state as inputs.

Verdict space. The canonical verdict space contains three verdicts: ALLOW, DENY, and ABSTAIN. There is no separate ESCALATE verdict. ALLOW permits execution. DENY blocks it. ABSTAIN blocks execution pending authorized human override.

Fail-closed design. When governance conditions cannot be resolved, execution is blocked by default. This is an architectural commitment, not a configuration. There is no opt-in setting for fail-open behavior.

Authorization artifacts. An authorization artifact is a tamper-evident record that represents a verdict such that the verdict is independently reconstructable from the bound inputs, the policy and version state that applied, the authority chain, and the proposed action, and such that the origin of the inputs on which it rests is established. FERZ represents every verdict in such an artifact. The formal name is “proof-carrying authorization artifact”; in practice the shorter “authorization artifact” suffices.

The override path. ABSTAIN blocks execution. It covers two cases: the indeterminate case, where the applicable authorization state does not resolve the proposed action, and the authority-required case, where the governing policy reserves the action or action class for a named human authority. In both, an authorized human resolution supplies authority-bound input to the runtime authorization boundary. The boundary evaluates that input and emits the resulting ALLOW or DENY verdict for the held action. Execution depends on that affirmative, action-bound verdict, which is represented in an independently reconstructable authorization artifact carrying the authority chain. Any policy amendment is a separate, independently authorized act. This sequence is what distinguishes ABSTAIN with authorized resolution from review-only human-in-the-loop, in which a human determination is consumed by the surrounding workflow and recorded but no boundary verdict is produced; the distinction is developed in Override Asymmetry (Meyman, 2026), and it is what distinguishes ABSTAIN-with-authorized-override from human-in-the-loop workflows. In HITL, humans make decisions routinely; in FERZ, humans are invoked only at the ABSTAIN boundary, and their overrides leave evidence.

The six commitments interlock. Action canonicalization gives policy a stable target. Governed state gives policy something to reason against. The three-verdict space gives policy something to emit. Fail-closed design gives the system a default that does not require ongoing operator vigilance. Authorization artifacts give third parties a verdict they can reconstruct. The override path closes the loop for cases policy does not resolve or reserves for human authority.

These commitments are designed to satisfy both prongs of the Authorization Artifact Test: a pre-execution verdict and independent reconstruction. They are not additions to a monitoring or policy infrastructure; they define a different category of system.

The Position

FERZ treats AI-action authorization as a distinct architectural category, not as a renamed version of monitoring, IAM, policy engines, or human review. It does not replace monitoring, observability, identity authorization, attack detection, content filtering, or human review. It sits at a structurally different point in the system: at the AI action proposal boundary, before execution.

Adjacent categories are composable, not substitutable. AI Observability watches what AI systems did; FERZ decides whether they may. IAM authorizes identity-to-resource access; FERZ authorizes AI-action execution. SIEM aggregates post-hoc events; FERZ emits ex-ante verdicts. RASP-class tools detect attacks; FERZ enforces policy regardless of whether anything is an attack. Policy engines evaluate caller-supplied rules; FERZ supplies the architectural commitments that turn policy evaluation into authorization. The architectural comparisons describe each contrast in detail.

Adding labels, policy features, or intervention logic to an adjacent system does not move it across the architectural-class boundary. The boundary is not a feature gap; it is a difference in what kind of decision the system makes, what artifact it produces, and what failure mode it exhibits. An adjacent system crosses the authorization boundary only by adding a non-bypassable, fail-closed pre-execution authorization function whose action-bound verdict conditions execution and is represented in an independently reconstructable authorization artifact. An architecture that adds that function is a composite architecture with a genuine authorization layer; the architectural commitments above are what that layer consists of.

FERZ publishes the Five Tests Standard (5TS), a vendor-neutral published standard, so any vendor can be evaluated against the same structural conditions the standard formalizes. The standard is available at github.com/edmeyman/4ts-standard. The specification is licensed under CC BY-NC-ND 4.0, and the conformance bundle is licensed under MIT. Adoption of the standard does not require adopting FERZ; satisfying the current conformance bundle requires satisfying the testable conditions the standard defines. The repository release is v1.2.2; the specification is v1.2.0; the conformance bundle is v1.0.2. In specification v1.2.0, Provenance is normative, while Provenance conformance and full five-test conformance are not yet assertable; the conformance bundle verifies Stop, Ownership, Replay, and Escalation. Current status is maintained in the repository.

The corpus is published. The standard is published. The architecture is documented. What remains is the work of building and deploying.

Explore further

Other governance surfaces

Frequently Asked Questions

References

1. Meyman, E. (2026). On the Impossibility of Observability-Based Authorization, v1.4.0. FERZ, Inc. https://doi.org/10.5281/zenodo.19647542
2. Meyman, E. (2026). A Taxonomy of AI Governance Approaches: Distinguishing Visibility, Alignment, and Authorization, v1.7.1. FERZ, Inc. https://doi.org/10.5281/zenodo.18275969
3. Meyman, E. (2026). The Authorization Artifact Test: Applying the Impossibility Result to Ex-Ante Regulatory Regimes, v1.1. FERZ, Inc. Concept DOI https://doi.org/10.5281/zenodo.20013582; version 1.1 DOI https://doi.org/10.5281/zenodo.21326750
4. Meyman, E. (2026). Execution-Time Authorization for AI Agents, v2.1. FERZ, Inc. Concept DOI https://doi.org/10.5281/zenodo.18764561; version 2.1 DOI https://doi.org/10.5281/zenodo.21206935
5. Meyman, E. (2026). The Override Asymmetry: Why ABSTAIN with Authorized Resolution Is Not Guardrails with Review-Only Human-in-the-Loop, v2.0. FERZ, Inc. https://doi.org/10.5281/zenodo.19772248
6. Meyman, E. (2026). Versioned Meaning, Auditable Records, Stable Ontologies. FERZ, Inc. https://doi.org/10.5281/zenodo.18328587

The full FERZ corpus is available at /research/papers, on Zenodo, and on SSRN.

@misc{ferz2026authorizationgap,
  author    = {{FERZ, Inc.}},
  title     = {The Authorization Gap: Why AI Governance Is an Enforcement Problem, Not a Monitoring Problem},
  year      = {2026},
  month     = {May},
  publisher = {FERZ, Inc.},
  url       = {https://ferz.ai/governance}
}