FERZ Working Paper • February 2026 • Version 1.0
Why Guardrails Aren't Enough: The Case for Execution-Time Authorization in AI Governance
Your AI agents are executing thousands of irreversible actions per hour—placing orders, modifying patient records, transmitting protected data. The governance question is no longer whether they'll generate inappropriate text. It's whether a specific action, proposed by a specific agent, is authorized under governing policy, given the current system state, before that action takes effect.
Very few governance stacks answer that question deterministically, pre-execution, and with independently verifiable evidence.
Guardrails filter content. Alignment shapes behavior. Observability records what happened. Identity and access management authenticates who's acting. Orchestration coordinates sequencing. Each solves a real problem.
None of them evaluates a proposed action against governing policy prior to execution and produces verifiable evidence of the decision.
That missing layer has a name: execution-time authorization.
This article introduces the concept, explains why it's architecturally distinct from everything else in your governance stack, and provides a diagnostic framework for evaluating whether your current tooling actually provides it.
TL;DR — Execution-time authorization is a deterministic enforcement layer that evaluates every AI agent action against governing policy before execution and produces verifiable proof of the decision. It is not guardrails, alignment, IAM, observability, or orchestration—it is the architectural layer those tools cannot replace. This article defines the concept, provides six testable invariants, and includes a diagnostic table you can run against your own governance stack. The full formal model is in the Downloadable Research Paper.
What is execution-time authorization?
Execution-time authorization is a deterministic enforcement layer that evaluates every proposed AI agent action against versioned governing policy and current system state before that action executes, producing a replayable verdict and an immutable decision artifact. It matters because it is the only governance mechanism that provides instance-level, pre-execution, evidence-grade enforcement—properties that guardrails, alignment, IAM, observability, and orchestration do not provide individually or in combination.
The Governance Gap No One Is Talking About
Consider a clinical decision support agent that proposes ordering a medication for a patient. Or a trading agent about to execute a high-value transaction. Or a code-generation agent preparing to deploy software to production.
Each of these crosses what we call the boundary of irreversible state transition. Before that boundary, the action is a proposal. After it, the action has consequences that may be difficult or impossible to reverse.
The governance question at this boundary is precise: Is this specific action authorized under the policies that govern this system, given the current state of the environment?
This question has three properties that distinguish it from every other governance concern:
It is instance-level, not distributional. The question isn't whether the model generally produces safe outputs—it's whether this particular action is authorized right now.
It is pre-execution, not post-hoc. The evaluation must happen before the state transition, not after. Recording a violation after the fact is forensics, not governance.
It requires evidence, not assertion. The answer must be independently verifiable—an auditor, regulator, or counterparty must be able to confirm the governance decision without trusting the system that made it.
No combination of guardrails, alignment, IAM, observability, or orchestration provides all three properties simultaneously.
What Execution-Time Authorization Actually Is
Here is the formal definition, drawn from the research paper:
Execution-Time Authorization (ETA) is a deterministic enforcement layer that evaluates canonicalized action instances against versioned policy and governed system state prior to execution, producing a replayable authorization verdict and an immutable decision artifact.
Every word in that definition carries weight. Strip any element—canonicalization, policy versioning, pre-execution evaluation, determinism, replayability, artifact generation—and the system doesn't implement execution-time authorization, regardless of what it calls itself.
The practical implications:
Deterministic means identical inputs produce identical verdicts, unconditionally. No probabilistic inference, no model-based reasoning, no sampling. A regulator or auditor can reproduce the exact same decision by re-evaluating the same inputs. If they can't, the system provides assertions, not evidence.
Canonicalized means the action is transformed into a standard form before evaluation—order-independent, encoding-normalized, hash-stable. Two structurally equivalent representations of the same action must produce the same authorization verdict. Without canonicalization, determinism is impossible.
Versioned policy means every authorization decision is bound to the specific policy version under which it was made. Policy changes don't retroactively alter compliance status of prior decisions—a critical property for regulatory defensibility.
Fail-closed means that in the absence of an explicit ALLOW verdict, execution does not proceed. System failures default to denial. Ambiguous cases default to denial. There is no bypass mode, no degraded operation where actions proceed unexamined.
Decision artifact means every evaluation produces a proof-carrying record—the action hash, policy version, state reference, verdict, timestamps, evaluator identity, and where required, cryptographic signatures. This is the evidentiary basis for audit, not a log entry that says "action checked; result: approved."
Five Things That Aren't Execution-Time Authorization (But Get Confused for It)
The most common deployment failure in AI governance isn't the absence of tools—it's the misapplication of tools designed for one governance problem as substitutes for a different one.
Guardrails aren't authorization
Guardrails inspect content features (does this text contain profanity?); execution-time authorization evaluates authorization predicates (is this action permitted under governing policy given current state?). Guardrails may fail open on novel inputs, don't produce decision artifacts, and operate on surface patterns rather than policy semantics. For a deeper treatment of why multi-layer guardrails—even well-architected ones—don't constitute proof, see our related research.
Alignment isn't authorization
RLHF, constitutional AI, and instruction tuning shape model behavior at the population level during training. They make models less likely to generate harmful content. But a well-aligned model remains ignorant of your organization's specific policies—the model vendor doesn't know whether a particular output violates HIPAA, SEC reporting requirements, or your internal governance rules. Alignment improves the odds; authorization provides proof.
IAM isn't authorization (at the action level)
IAM answers "Who is this entity, and what permissions does it hold?" Execution-time authorization answers a different question: "Given the identity, the proposed action, the governing policy, and the current state, is this specific action authorized?" An agent with valid credentials and appropriate role permissions can still propose an action that violates temporal constraints, resource limits, or domain-specific compliance rules. IAM controls access. Execution-time authorization governs action.
Observability isn't authorization
Logging and monitoring record what happened after the action has taken effect. They provide forensic capability, not prevention. As we explored in Guardrails vs. Proof, the distinction between narrative-grade traceability and proof-grade evidence is architectural, not cosmetic—logs support reconstruction; they do not produce admissible proof that authorization was enforced at decision time.
Orchestration isn't authorization
Agent orchestration frameworks coordinate sequencing, routing, and agent-to-agent handoffs. They determine what happens in what order—not whether what happens is authorized. Orchestration coordinates; authorization governs.
Why AI Agents Break Traditional Security Models
Here's the insight that most governance frameworks miss: traditional security models rely on deterrence. The threat of legal liability, reputational damage, and consequences discourages human actors from violating policies they technically could violate.
AI agents don't experience deterrence. They have no fear of consequences, no reputation to protect, no personal stake in compliance. An agent that can technically execute an action will execute it unless an architectural boundary prevents execution.
This means governance for AI agents must be enforced, not incentivized. The authorization boundary must be architecturally non-bypassable—no execution path exists that permits an action to take effect without passing through the authorization function. Policy alone isn't enough. Architecture must guarantee it.
The Authorization Function
The paper formalizes execution-time authorization as a mathematical function:
Auth(A, P, S) → V
Where A is the canonicalized action instance, P is the versioned policy set, S is the governed system state, and V is a verdict from a triadic model: ALLOW, DENY, or ABSTAIN.
The ABSTAIN verdict is architecturally significant. Binary permit/deny models force the system to render a verdict in all cases, including cases where the policy set is genuinely ambiguous or incomplete. ABSTAIN provides the system's explicit acknowledgment of its own limits—a controlled handoff of authority rather than an uncertain guess. ABSTAIN is operationally equivalent to DENY by default; it differs in that it triggers mandatory escalation rather than terminal refusal. ABSTAIN never permits execution; it routes authority to a higher trust tier.
The determinism invariant requires that for any given action, policy, and state, the function produces the same verdict on every evaluation, regardless of when, where, or by whom the evaluation is performed.
Six Invariants Your Governance Must Satisfy
A system cannot be considered to implement execution-time authorization unless it satisfies all six of the following invariants. Violation of any single invariant disqualifies a system from the category.
1. Deterministic evaluation. Identical inputs produce identical verdicts, unconditionally. No randomness, sampling, or probabilistic inference participates in the verdict computation.
2. Fail-closed enforcement. In the absence of an explicit ALLOW verdict, execution does not proceed. System failures, timeouts, and evaluation errors result in denial, not default permission.
3. Non-bypassability. No execution path exists that permits an action to take effect without passing through the authorization function. This is an architectural property, not a policy requirement.
4. Provenance-complete decision artifacts. Every evaluation produces a decision artifact containing, at minimum: the action hash, policy version and hash, state reference, verdict, timestamps, and evaluator identity. A third party can verify the decision without trusting the original evaluator.
5. Replayability. Given the decision artifact, a third party can reproduce the verdict. The verifier does not invoke the original AI model, does not rerun probabilistic inference, and does not require access to model weights. The decision artifact and the evaluation function are sufficient.
6. Time-bounded evaluation without fail-open. Authorization completes within bounded latency. If evaluation does not complete within the allotted window, the result is denial, never default permission.
A Diagnostic for Your Current Governance Stack
Use these six tests to evaluate any governance solution—including your own. For each, the answer is binary: the system either satisfies the invariant or it doesn't.
| Test | Question to Ask | Pass Criteria |
|---|---|---|
| Determinism | Can a third party reproduce the exact verdict from the same inputs? | Identical inputs → identical verdicts, every time |
| Fail-closed | What happens when the governance layer goes down? | All actions blocked until governance is restored |
| Non-bypassability | Does any execution path exist that skips governance evaluation? | No path to execution without authorization |
| Decision artifacts | Does every evaluation produce a verifiable proof record? | Artifact sufficient for independent verification |
| Replayability | Can an auditor reproduce the decision without the original system? | Verdict reproducible from artifact + evaluation function |
| Anti-laundering | Does the system produce its own governance evidence, or rely on the governed system's claims? | Evidence generated by enforcement layer, not by governed agent |
If your current governance stack fails any of these tests, it doesn't provide execution-time authorization—and the actions it permits are authorized by assumption, not by evidence.
Want the full formal model, conformance criteria, and deployment patterns? Download the research paper (PDF) or cite via Zenodo.
Where Execution-Time Authorization Fits in Your Stack
Execution-time authorization is not the entire AI governance stack. It's the layer that makes the stack complete.
| Layer | Function | Example Technologies |
|---|---|---|
| Training & Alignment | Shape model behavior at training time | RLHF, Constitutional AI, instruction tuning |
| Identity & Access | Authenticate entities, manage permissions | IAM, OAuth, RBAC |
| Content & Safety | Filter outputs post-generation | Guardrails, content classifiers |
| Authorization | Evaluate actions against policy before execution | Execution-time authorization |
| Orchestration | Coordinate agent sequencing and routing | MCP, AI gateways, workflow engines |
| Observability | Record and analyze system behavior | Logging, monitoring, anomaly detection |
Each layer addresses a distinct governance problem. The authorization layer is the one that provides deterministic, pre-execution, evidence-grade enforcement. It sits between content safety and orchestration—after the model has generated a proposed action, before that action takes effect.
Implications for Regulated Industries
For organizations operating in regulated domains, execution-time authorization addresses several governance requirements simultaneously:
In healthcare, it provides evidence that AI-proposed clinical actions were evaluated against institutional policies, formulary constraints, and patient-specific rules before execution—not just logged after the fact.
In financial services, it produces the decision artifacts that regulatory examinations increasingly require: not just records that trades occurred, but verifiable proof that each action was individually authorized under governing policy at the time of execution.
In government and defense, where the consequence of unauthorized agent action can be catastrophic, execution-time authorization provides the architectural assurance that no action proceeds without deterministic evaluation—including in degraded or adversarial conditions.
In enterprise AI deployment broadly, it shifts the compliance posture from retrospective audit defense ("we logged what happened and it looked OK") to prospective authorization proof ("every action was evaluated before execution and here is the verifiable evidence").
The Research Behind This Framework
This article summarizes findings from a formal research paper that provides the complete mathematical treatment, threat model, deployment patterns, conformance criteria, and open research directions.
The paper is part of a broader research program that includes work on AI governance taxonomy, authorization boundary architecture for agentic infrastructure, deterministic enforcement architectures, multi-tier linguistic governance, proof-carrying governance standards, and cryptographic audit frameworks.
Permanent citation: doi.org/10.5281/zenodo.18764562
The paper includes:
- Formal definition and mathematical model with explicit invariants
- Threat model mapping five threat classes to specific invariants
- Five architectural deployment patterns with trade-off analysis
- Six testable conformance criteria
- Six open research directions including policy composability, distributed coordination, and hardware-bound enforcement
Related FERZ Research & Technology
- Guardrails vs. Proof: The Missing Axis in Multi-Layer Agent Safety — Why multi-layer guardrails don't constitute evidentiary proof
- DELIA: Deterministic Enforcement & Linguistic Interception Architecture — An implementation architecture for execution-time authorization
- Four Tests Standard (4TS) — Open conformance standard for AI governance
- Constitutional Blockchain Architecture — Cryptographic audit infrastructure for decision artifact chains
- LASO(f): Linguistic & Algebraic Structuring Operator — Multi-tier linguistic governance for policy formalization
By Edward Meyman, Founder, FERZ, Inc.