How Runtime Authorization Became the Missing Layer in AI Governance
There's a sentence I keep hearing in AI governance conversations that would have been unintelligible eighteen months ago: "We need runtime authorization for our agents."
It's encouraging to hear. It's also worth pausing to explain where the idea came from, because the path wasn't obvious — and understanding the path matters for understanding what the concept actually requires.
The observation that started it
In mid-2024, we were looking at the security models that enterprises were applying to AI systems and noticed something that, in retrospect, should have been obvious: they were all built on deterrence.
Firewalls work because an attacker weighs risk against reward. Access controls work because employees fear consequences. Audit logs work because the threat of discovery changes behavior. The entire apparatus of information security assumes that the entity being governed has something to lose.
AI agents have nothing to lose.
An AI system has no career. No reputation. No fear of prosecution. No mortgage. The entire deterrence model — the model that undergirds decades of security architecture — doesn't apply. You can't deter a system that doesn't know what deterrence means.
This was the first insight, and it changed everything that followed. If you can't deter, you must constrain. Not monitor and hope. Not log and review. Constrain — at the point of action, before the action occurs.
From monitoring to authorization
The AI governance market through 2024 and 2025 was dominated by observability. Good observability — sophisticated logging, anomaly detection, dashboards that could tell you exactly what your AI systems were doing. But observability answers the wrong question. It answers "what happened?" The question that matters for regulated deployment is "was this specific action authorized under governing policy before it executed?"
These are not the same question. A comprehensive log that records every AI decision still requires trusting that the logging system accurately captured what was checked. A log tells you what happened. It does not prove what was permitted.
We started calling this the enforcement gap: the space between knowing what your AI did and proving that it was allowed to do it. The gap is invisible in a demo. It is glaring in an audit.
Once you see it, you can't unsee it. Every "governance" product that monitors, scores, or reports without issuing a binding verdict before execution has the same structural gap.
Engineering the answer
We didn't start by writing papers. We started by engineering what it would take to make authorization provable. The publications came after the architecture was fixed.
In October 2024, we began designing LASO(f) — a linguistic governance architecture that enforces constraints on AI-generated language at the structural level. Not filtering after the fact. Not scoring and flagging. Deterministic enforcement of what an AI system is and isn't permitted to say, with independently verifiable proof that the constraints were applied.
The architecture couldn't have been designed any other way. If you believe governance is advisory — suggestions that a model can accept or ignore — you build a monitoring layer. If you believe governance is authorization — binding verdicts that determine whether an action proceeds — you build an enforcement layer. We believed the latter. The product reflected it from the first line of code.
By May 2025, the provisional patent for LASO(f) was filed. By July 2025, the provisional for DELIA — our constraint validation and authorization engine — followed. DELIA formalized the deny-by-default, fail-closed architecture: no AI action proceeds unless explicitly authorized against governing policy. Every decision produces a signed evidence artifact that a third party can independently verify.
These weren't products that had "deterministic governance" retrofitted onto them. The deterministic philosophy is the product architecture. Strip it out and you no longer have authorization; you'd be back to monitoring and after-the-fact controls.
The question that forced a taxonomy
Building authorization infrastructure forces a question that monitoring never has to answer: if most of what the market calls "governance" isn't actually governing anything, what is it doing? We needed vocabulary precise enough to distinguish approaches without being dismissive of work that genuinely matters.
The answer was a three-part taxonomy, published as a formal classification in January 2026. Every AI governance capability falls into one of three categories:
Operational Visibility answers "what happened?" — logging, monitoring, anomaly detection. Essential infrastructure. Not governance.
Behavioral Alignment answers "is this AI generally safe?" — RLHF, constitutional AI, guardrails, content filtering. Critical model-layer work. Not governance.
Decision Authorization answers "was this specific action permitted under governing policy?" — pre-execution validation that produces independently verifiable proof artifacts. This is governance.
The taxonomy isn't a hierarchy. Visibility and alignment are not lesser functions — they're prerequisites. You need aligned models, you need operational visibility, and you need authorization. The problem is that most organizations have the first two and assume they have the third.
What authorization actually requires
Naming the category was the easy part. Specifying what it requires was harder.
We worked backward from what a regulator would actually need in an enforcement action and arrived at four formal tests. We called them the Four Tests Standard, published in December 2025 as an open specification. The tests apply to any system claiming to provide governance — including ours. We hold LASO(f) and DELIA to the same standard we're asking the market to adopt. If our own products couldn't pass, we'd have no business publishing the criteria:
Reproducibility. Identical inputs under identical policy must produce identical verdicts. If two auditors evaluate the same governed state and get different answers, the system isn't deterministic — it's an opinion engine.
Verifiability. An independent third party must be able to validate the verdict without access to the vendor's infrastructure. If verification requires calling the vendor's API, the vendor is marking their own homework.
Completeness. Every governed action must produce a decision artifact. Sampling is not governance. If 10% of actions are evaluated, 90% are ungoverned.
Boundedness. Governance must cover the full action space. If the system governs text but not tool calls, the tool calls are ungoverned — and tool calls are where agents actually do things.
Any system that satisfies all four is doing authorization. Any system that fails one is doing something else — possibly something valuable, but not authorization.
If you're evaluating a vendor — or your own infrastructure — three questions will tell you where you stand: Ask for a DENY demo. Ask for an exported decision artifact. Then ask an independent party to replay and verify it without the vendor's infrastructure. If any step fails, what you have is monitoring with better branding.
Operationalizing before evangelizing
By late 2025, we had products under patent, a formal architecture, and a growing conviction that the market needed vocabulary before it needed vendors. There's a temptation, when you have a working framework, to sell it. We chose to publish it instead.
In December 2025, we released the Four Tests Standard and the formal taxonomy as open specifications. Before the first public article went live in January 2026, we had already published vertical-specific governance frameworks for four regulated industries — financial services, healthcare, federal programs, and government contractors — translating the formal tests into procurement-ready instruments aligned to existing regulatory expectations. SR 11-7 for financial services. FDA's SaMD pathway for healthcare. OMB M-24-10 for federal programs.
The reasoning was simple: a standard that lives only in a preprint is an academic exercise. A standard that shows up in an RFP evaluation matrix is infrastructure. We wanted to put the evaluation criteria into the hands of buyers, compliance officers, and audit teams before we started explaining the theory publicly. Let the instruments create pull. Let the theory explain the pull.
Where the field is now
In early 2026, papers from major labs and governance groups began converging on the same structural conclusion — through different analytical paths, using different vocabulary, but arriving at remarkably familiar requirements. Authorization over coordination. Cryptographic proof over logs. Fail-closed enforcement over monitoring.
This is encouraging, not threatening. The more organizations that recognize the enforcement gap, the faster the market moves from monitoring to authorization. The more researchers who formalize the requirements, the harder it becomes to sell dashboards as governance. Convergence validates the category — a category we've been building into product architecture since before it had a name.
And the category needs to exist. The number of AI agents making consequential decisions is growing faster than the governance infrastructure to authorize those decisions. Every enterprise deploying agents in regulated environments will eventually face the same question their auditors will ask: Can you prove this action was authorized before it executed?
The organizations that can answer that question will deploy with confidence. The ones that can't will deploy with dashboards and hope.
Where it needs to go next
Runtime authorization as a concept is entering the mainstream. But the hard engineering work is just beginning.
Multi-agent authorization is the immediate frontier. When Agent A delegates a task to Agent B, which then invokes Tool C, who authorized the chain? Current protocols handle coordination — message passing, capability discovery, task routing. None of them handle authorization. The gap between "Agent B can do this" and "Agent B is permitted to do this under the delegator's governing policy" is the next enforcement gap. We've already published formal work on cross-agent governance architectures, and the engineering challenges are significant — but tractable if you start from the right foundation.
Cross-organizational governance is the horizon beyond that. When your agent calls my agent calls a third party's tool, governance can't depend on any single organization's infrastructure. The proof must be portable, the verification must be independent, and the policies must compose without requiring trust between parties.
Formal verification of governance itself is the deeper problem. It's not enough to prove that an action was authorized. We need to prove that the authorization system correctly implements the stated policy — that the governance layer does what it claims. This is where type theory, proof-carrying code, and formal methods enter the picture.
These are hard problems. They are also solvable problems, and they're the problems we've been working on since before the market knew they existed.
The path from "AI governance" as a market category to runtime authorization as an engineering discipline has been shorter than anyone expected. The question now isn't whether authorization will be required. It's whether the industry will build it with evidentiary rigor, or rebrand dashboards again.
We know which side of that question we're on. We've been building toward it since October 2024.
By Edward Meyman, Founder, FERZ, Inc.
Resources
Four Tests Standard (4TS) — The conformance standard for deterministic AI governance
A Taxonomy of AI Governance Approaches — Visibility, Alignment, and Authorization classification
AI Governance Executive Guide Series — Vertical-specific procurement frameworks (CC BY 4.0)
FERZ Publications — Zenodo — Full technical research corpus
FERZ Publications — SSRN — Business and policy research