The Ambit Infrastructure Thesis

Research programme. The Governance of Autonomous Action establishes the conceptual foundations of execution governance. From Confused Deputies to Execution Governance develops the architecture. This paper examines why this governance layer becomes infrastructure.

1. Autonomous AI Systems and the Governance Gap

Autonomous AI systems generate actions through probabilistic reasoning. Unlike traditional software, which executes deterministic instructions written by developers, these systems reason over information, select their own actions, and produce tool invocations, API calls, database modifications, and infrastructure operations dynamically. The action space is open-ended. A model does not follow a fixed control flow; it proposes actions based on statistical inference, contextual reasoning, and delegated goals. The same system, given similar inputs, may produce different sequences of operations.

This flexibility is precisely what makes autonomous AI systems valuable. It is also what makes them ungovernable under existing architectures. Autonomous systems scale capability through probabilistic reasoning; they scale trust through deterministic governance. Today, the capability is scaling. The governance is not.

Organisations deploying autonomous AI systems must answer two questions about every consequential action those systems perform. First: was the action authorised according to policy? Second: can the organisation prove that authorisation occurred? These are not aspirational questions. They are the questions that auditors, regulators, and incident investigators will ask — and that today’s control architectures cannot answer.

The gap is not a shortage of controls. Enterprises deploy six mature categories of security and governance tooling, each addressing a real concern:

Control Family	Boundary	What It Can Prove	What It Cannot Prove
Identity and Access Management	Identity / resource	Who holds permission to access a resource	Whether a specific autonomous action was authorised under a specific delegation
Policy Engines	Request / rule	That a request matched declarative rules	That the delegation chain was valid, temporally fresh, and unrevoked
Guardrails and Content Filtering	Model output	That model output was constrained	That the resulting tool invocation was authorised at the execution boundary
Framework-Scoped Controls	Application lifecycle	That developer-defined workflows were followed	Whether execution authority can be independently verified across frameworks
Logging and Observability	Post-execution	What occurred and when	Whether the action should have been allowed before it executed
Network Security	Connection / perimeter	That connections were permitted	That the data flowing through permitted connections was authorised to flow

The gap is not in any single row. It is that no combination of rows produces a pre-execution record binding the action, the delegation, the policy, and the decision into independently verifiable evidence. Each control operates at a different boundary, addresses a different concern, and produces a different kind of assurance. None composes with the others into a synchronous, pre-execution governance gate that evaluates the specific action, verifies the delegation chain, renders an explicit decision, and produces tamper-evident evidence — all before the action executes.

The structural precondition: complete mediation. Every guarantee in this document rests on one assumption that must be stated before any of them can be defended: the action has no route to consequence except through the governance plane. This is the principle of complete mediation (Saltzer and Schroeder, 1975), applied to the deployment rather than to the model. It is a property of where the enforcement point physically sits — a credential broker the system must call to obtain authority, an egress gateway the system’s traffic must traverse, a governing tool proxy through which every tool invocation is routed — not a property of the model’s good behaviour. Where a consequence-producing path exists that the plane does not sit on, that path is ungoverned by definition, and no downstream claim (“execution iff ALLOW”, “cannot be bypassed”) holds across it. The trusted computing base of this architecture is therefore the set of enforcement points and the integrity of the evidence chain — not the reasoning system, which is explicitly outside it. The threat model below, and the residual gaps disclosed throughout (the code-execution plane, §8; ungoverned egress, §8; object-side TOCTOU, §7; cross-trust-root composition, §5), are precisely the cases where complete mediation is hardest to establish. Stating the precondition converts each of them from a refutation of the thesis into a named coverage obligation the deployment must discharge.

The consequences of this gap are not theoretical. The architecture that follows is designed against a specific threat model — six categories of governance failure that existing controls cannot address:

1. Reasoning error — the model proposes an unsafe or policy-violating action through faulty inference.
2. Capability escalation — delegated authority is widened, stale, or unverifiable, permitting actions beyond intended scope.
3. Policy drift — governance rules change without replayable traceability, making historical decisions unverifiable.
4. Execution ambiguity — no pre-execution record establishes which authority enabled an action.
5. Evidence tampering or gaps — logs are absent, incomplete, or altered, making governance unverifiable after the fact.
6. Reasoning-plane compromise — the reasoning plane is induced to propose an attacker-chosen action: by prompt injection, indirect context poisoning, a confused deputy, a hijacked or malicious driver, or multi-agent collusion. This is the dominant real-world bypass, and it requires the most careful honesty about what the architecture does and does not do.

On category 6, the architecture makes no claim to detect or prevent the compromise. It does not inspect the reasoning plane’s inputs or reverse the inducement; that is the work of guardrails (§3) and out of scope here. What it does is source-independent: it bounds the blast radius of a compromised reasoning plane to whatever the presented delegation authorises. A poisoned proposal that exceeds authority is denied on exactly the same basis as a buggy or malicious one — the plane evaluates the action against the delegation, not the provenance of the intent. The load-bearing corollary is that governance is only as strong as the tightness of the delegation: an over-broad delegation re-opens the gap, because a hostile in-scope action is, by construction, indistinguishable from a benign in-scope action (§13 tightens this claim for the evidence record). This is why scope-narrowing (§7), not anomaly detection, is the real control. Source-independence is therefore not a weakness of the model; it is the property that makes the same denial hold regardless of who or what induced the action.

Each category is addressed by a different aspect of the architecture. The mapping — and, critically, the guarantee class each category receives — is the following:

Threat category	Addressing mechanism	Guarantee class
1. Reasoning error	Deterministic evaluation at the action boundary (§6)	Contained, not prevented — a reasoning error is caught only if it surfaces as a policy-violating action; a policy-conformant-but-harmful action is out of scope (governance ≠ correctness)
2. Capability escalation	Scope-narrowing delegation, fail-closed on stale/unverifiable authority (§7)	Prevented — given a sound, complete policy and a correctly narrowing chain
3. Policy drift	Content-hashed policy and ontology, replayable evidence (§6, §10)	Detected and evidenced — historical decisions remain replayable under their stamped policy identity
4. Execution ambiguity	Pre-execution Evidence Record binding action, delegation, policy, decision (§10)	Prevented — no governed action executes without a binding pre-execution record
5. Evidence tampering or gaps	Hash-chained Decision Ledger, externally anchored ledger head (§10)	Detected — tampering is computationally detectable by a verifier holding an independent commitment to the ledger head
6. Reasoning-plane compromise	Source-independent blast-radius bounding via delegation tightness (§7, §13)	Bounded, not detected — the compromise is neither detected nor prevented; its consequences are bounded to the presented delegation’s scope

“Addressed” thus means different things for different categories, and the table states which. The honest boundary of the whole architecture is visible in the right-hand column: two categories are prevented, one detected-and-evidenced, one detected, one contained-if-it-surfaces-as-an-action, and one merely bounded. The negative space — what governance does not guarantee — is restated where it bites in Sections 8, 10, and 13.

The argument that follows is that an independent authorisation layer is not merely useful but structurally inevitable. It proceeds in thirteen steps: from the core contradiction that autonomous AI systems create (Section 2), through the architectural resolution (Sections 3–7), the enforcement surfaces that governance must cover (Section 8), the evidence architecture that makes governance verifiable (Sections 9–10), the structural requirement for independence (Section 11), the historical trajectory that makes this layer inevitable (Section 12), the control-plane pattern that names it (Section 13), to the destination (Section 14).

The architectural details of this layer are developed in the companion research white paper; this document addresses a different question: why such a layer becomes structurally inevitable.

The framing throughout is architectural, not commercial. The question is not whether a particular product succeeds but whether the governance of autonomous AI action converges on an independent, evidence-producing, vendor-neutral layer — the same structural convergence that produced identity infrastructure, network control planes, container orchestration, and payment networks. The evidence suggests it must.

2. The Autonomy–Control Contradiction

The failure of existing control families to compose into governance is not accidental. It reflects a structural contradiction inherent in any system that must be simultaneously autonomous and governed.

The system must be autonomous to be useful. The value of autonomous AI systems lies in their capacity to reason over complex domains, discover novel strategies, adapt to changing contexts, and automate tasks that resist deterministic specification. Restricting the reasoning process — constraining which thoughts the system may have, which tool sequences it may consider, which strategies it may explore — destroys the capability that justifies deployment. An autonomous AI system that can only follow predetermined paths is a workflow engine with higher compute costs.

The system must be governed to be trustworthy. Actions that modify infrastructure, initiate financial transactions, transmit sensitive data, or alter persistent records must be authorised according to policy. Without governance, every action is implicitly permitted — including actions that violate regulations, exceed delegation scope, or produce irreversible harm. An autonomous AI system that can take any action without constraint is not an employee; it is an unaccountable principal with the keys to the building.

Traditional approaches resolve this contradiction by sacrificing one side. Systems that prioritise autonomy provide weak governance guarantees: the model reasons freely, but no mechanism ensures that the resulting actions are authorised. Systems that prioritise control restrict the reasoning process itself: guardrails constrain outputs, prompt engineering limits action selection, and hardcoded allowlists reduce the system to a narrow set of pre-approved operations. The first approach loses governance. The second loses capability. Neither is acceptable.

The Theory of Inventive Problem Solving (TRIZ; Altshuller, 1999) — a structured approach to resolving engineering contradictions, typically by separating conflicting requirements onto independent mechanisms or different operating regimes — provides a precise vocabulary for this situation. The autonomy–control conflict is a technical contradiction: improving one parameter (reasoning autonomy) worsens another (action controllability). TRIZ further identifies a physical contradiction at the action level: the action selection process must be simultaneously probabilistic (to enable creative reasoning) and deterministic (to enable governance). A single mechanism cannot be both.

TRIZ resolves physical contradictions through separation. The resolution principle is: do not constrain reasoning; govern consequence. Separate the system into components that handle each requirement independently. Let the probabilistic process do what it does best — reason, plan, propose. Let a deterministic process do what it does best — evaluate, decide, record. The contradiction dissolves when governance operates on a different plane from reasoning.

This is not a design preference. Within the option space, it is the resolution that preserves both properties. The dichotomy is exhaustive by construction: any mechanism either constrains the reasoning process or it does not. If it constrains reasoning — narrowing which thoughts, strategies, or tool sequences the model may consider — it destroys the capability that justifies deployment, sacrificing autonomy. If it does not constrain reasoning, the only place left to act is on the consequence of reasoning: the proposed action. So the architectural choices reduce to two, and the apparently distinct “third options” collapse into one or the other. Bounded-probabilistic governance (a model that scores its own actions’ permissibility) constrains nothing deterministically and therefore fails to govern — the same action may be permitted or denied by inference path. Post-hoc reversal with escrow governs after consequence, not before it, and only covers the reversible subset of actions; for the irreversible remainder it is not governance but compensation. Human-in-the-loop on every action is a degenerate case of consequence-governance with a human evaluator, subject to the same separation, and does not scale to the action rates that motivate autonomy in the first place. Each plausible candidate thus either constrains reasoning (and loses capability) or governs consequence (the architecture below) — there is no third regime that escapes the reduction.

Any architecture that constrains reasoning to achieve governance has collapsed the contradiction into a single mechanism — and must sacrifice one side to serve the other. Any architecture that separates reasoning from governance can serve both.

Two predicates over a canonical action. The whole thesis turns on a distinction the rest of this document makes precise. Let $a$ be a canonical action (its definition is pinned in Section 6). Define two predicates:

• $\mathrm{Capable}(a)$ — the action is technically reachable by the system: it possesses the credentials, the network path, and the tool to attempt it.
• $\mathrm{Authorised}(a)$ — the action is permitted by standing policy under a presented, valid delegation: $\mathrm{Authorised}(a) \iff G(I, D, P) = \mathrm{ALLOW}$, where $G$ is the governance function defined in Section 6.

These are independent. A system is routinely capable of far more than it is authorised to do. The core property of the architecture is then stated as a single line: execution requires $\mathrm{Authorised}(a)$, and $\mathrm{Capable}(a) \wedge \neg\,\mathrm{Authorised}(a) \Rightarrow \mathrm{DENY}$ — capability without authorisation is exactly the case the plane exists to refuse. “Should” here is a decidable predicate over resolved inputs — authorised under currently-distributed policy and an unexpired, unrevoked, in-scope delegation with its temporal and contextual preconditions satisfied — not a normative or ethical judgement about whether the action was wise or kind. With these two predicates in hand, the confused-deputy result and the “unaccountable principal” line (Section 7) fall out as corollaries rather than restatements.

The separation principle is easy to state and difficult to implement. It demands answers to precise architectural questions. Where does governance occur? What does it evaluate? What guarantees does it provide? The remaining sections answer those questions. But the structural point must be established first: the autonomy–control contradiction is inherent in autonomous AI systems, it cannot be resolved by better engineering within a single plane, and it dissolves only when reasoning and governance are architecturally separated.

3. Why Guardrails Cannot Solve the Problem

The most common objection to the inevitability argument is that better guardrails will suffice. If guardrails are improved — made more sophisticated, more context-aware, more comprehensive — they will eventually close the governance gap. This objection deserves a serious answer, because guardrails are genuinely useful and the argument against them is not that they fail but that they govern the wrong surface.

Guardrails are necessary. They reduce harmful outputs, enforce content policies, catch prompt injection attempts, and constrain model behaviour within acceptable bounds. Any serious deployment of autonomous AI systems should include them. The argument that follows is not against guardrails. It is against the belief that guardrails are sufficient — that improving them enough will eventually close the governance gap. That belief is architecturally mistaken.

Guardrails operate at the language boundary. They evaluate what the model says — the text it produces as output. A guardrail can determine whether a model’s response contains prohibited content, whether the output conforms to structural requirements, and whether the generated text matches or violates predefined patterns. This addresses a real category of risk: the risk that a model produces harmful, misleading, or policy-violating text.

But text production and action execution are different operations at different boundaries. A model may produce acceptable text while proposing an action that violates policy. The model’s output might say “I’ll help you process that refund” — text that passes every guardrail — while the tool invocation it generates issues a refund that exceeds the delegation scope, violates temporal constraints, and lacks the required approval. The guardrail evaluated the language. Nobody evaluated the action.

This is the crux: once reasoning produces a tool invocation, the guardrail is no longer in the control path. The tool call flows to the execution layer with whatever parameters the model selected. The guardrail cannot see the tool call’s parameters, cannot evaluate whether the delegation chain authorises this specific invocation, cannot check whether the target resource falls within the permitted scope, and cannot produce evidence that governance occurred. The guardrail’s jurisdiction ends where consequence begins.

Better guardrails do not change this architecture. More accurate classifiers, more comprehensive pattern matching, more sophisticated semantic analysis — all improve the quality of language-boundary evaluation. None extends the evaluation to the action boundary. A perfect guardrail that catches every harmful output with zero false positives still does not evaluate tool invocations, verify delegation chains, or produce pre-execution evidence records.

Perfection at the wrong boundary does not compensate for absence at the right one.

The distinction is categorical, not incremental.

Guardrails govern what a model may say. Governance governs what a system may do.

These are different surfaces operating at different boundaries on different representations. A guardrail evaluates a text string. An action-boundary evaluation evaluates a structured canonical representation: actor identity, intent, target resource, parameters, delegation context, policy identity, and evaluation timestamp. A guardrail produces a binary classification (pass or block) on the text. An action-boundary evaluation produces an explicit decision (ALLOW, DENY, or ESCALATE) on the action, with a full reason trace and tamper-evident evidence. A guardrail’s output disappears after the text is released. An action-boundary evaluation’s receipt persists as independently verifiable proof that governance occurred.

Guardrails and governance are complementary, not competing. Guardrails govern the model boundary — a non-authoritative control surface described in Section 8, distinct from the six enforcement planes. Governance governs the action boundary. A well-architected system deploys both. But the governance gap exists at the action boundary, and no amount of improvement at the language boundary closes it.

4. The Moment of Consequence

If guardrails govern the wrong boundary, where is the right one?

The answer is architectural, not operational. Governance must occur at the boundary where intent becomes consequence — the point where a proposed action would produce a real-world effect. This is the action boundary: the moment at which a tool invocation, API call, database write, or infrastructure modification transitions from being a proposal inside a reasoning system to being an operation that changes something outside it. Before that moment, the action is an intention. After it, the action is a consequence. Governance must stand at the threshold.

The action boundary is downstream of reasoning, upstream of execution, and independent of any specific vendor, framework, or runtime. It exists wherever autonomous AI systems interact with external systems. An MCP tool call crosses the action boundary. An HTTP request to an external API crosses the action boundary. A write to a vector store crosses the action boundary. Each crossing is a moment where governance can either evaluate the proposed action or permit it to proceed unevaluated — a genuine dichotomy by definition, since “unevaluated” is the complement of “evaluated.” The substantive question is not whether a third option exists but whether the plane is in fact on the path of every such crossing; that is the complete-mediation precondition stated in Section 1, and where it does not hold, the crossing is simply ungoverned.

The temporal distinction matters. A governance record produced before execution is a fundamentally different artefact from a log entry produced after it. Pre-execution evaluation renders a decision — ALLOW, DENY, or ESCALATE — and that decision determines whether the action proceeds. The evidence record produced at that moment binds the decision to the policy, the delegation, and the action before any consequence occurs. Post-execution logging records what happened but cannot change it. The action has already executed. The database row has already been modified. The money has already moved. The data has already been transmitted.

The distinction is epistemic, not merely temporal. Proving that something happened is not the same as proving it was permitted. A log reconstructs history. An evidence record proves authorisation. One tells you that a refund was issued at 14:32. The other tells you that the refund was evaluated against policy version 7a3f..., under delegation d-2847 with scope narrowed to refund.issue actions below $500, and the decision was ALLOW based on rule amount_within_scope — and here is the cryptographic proof. The difference is the difference between a surveillance camera and a signed warrant. Both record events. Only one establishes authority. The warrant analogy must be held to its precise sense: a warrant proves the action was authorised under presented authority and standing rule, not that it was the right action to take. An Evidence Record proves authorisation — not intent, not appropriateness, not benefit to the delegating principal. An in-scope refund issued to the wrong customer through context bleed passes every check and produces a clean record; the record attests that the gate was followed, not that the outcome was correct. Intent-fidelity is a property of how narrowly the delegation was scoped (Section 7), not a property the evaluator can certify. Section 13 returns to this boundary.

The moment of consequence is not a product feature. It is the only architecturally correct location for governance of autonomous AI action. Any system that evaluates actions before this boundary is evaluating intentions, not operations — and intentions can change between evaluation and execution. Any system that evaluates actions after this boundary is monitoring, not governing — and monitoring cannot prevent the consequence it observes. Only evaluation at the action boundary, synchronously, before execution proceeds, satisfies both requirements: the action is assessed in its final form, and the assessment determines whether it executes.

This is the architectural foundation on which everything that follows is built. The three-plane architecture (Section 5) positions governance at this boundary. The deterministic evaluation function (Section 6) defines what happens there. The evidence chain (Section 10) records what happened.

The foundational claim is simpler: governance must stand at the moment of consequence, or it is not governance.

5. Execution Governance: The Three-Plane Architecture

The autonomy–control contradiction dissolves when the system separates into three planes, each responsible for exactly one concern.

The reasoning plane is probabilistic. It includes language models, planning systems, orchestration frameworks, and any mechanism that proposes actions based on contextual reasoning. The reasoning plane generates candidate actions — tool invocations, API calls, data operations — through whatever inferential process the model employs. Governance does not constrain this plane. The model may reason about anything, consider any strategy, and propose any action. The reasoning plane’s output is not a consequence; it is a proposal.

The authorisation plane is deterministic. It receives the proposed action as a structured canonical representation and evaluates it against compiled policy, validated delegation artefacts, and the current governance configuration. The evaluation function is pure: it takes defined inputs and produces exactly one of three outcomes — ALLOW, DENY, or ESCALATE. Silence is DENY. There is no implicit approval, no probability score, no “log and allow.” Every evaluation produces a tamper-evident evidence record binding the decision to the inputs that produced it.

The execution plane is consequence-producing. It carries out the authorised action: calling the API, writing to the database, modifying the file, transmitting the data. Execution occurs if and only if the authorisation plane renders ALLOW. The execution plane does not evaluate policy. The authorisation plane does not execute actions. The reasoning plane does neither.

This is the same architectural separation that networking introduced between control planes and data planes: the component that decides is independent of the component that executes. Section 13 develops this analogy in full.

The flow for a single action is propose → evaluate → decide → execute (if ALLOW) → receipt. This linear depiction is per-action, not per-turn: real runtimes emit parallel and streamed tool calls and speculative retries within one reasoning step. The boundary therefore handles a set of concurrently proposed actions, evaluating each independently; a streamed tool call is gated once its canonical action is complete and before any external effect occurs, never on partial arguments; and a retried action is a fresh evaluation whose consequence marker (Section 10) is keyed to the execution-event identifier so a retry cannot be double-counted as two consequences. The evaluator is per-action; the enforcement boundary is the coverage obligation across all of them.

The architecture crystallises into a single invariant:

Execution Governance Invariant. No action that produces external consequences may execute unless its authorisation has been deterministically evaluated against the canonical action, the delegation artefacts, and the policy identity at the action boundary — and unless that evaluation has produced a tamper-evident evidence record before execution proceeds.

An autonomous AI system proposes a write action targeting a customer database record, with parameters specifying the fields to modify. The proposal is intercepted at the action boundary and transformed into a canonical action representation: actor identity (the system operating under delegation d-4819), intent (write), target (customer_db/records/8472), parameters (the field modifications), delegation context (scope limited to write actions on customer_db, valid until 2026-06-30T00:00:00Z, revocation status verified fresh within the last 60 seconds), and policy identity (compiled policy hash c9e2...). The authorisation plane evaluates this canonical representation. If the delegation is valid, the scope includes the target, the temporal constraints are satisfied, and no deny rule matches, the decision is ALLOW. The Evidence Record is produced and appended to the Decision Ledger. The execution plane proceeds. If any condition fails — delegation expired, target outside scope, deny rule matched — the decision is DENY or ESCALATE. The Evidence Record is produced. Execution does not proceed.

Why three planes, not two? Because the authorisation plane must not collapse into either of its neighbours. If authorisation collapses into reasoning — if the model itself decides whether its actions are permitted — then governance inherits the probabilistic, non-deterministic properties of the reasoning process. The same action might be permitted or denied depending on the model’s inference path. Governance becomes subjective. If authorisation collapses into execution — if the execution layer retroactively determines whether the action should have been allowed — then governance occurs after consequence. The action has already executed. Evidence is reconstructed, not produced.

The separation is not an engineering convenience. It is a constitutional invariant. The Governance Constitution distinguishes two operational tests. Clause 8 (Separation of Planes) is the evolution test: governance remains structurally distinct from adjacent systems as those systems evolve over time. Clause 9 (Provider Neutrality) is the substitution test: governance semantics remain invariant when one adjacent system is replaced by another (Section 11). The evolution test is behavioural: a change to any adjacent system — model version, framework, runtime — must not alter governance evaluation semantics unless a corresponding, explicit change is made to governance configuration. If upgrading a model changes what is allowed or denied without a policy change, the planes are not separated.

The canonical action representation flows through the planes unchanged. It carries:

• Actor identity: who is acting (the autonomous AI system under a specific delegation)
• Intent: the operation requested (read, write, send, delete, execute, delegate)
• Target: the resource affected (identified by domain, path, classification)
• Parameters: the operation specifics
• Delegation context: the authority under which the actor operates (scope, temporal bounds, revocation status)
• Policy identity: the compiled policy against which evaluation occurs (content hash)
• Evaluation timestamp: when the evaluation was rendered (from a cryptographically authenticated time authority)

This representation is the interface between planes. The reasoning plane produces it. The authorisation plane evaluates it. The evidence record preserves it. The same canonical vocabulary operates regardless of which model, framework, or runtime produced the proposal — which is what makes the architecture vendor-neutral rather than vendor-specific.

The architecture extends to multi-system environments only when explicit conditions are satisfied. The Governance Constitution’s Clause 11 (Composition Closure) is unambiguous: governance of individual systems does not guarantee governance of their composition. Clause 11 scopes what it can deliver precisely — non-escalating, auditable delegation, not a blanket guarantee that any composed effect is acceptable. It states a three-part mechanism criterion: (a) every component produces its own Evidence Records at the action boundary; (b) the delegation chain linking components is verifiable end-to-end and narrows monotonically with each hop, never widening; and (c) the coordination artefact that admits cross-system action (the message, event, or shared-state record that carries authority from one component to the next) declares an explicit schema with a content-hashed identity, so that policies pattern-match against a stable shape rather than an implicit one. The precise claim is conditional on the trust root: within a shared trust root, (a) ∧ (b) ∧ (c) are jointly sufficient for the composition to be governed in Clause 11’s sense; across trust roots they are necessary but not sufficient. When any of the three is absent, the composition is ungoverned — even if each component, examined in isolation, satisfies the per-action invariants.

What “governed composition” guarantees, and what it does not, must be stated exactly, because the limit is the canonical objection to per-action governance. It guarantees per-hop authority traceability and monotonic narrowing: every component acts within a delegation that is a subset of its delegator’s, and the whole chain is reconstructable from evidence. It does not guarantee that the aggregate effect of independently-authorised actions is itself policy-conformant. A prohibited outcome can be decomposed into N individually in-scope actions — possibly across N colluding agents, each narrowing correctly from a common root (agent 1 stages sensitive data into a location it is permitted to write; agent 2, separately and validly delegated, exfiltrates from that location through an egress it is permitted to use). Clause 11’s monotonic narrowing does not prevent this, because no single action exceeds its delegation. Governing the aggregate effect requires stateful cross-action analysis that the deterministic per-action evaluator deliberately excludes (the constitution scopes workflow-level atomicity out of governance entirely). Sequence, decomposition, and collusion attacks are therefore a named open frontier, standing alongside the cross-trust-root gap — not a solved case. The honest reading of Section 8’s “cannot govern” table cell and Sections 5/12’s “governed” claim is this: composition is governed in the per-hop traceability sense, and ungoverned in the aggregate-effect sense; both statements are true of the same mechanism.

A second frontier remains open and is named in Clause 11: the cross-system trust-root problem. Two organisations whose authorisation planes use different time authorities, different schema registries, or different evidence anchors cannot trivially compose their evidence chains into a single auditable record. The mechanism criterion holds within a shared trust root; cross-root composition requires a separate trust-bridging artefact that is not yet doctrinally specified.

Within these conditions, the authorisation plane evaluates each action on its own terms: its own actor identity, its own delegation context, its own target. Coordination complexity lives in the reasoning and execution planes. The authorisation plane sees only canonical actions and renders only deterministic decisions. This is the precise sense in which the architecture is scalable: the per-action cost of evaluation does not grow with the coordination complexity of the systems it governs (it depends on the rules traced, the chain depth, and the scope size of the single action under evaluation — see Section 6), provided the three composition-mechanism criteria are met for every cross-system path. Aggregate cost still scales with action volume; it is the per-action cost, not the total, that is invariant under coordination complexity.

The three-plane model resolves the autonomy–control contradiction. Each plane does one thing. No plane interferes with the others. The contradiction is not managed — it is dissolved.

6. Deterministic Authority

The authorisation plane’s central property is determinism. The evaluation function must produce identical decisions for identical inputs — always, everywhere, under any runtime conditions. This is not a design preference. It is the property that makes governance auditable, reproducible, and independently verifiable. Without it, governance becomes subjective: two evaluations of the same action under the same policy might disagree, and no external party could determine which was correct.

The entire governance model reduces to a single formal statement. Let $I$ denote the canonical action, $D$ the validated delegation artefacts, and $P$ the policy identity. The governance function is the pure, total function:

$$G : \mathrm{ResolvedInputs} \to \{\mathrm{ALLOW}, \mathrm{DENY}, \mathrm{ESCALATE}\}, \qquad d = G(I, D, P)$$

where $d \in \{\mathrm{ALLOW}, \mathrm{DENY}, \mathrm{ESCALATE}\}$ and $\mathrm{ResolvedInputs}$ is the output of a possibly-failing resolution phase $R$. Execution is permitted only when $d = \mathrm{ALLOW}$. The full decision procedure is the composition $\mathrm{Decide} = G \circ R$, where a resolution failure short-circuits to DENY before $G$ is reached. This composition is the honest signature: the clean $d = G(I,D,P)$ form describes the evaluation phase only, and resolution-failure DENY sits in $R$, outside $G$ — a distinction Section 6’s fail-closed list makes good as a totality lemma below. Both branches produce an Evidence Record; a resolution-failure denial is recorded with the resolution step that failed in place of a full rule trace.

Determinism is a property of a frozen input tuple, not of wall-clock time. $G$ is pure with respect to its resolved inputs, but those inputs include time-varying state — current policy, current revocation status, the evaluation timestamp. The same nominal action under the same nominal policy can yield ALLOW under fresh state and DENY under stale or degraded state; this is not non-determinism but the explicit operation of fail-closed currency. To keep “same inputs, same output” precise, the snapshotted tuple that $G$ is a function of is stated in full: $(I,\; D \text{ with its revocation epoch},\; P \text{ as a content hash},\; \text{resolved context},\; \text{the evaluation timestamp from a named time authority})$. The Evidence Record binds this exact tuple (Section 10), so replay re-derives both the output and its input provenance. Determinism is “same output for the same frozen tuple,” never “same output across wall-clock.”

The canonical action $I$ is not the model’s free-text or the framework’s native call. It is the output of a deterministic, model-external canonicalisation: a per-tool-contract projection that is injective over the semantically-relevant fields, serialises to a byte-exact canonical form, and emits DENY or ESCALATE on any input shape it cannot canonicalise unambiguously. No language model is in this loop; canonicalisation is ordinary, inspectable code governed by a versioned canonicalisation spec whose identifier is recorded in every Evidence Record (Clause 5). Two evaluators that disagree on the canonical form of the same runtime behaviour are running different canonicalisation specs, and their receipts are not comparable (Clause 9).

In operational terms: decision = Authorise(canonical_action, validated_delegation, policy_bundle) — where canonical_action is the structured representation of the proposed operation (actor, intent, target, parameters), validated_delegation carries the scoped, time-bound, revocation-checked authority under which the system acts, and policy_bundle is the content-addressed compilation of governance rules and ontology against which the action is evaluated.

Rule order and conflict resolution are part of the policy identity. Determinism of $G$ requires not only pure inputs but a deterministic evaluation order and a defined conflict-resolution rule: if two rules match — one ALLOW, one DENY — “the rule that determined the outcome” is well-defined only under a stated precedence. This architecture fixes the discipline as deny-overrides under a total order on rules fixed at compile time, and that order is folded into the compiled policy and therefore into the policy hash. Rule-evaluation order is thus content-addressed: two independent evaluators given the same policy hash necessarily trace rules in the same order and resolve conflicts the same way, which is what makes the byte-identical-receipt claim defensible rather than implementation-dependent.

Every evaluation produces an Evidence Record:

$$r_n = (I_n, D_n, P_n, d_n, t_n, h_{n-1})$$

where $t_n$ is the evaluation timestamp acquired during resolution (a resolved input artefact, not a runtime-generated value), and $h_{n-1}$ is the previous record hash, forming the Decision Ledger described in Section 10.

The purity requirement is absolute. The evaluation function performs no I/O. It reads no external state. It makes no network calls. It consults no databases. Given the same canonical action, the same delegation artefacts, and the same policy identity, it produces the same decision — on any hardware, at any time, under any operational conditions. Two independent evaluators, provided with identical resolved inputs, must produce byte-identical deterministic receipt cores (Clause 5). The full emitted receipt envelope may additionally depend on explicit ledger state (the prev_hash and seq of Section 10) and emission metadata; when those are also fixed, the envelope too replays byte-identically. The determinism claim is about the receipt core; the envelope inherits it once ledger state is pinned.

This purity is achievable only because of a deliberate architectural separation between resolution and evaluation.

Resolution is the phase that assembles the evaluation’s inputs. It is permitted to perform I/O. Canonicalisation transforms raw adapter output into the canonical action representation. Revocation checks consult external services to determine whether the delegation has been revoked. Timestamp acquisition obtains a cryptographically authenticated time assertion. Delegation validation verifies temporal bounds, scope constraints, and chain integrity. These steps produce integrity-protected artefacts — the canonical action, the materialised delegation state, the verified timestamp — that become the evaluation function’s inputs. Resolution may fail. If it fails, the action is denied: the canonical input is incomplete, and evaluation cannot proceed.

Evaluation is the phase that renders the decision. It consumes the resolved inputs and nothing else. It is a pure function. It cannot fail due to external factors — all external dependencies were resolved in the previous phase. This separation is what makes determinism achievable: the evaluation function has no external dependencies because all external dependencies were resolved before evaluation began.

The fail-closed semantics are universally quantified, not a sample of triggers. The rule is: ALLOW requires every authorising precondition to be positively verified as current at evaluation time; if any precondition cannot be so verified, for any reason, $\mathrm{Decide}$ yields DENY or ESCALATE. The enumerated cases are instances, and together they establish the totality lemma: no input lacks a defined decision. An unknown action type is denied. A missing delegation for a privileged action is denied. An expired delegation is denied. A delegation whose revocation status cannot be verified within the required freshness window is denied. An evaluation that cannot complete — because the policy is unparseable, the ontology bundle is missing, or any input assembly step in $R$ fails — is denied. Silence is DENY. There is no fallback policy. There is no degraded mode. Integrity takes precedence over availability. A system that silently degrades governance to maintain throughput is not governed; it is merely optimistic.

ESCALATE is a defined value with a termination guarantee. ESCALATE is a first-class element of $G$‘s codomain, not a deferral that leaves the action ungoverned. It means execution is withheld and the decision is deferred to a named human or secondary authority, which resolves it to ALLOW or DENY. Termination is guaranteed by tying the pending decision to the delegation’s temporal window: an ESCALATE that is not resolved before the delegation’s exp defaults to DENY, and the timeout is itself recorded. There is no state in which an action sits in ESCALATE indefinitely — neither allowed nor recorded as denied — which is what keeps the “execution iff ALLOW” rule sound as a liveness as well as a safety property.

The fail-closed stance has a trust-root precondition that must be threat-modelled, not assumed. “Positively verified as current” leans on two external dependencies the architecture must not take on faith: the time authority and the revocation service. A spoofable or rollback-able clock lets an attacker re-validate an expired delegation or backdate a timestamp; a replayed cached “not revoked” assertion within the freshness window lets a just-revoked token still authorise an action. Closing the gap between “fail-closed on unreachable” (handled by the rule above) and “fail-closed on lying or stale” (otherwise unhandled) requires the time authority to issue signed, nonce-bound or monotonic assertions that resist rollback and replay, and the revocation service to issue non-replayable freshness assertions (signed over a challenge or short-lived). Without these, fail-closed is sound against an outage but not against an active adversary at the trust root.

Policy itself is data, not code. Tool classifications (safe, privileged, destructive), temporal constraints, delegation requirements, and approval thresholds are declared in a compiled policy configuration identified by its content hash. The ontology bundle — the domain model that defines the canonical vocabulary, field semantics, and valid enumeration values — is similarly identified by a content hash. Together, the policy hash and ontology hash form a complete, immutable reference to the rule system under which any decision was made. Policy changes produce new hashes. Decision records bind to specific hashes. An auditor examining a historical decision can load the exact policy and ontology versions that were in effect and replay the evaluation to confirm correctness.

Determinism is not a technical nicety. It is the property that transforms governance from an operational assertion (“we have policies”) into a mathematical guarantee (“given these inputs, this was the only possible decision, and here is the proof”). Without determinism, governance is a claim. With determinism — and with the evidence chain that determinism makes possible — governance is a verifiable system property.

The Cost of a Mandatory Gate

A synchronous, on-path, pre-execution gate is a strong claim for systems whose agents may issue thousands of actions a minute, and an inevitability thesis owes the cost side of its own gate. The resolution/evaluation split is precisely what makes the cost bounded, and the governing principle is separation in space between who owns governance and where enforcement runs: policy ownership, key custody, and evidence anchoring are organisationally independent of the actor (Section 11), while the enforcement point itself is co-located with the actor — an in-process library or a sidecar — so the hot path is a local call, not a remote round-trip.

On that hot path, evaluation is a pure function over already-resolved, freshness-bounded inputs: it is CPU-bound rule tracing with no I/O, and runs in sub-millisecond time for policies of realistic size. The slow path is resolution, and its expensive step — revocation — is a cached read within the declared freshness window (the 60-second bound of Section 5), not a per-action network call; time-authority assertions are batched or pre-acquired the same way. A reasonable design target is single-digit-millisecond added latency in the cached-warm common case, with the residual cross-network cost paid only when a freshness window genuinely lapses — a stated deployment trade-off, not a hidden one.

Two cost claims must be stated quantitatively, because the inevitability argument rests on them.

First, per-action cost. The per-action evaluation cost is approximately

$$O(\text{rules traced} + \text{chain depth} + \text{scope size} + \text{changed composition components}),$$

and this is what is invariant under coordination complexity (Section 5) — not aggregate throughput, which scales linearly with action volume. The composition-hash recomputation (Section 7) is kept from dominating this by structuring the composition as a Merkle commitment over its components, so forwarding-time recompute is $O(\text{changed components})$ against cached subtree hashes for the static majority, rather than a full re-hash on every action.

Second, the ledger is not a global serialisation point. A single linear hash chain — where $h_n$ depends on $h_{n-1}$ — is a strict serialisation point and cannot, as a single global chain, sustain thousands of actions a minute across concurrent agents: every append would have to wait for the previous one. The structural mitigation is per-actor or per-tenant sub-chains, each internally hash-chained, with sequence numbers assigned within a sub-chain (removing cross-actor contention), periodically cross-anchored into a Merkle root that commits all sub-chain heads at a checkpoint. This preserves tamper-evidence while making verification an $O(\log n)$ inclusion proof against a signed checkpoint rather than an $O(n)$ re-hash of the entire history — so verification cost is independent of ledger age. Section 10 specifies the chain; this is how it scales.

The unifying principle is that governance cost should scale with consequence, not with action volume. The irreversibility test and the consequence marker (Section 10) are what make this concrete: the full weight of evidence binding and consequence marking is owed for actions that produce irreversible external effects, while a high-volume stream of trivially reversible reads carries the cheap pure-evaluation cost and little else. A gate priced by consequence is compatible with high action rates; a gate priced by volume would not be.

7. Delegation and Capability Semantics

The autonomy–control contradiction is resolved architecturally by separating reasoning from governance. But separation alone does not answer a deeper question: under what authority does an autonomous AI system act?

Traditional systems answer this question with identity. A user authenticates, permissions are looked up, and access is granted or denied based on role membership. This works when the entity requesting access is the principal whose intent the action represents.

Autonomous AI systems break this assumption. The system is not the principal. It acts on behalf of a principal — a human operator, a service account, an upstream system — under authority that was explicitly granted to it. It exercises delegated authority. And that delegation must be explicit, scoped, time-bound, revocable, and verifiable at the moment of action.

The Governance Constitution (Clause 4) is unambiguous: “Agents do not possess inherent authority. If an agent can act, it acts under authority that was explicitly delegated to it.” Authority inferred from identity, role labels, or ambient runtime context is not sufficient. If authority cannot be traced to a presented, validated delegation artefact, the action is denied.

A delegation artefact is a structured claim carrying:

• Scope: the actions, tools, paths, and domains the delegation permits. scope.actions enumerates permitted canonical action types. scope.tools enumerates permitted tool identifiers. scope.paths constrains filesystem-like target prefixes. scope.domains constrains resource domains.
• Temporal bounds: nbf (not-before) and exp (expiry) timestamps defining the window during which the delegation is valid. The authorisation plane rejects delegations where the current time falls outside this window.
• Revocation status: whether the delegation has been explicitly revoked. Revocation status must be cryptographically verifiable and include freshness bounds. If revocation information is absent, freshness bounds are not declared, revocation status is unverifiable, or the declared validity window has been exceeded — the action is denied.
• Kind: the mechanism conveying the delegation (JWT, API key, session, OAuth), versioned for structural validation.

The scope narrowing invariant is fundamental: a child delegation’s scope must be a subset of its parent’s scope. But “subset” is not self-evident over the four heterogeneous scope dimensions — actions, tools, paths, domains — and an unstated order is where silent-widening bugs live. In particular, path narrowing is the inverse of naïve set inclusion: a longer path prefix denotes a smaller permitted set, so a reading of “child ⊆ parent” applied dimension-by-dimension can let an adversary widen one dimension while narrowing another. The order is therefore defined over a single derived set. Let

$$\mathrm{Perm}(\text{scope}) = \{\text{actions}\} \times \{\text{tools}\} \times \{\text{path-prefixed targets}\} \times \{\text{domains}\},$$

the set of concrete targets the scope actually permits, with a longer path prefix yielding a smaller target set. Narrowing is then $\mathrm{Perm}(\text{child}) \subseteq \mathrm{Perm}(\text{parent})$ over that single set — under which prefix-lengthening correctly reads as narrowing — and by transitivity $\mathrm{Perm}(\text{leaf}) \subseteq \mathrm{Perm}(\text{root})$. The subset check is decidable only once its edge cases are pinned, each a known escalation vector: empty scope denotes the empty permitted set (deny-all), never the universal set; paths and domains are canonicalised before comparison (resolving ./, ../, trailing slashes, case, and unicode normalisation) so that two spellings of one target cannot evade the check; prefix matching respects segment boundaries (/a does not match /ab); and scope patterns, if wildcarded at all, use a wildcard grammar under which subset remains decidable. Delegation chains must be end-to-end traceable. Sub-delegation must preserve or narrow the delegator’s authority scope and must never widen it. If the chain cannot be validated end-to-end, the action is denied.

Topology and depth. Sub-delegation is not necessarily a single chain. A delegator may sub-delegate to several children, and Section 5’s multi-system composition implies a tree, or a DAG where a node is reachable from more than one parent. The invariant generalises accordingly: every root-to-node path must narrow monotonically, and a re-convergent node — one with multiple parents — is bounded by the intersection of its parents’ scopes, never their union (the union would silently widen authority through re-convergence). Validation is therefore $O(\text{paths} \times \text{depth})$ per action, which is why depth is bounded: the bound exists to cap transitive authority and worst-case evaluation cost. The bound is not a free parameter — the derivation principle is that chain depth must not exceed the number of distinct trust boundaries a single action legitimately crosses in the deployment, a small constant in practice; a deployment states its value and treats any chain exceeding it as a denial.

Delegation targets must also have stable, verifiable identity. An autonomous AI system’s identity is not intrinsic — there is no natural fingerprint of what it is. Identity must be derived deterministically from the system’s composition: model version, system prompts, tools, policy bindings, fine-tuning artefacts, retrieval configuration. A delegation stamps the composition hash of the target at issue time. But verifying the hash at delegation time is insufficient: the composition can change between the moment of delegation verification and the moment of action forwarding. This opens a race condition in which an action delegated to composition $c_1$ executes under composition $c_2$. The Governance Constitution’s atomicity of composition check (Clause 4) closes this: composition-hash verification must be atomic with action forwarding at the enforcement boundary, not only at evaluation time. The enforcement boundary recomputes the composition hash immediately before forwarding the action to execution, and fails closed on any mismatch. Mismatch produces a binding-violation Evidence Record containing the stamped hash, the evaluation-time hash, and the forwarding-time hash — diagnostic evidence that distinguishes a legitimate hot-upgrade race from a tampered delegation. This extends the execution-bound binding of Clause 2 (action boundary primacy) to composition identity, so that the authority of a delegation extends only to actions forwarded under the stamped composition.

This authority model has a fifty-year lineage in systems security. Saltzer and Schroeder (1975) established the foundational design principles — least privilege, complete mediation, fail-safe defaults — that the architecture applies to autonomous AI action. The lineage matters, because the same structural problem has been solved before.

Clause 4’s atomicity requirement is substrate-dependent in practice: only in-process forwarding is truly atomic with the composition-hash recomputation; cross-process and cross-network forwarding must document the residual window between hash verification and action commit, and treat that window as an explicit governance variable. The enforcement boundary still fails closed on mismatch, but architectures that span process or network boundaries must make their residual atomicity window explicit, bound it, and surface it in evidence — not assume it away.

Object-side binding: the symmetric race. Clause 4 closes the race on the actor’s identity, but the canonical action’s target admits the same attack and must be closed symmetrically — otherwise the architecture leaves a clean asymmetry an adversary will take. The target is resolved during $R$, evaluated, and then executed; if nothing re-binds it, an adversary can swap the referent in the interval between ALLOW and execution — a symlink or path swap, a mutable database row whose pointer is reassigned, a DNS rebinding on an http target, a reassigned vector-store key — so that evaluation said ALLOW for resource $X$ while execution touches resource $Y$. This is the complete-mediation gap of Saltzer and Schroeder applied to the object rather than the subject. The requirement is symmetric to composition-hash atomicity: the target must be designated by a stable, content- or identity-bound reference rather than a mutable name that can be re-pointed, or the enforcement boundary must re-verify the target binding atomically with execution and fail closed on mismatch. Where neither is achievable for a class of target — late-bound names that cannot be content-addressed — object-side TOCTOU is a disclosed open frontier alongside the cross-trust-root problem, not a silently accepted gap.

Replay of legitimate artefacts. The threat model’s “evidence tampering” (Section 1) does not cover replay of a valid artefact, which is a distinct authority gap the scope/expiry/revocation checks do not close. Two vectors matter. First, a captured valid delegation token: because delegations travel like capabilities (bearer credentials), a token captured before revocation can be replayed within its temporal and revocation-freshness window to authorise an attacker’s action — nothing binds a delegation use to a single action. Revocation-freshness bounds this window but does not eliminate it; the closure is a per-action nonce or single-use binding, so a given delegation use authorises exactly one action. Second, the cross-process/network residual window above is not only a benign hot-upgrade race — it is exactly the interval in which a captured authorised action can be re-injected. It must therefore be characterised and bounded as a replay window, surfaced in evidence, not treated as a benign race. Anti-replay binds a nonce or monotonic action identifier into both the canonical action and its receipt; this is the property the pure evaluation function does not itself provide, and it must be supplied at the enforcement boundary. Replayability-for-audit (a good property of the deterministic record) and replay-resistance-of-execution (a property of single-use binding) are separate, and only the latter defends against re-injection.

The core question is where authority lives. In the access-control list tradition, authority lives at the resource: a file carries a list of permitted identities. Delegation is administrative — modify the list. Revocation is easy (remove the entry), but authority cannot travel with the actor. In the capability tradition (Dennis and Van Horn, 1966; KeyKOS, EROS, seL4, Miller’s object-capability work), authority lives with the actor as an unforgeable token that both designates a resource and conveys the right to operate on it. Delegation is natural — pass the token, pass the right. But revocation is hard: the token is a bearer credential, and revoking it means finding every copy. The revocation problem prevented capability systems from reaching mainstream deployment.

Autonomous AI systems break the ACL model’s assumptions. Authority must travel with the system — through every tool invocation, every sub-delegation, every boundary crossing — because the system accesses resources dynamically across trust boundaries no single administrator controls. The structural conditions that capability security was designed to handle have returned.

The governance architecture resolves the historical trade-off by changing when authority is verified. Delegation artefacts travel like capabilities — carried with the actor, scoped to the context, presented at the boundary. But they are verified like access-control entries — checked against current state, at every action boundary. This recovers revocation control (check status at every evaluation, deny if stale or unverifiable) without sacrificing delegation fluency (the artefact still travels with the actor).

Two properties extend beyond what either classical tradition provided. First, deterministic evaluation: the decision function is pure, its output reproducible by any party with the same inputs — a property that kernel-level capability checks, rendered opaquely, never offered. Second, cryptographic evidence: every evaluation produces a chained receipt that any third party can verify. Classical capability systems could enforce authority at the point of action, but could not prove to a third party that enforcement occurred correctly. The receipt closes that gap.

The confused deputy problem — Hardy (1988) — dissolves under this model. The confused deputy arises when authority is ambient: a program cannot distinguish its own authority from the caller’s. In the delegation model, authority is not ambient. It is carried, scoped, and presented. The authorisation plane evaluates the delegation, not the identity. A system with broad capabilities but a narrow delegation can only exercise the narrow delegation. Only the presented delegation matters.

The consequence for governance of autonomous AI action is direct: delegation semantics are not an optional feature of the authorisation layer. They are what transforms coarse-grained permission checks into action-level governance — the difference between “this system may access the database” and “this system, under this delegation, may write this field in this record, right now, and here is the proof.”

8. Enforcement Planes and Control Surfaces

The preceding sections established the architecture: three planes, deterministic evaluation, delegation semantics. But architecture describes the mechanism. The question now is: where must the mechanism be deployed? Section 1 identified six existing control categories and the governance concern that none provides. This section examines the enforcement planes and control surfaces within the governance architecture itself, each governing a distinct category of consequence-producing action.

A security team at a healthcare company deployed action-boundary governance at the tool boundary. Every tool invocation was evaluated against policy. Every evaluation produced a receipt. The team was confident. Then an internal audit discovered that one of their autonomous AI systems had been writing patient identifiers to a vector store — not through a governed tool call, but through the system’s built-in memory persistence layer, which the governance system never saw. The system’s tool invocations were impeccable. Its memory writes were invisible. Forty thousand patient identifiers sat in an ungoverned store for three months before anyone noticed.

The tool boundary was governed. The memory boundary was not.

One governed plane is not a governed system.

An enforcement plane is a category of runtime surface where an autonomous AI system’s capability can be authoritatively constrained, observed, or audited. Not every consequential surface qualifies: a surface whose controls are probabilistic rather than deterministic is a control surface, not an enforcement plane. The six enforcement planes and one control surface are the current enumeration. The count is not sacred — the derivation principle is: wherever autonomous action can produce consequences through a boundary that no existing plane or control surface covers, a new one is required.

1. Tool Boundary. Every tool invocation — API call, database query, file write, service request — crosses this boundary. Enforcement is strong: not just whether the system may invoke a given tool, but whether this specific invocation, with these parameters, under this delegation, is authorised. The limit: sequences of individually permitted actions that collectively violate policy require cross-invocation analysis that per-invocation enforcement cannot provide.

2. Runtime Boundary. Process isolation, file system controls, network restrictions, resource limits, system call filtering — the interface between the system and its execution environment. These controls are intent-agnostic: they constrain the execution envelope regardless of purpose.

3. Code Execution Boundary. The meta-capability plane. Code execution can replicate any constrained tool, access any store, and reach any endpoint — a raw socket instead of the governed http adapter, a direct database driver instead of the governed query path — bypassing every other plane’s defined interfaces. Distinct from runtime containment: this boundary governs the introduction of executable capability, not the environment in which it runs. Static analysis faces a fundamental limit: the full behaviour of arbitrary code is undecidable in the general case. The plane resolves this honestly by governing the decidable question — may this actor introduce executable capability under this delegation?, a yes/no the evaluator decides like any other action — and not the undecidable question of what the code will do. Failing closed here is denying the capability, not predicting the behaviour; this does not re-collapse into the workflow-engine limitation of Section 2, because what is constrained is the introduction of a meta-capability, not the reasoning that proposed it. Residual behaviour of code that is admitted is contained downstream by the runtime boundary (plane 2) and measured as residual risk by the weakest ungoverned plane, below.

4. Data Boundary. Access scope, query constraints, write permissions, and classification enforcement at every data store. The data boundary is where information sensitivity becomes a governance variable.

5. Memory Boundary. The preceding planes govern immediate actions. Memory governs temporal influence: conversation history, vector stores, learned preferences, and accumulated context shape future decisions and can leak sensitive information across isolated contexts. The healthcare scenario that opened this section is a memory boundary failure.

6. Network and Telemetry Boundary. The exfiltration surface: which hosts, protocols, and endpoints the system may reach, and what payloads may leave. Cannot prevent covert channels, content-semantic encoding, or third-party misuse of legitimately transmitted data.

Control Surface (Non-Authoritative).

Model Boundary. Where the tool boundary governs what the system does, the model boundary governs what it reasons about: input constraints, output filtering, model selection. The boundary is detection-oriented, not preventive — it can filter what goes in and what comes out but cannot govern the opaque transformation between the two. These controls are probabilistic and operate before action formation; they influence behaviour but do not determine whether a consequential action is authorised. The model boundary is a control surface, not an enforcement plane.

The following table summarises each plane’s governance profile:

Surface	What It Governs	What It Cannot Fully Govern
Tool boundary	Specific invocations with parameter-level, delegation-bound evaluation	Sequences of individually permitted actions that collectively violate policy
Runtime boundary	Process isolation, resource limits, system call access	Actions within the sandbox that use permitted interfaces creatively
Code execution boundary	Execution permission, sandbox, pre-execution review	Full behaviour of arbitrary code (undecidable in the general case)
Data boundary	Access scope, query constraints, classification enforcement	Purpose of access; inference from individually unrestricted data
Memory boundary	What is stored, how long, which tasks may access it	How accumulated memory influences future decisions (semantic drift)
Network/telemetry boundary	Destination, protocol, payload classification	Covert channels, content semantics, third-party behaviour
Model boundary (control surface)	What reaches the model and what it produces (input/output filtering)	The model’s internal reasoning and the causal influence of context on output

Cross-cutting principles. Every plane must produce Evidence Records — structured, tamper-evident records of governance-relevant events. A plane without Evidence Records is a plane without governance, regardless of what enforcement it performs. Security posture is defined by the weakest ungoverned plane. A denial at any enforced boundary on the execution path halts the action. All planes must evaluate the same policy version; mixed-version evaluation produces an inconsistent governance state. Evidence Records from different planes for the same action must be linked by a common action identifier, enabling cross-plane reconstruction from the Decision Ledger.

The completeness assumption, stated plainly. The “execution iff ALLOW” invariant holds only under a strong, contestable deployment assumption that the architecture must state rather than assume: every consequence-producing path is interposed by a governed boundary the agent cannot bypass. This is complete mediation in the deployment (Section 1), and it is an empirical property of how the gate is wired, not a property the model can guarantee. The plane that makes it hardest to satisfy is named already: the code-execution plane, through which an agent can reach an endpoint via a raw socket the http adapter never sees. Where a consequence-producing path evades every instrumented point, that path is the ungoverned egress, and ungoverned egress is the dominant residual risk of any real deployment — measured, per the principle above, by the weakest ungoverned plane.

The action boundary is a coverage obligation, not one physical chokepoint. In a real agent runtime there is no single universal interception point: tool calls execute inside the orchestrator’s own loop — a provider tool-use API, a graph-framework node, an MCP client. The action boundary is therefore realised as coverage across a set of concrete interception points: an MCP client or proxy, a tool-executor wrapper, a network-egress sidecar, and a resource-side gateway (the database or API in front of the resource). “An ungoverned plane” is concrete in these terms — a code path that never reaches an instrumented point. Model Context Protocol (MCP) is the closest present-day instance of the standardised action interface this thesis predicts (Section 12), and is the most useful interception point available today; its limit is exactly the coverage point — it governs MCP-routed tools, not memory writes or native-SDK calls, which is precisely the healthcare failure that opened this section.

The six enforcement planes and one control surface reflect the current taxonomy of surfaces where autonomous AI action produces consequences. If a future architecture introduces a category of consequential action that none of the current planes or surfaces governs — direct physical-world actuation, for example, or inter-system governance negotiation — the taxonomy extends. The derivation principle is stable; the count may evolve.

Tool-boundary governance is necessary but not sufficient. Governance posture is determined by plane coverage, not tool coverage. An organisation that governs tool calls and leaves memory, network, and code execution ungoverned has three open paths through which consequences — and liability — will flow. The healthcare scenario that opened this section is not hypothetical. It is the predictable result of assuming that “we govern tool calls” means “we govern the system.” Governance coverage is measured by enforced planes with Evidence Records, not by the number of governed tools.

9. Evidence-Bound Governance

The preceding sections define where governance occurs, how it decides, under what authority, and across which surfaces. One question remains: how does an organisation prove that governance happened?

Enforcement alone is insufficient. An organisation that enforces policy but cannot prove enforcement occurred is in a precarious position: governance is asserted but unverifiable. The auditor’s question is not “do you have policies?” but “can you prove the policy was evaluated before this specific action executed?”

This distinction — between governance-as-assertion and governance-as-evidence — is the epistemic boundary that separates operational controls from governance infrastructure. Section 4 established the distinction between logs (which reconstruct history) and evidence records (which prove authorisation — not intent or appropriateness). This section and the next specify the mechanism.

Evidence records must be tamper-evident and independently reconstructable. They must contain sufficient information to reconstruct the decision without access to the originating system. They must be cryptographically chained so that modification, deletion, or insertion is detectable. The precise claim is detection, not impossibility: a log can be incompletely written, filtered, or silently altered after the fact and leave no trace; tampering with a hash-chained evidence record is computationally detectable by any verifier holding an independent commitment to the ledger head (Section 10 names where that commitment lives). This is a stronger guarantee than a log offers and a weaker one than “cannot be altered” — a spec is not a property, and stating the guarantee as detectability rather than impossibility is what keeps it honest against the very adversary the architecture is sold to defend against: a dishonest operator.

Evidence-bound governance transforms compliance from a procedural claim into a verifiable system property. Instead of asserting “we have policies,” an organisation demonstrates cryptographic proof that a specific policy was evaluated against a specific action, under a specific delegation, at a specific moment, before the action executed — linked to every prior decision back to the genesis record. The strength of that proof to an outside party depends on the integrity property in force (Section 10): operator-internal under a symmetric authenticator, and non-repudiable to any third party only under an asymmetric signature whose verification key is published.

The Governance Constitution (Clause 6) encodes this requirement: every evaluation must produce an evidence record. Governance that cannot be proven is indistinguishable from governance that did not occur.

10. Evidence Records, the Decision Ledger, and Cryptographic Integrity

The evidence architecture transforms the governance system’s decisions from ephemeral runtime events into durable, independently verifiable artefacts. The mechanism is the Evidence Record: a structured artefact that binds together everything relevant to a single governance decision. Evidence Records compose into a Decision Ledger — an append-only, hash-chained, tamper-evident sequence that links every decision cryptographically to every prior decision. Where “receipt” appears in the constitutional text (Clause 5: byte-identical deterministic receipt cores), it refers to the deterministic-replay property of the Evidence Record, not a separate artefact: the receipt core is the part that replays byte-identically from the resolved inputs alone, and the envelope is the emitted record including ledger-state fields (prev_hash, seq) that replay identically only once ledger state is also fixed.

An Evidence Record binds six categories of information:

• Actor: who acted — the identity of the autonomous AI system or the human principal on whose behalf it operated.
• Action: what was proposed — the canonical action type (read, write, send, delete, execute, delegate), the enforcement boundary (tool_execution, network_egress, memory, data_access, code_execution), and the privilege classification (safe, privileged, destructive).
• Object: what was targeted — the resource identifier, its domain (filesystem, http, database, vector_index, memory_store), and its sensitivity classification.
• Delegation: under what authority — whether the delegation was valid, its kind, its scope (actions, tools, paths, domains), its temporal bounds, its revocation status, and the delegation identifier for chain traceability.
• Decision: what was decided — the outcome (ALLOW, DENY, or ESCALATE), the complete rule trace showing every rule evaluated and why it matched or did not match, and the identifier of the rule that determined the outcome.
• Evidence: integrity proofs — the request fingerprint (SHA-256 of the canonical action payload), the arguments hash, the context hash, the response hash, the policy hash, the ontology hash, and the evaluation timestamp (a resolved input artefact). Evaluation duration is recorded as operational metadata but excluded from the canonical hashed Evidence Record to preserve replay equivalence.

Each of these elements is present in every Evidence Record, regardless of the decision outcome. Denial records carry the same structure as approval records. This is deliberate: a denial Evidence Record is the mechanism that proves enforcement occurred. Without it, an auditor cannot distinguish “the system did not attempt the action” from “the system attempted the action and was blocked.”

Cryptographic binding. The Evidence Record’s integrity rests on three separable properties that must not be conflated, because each defends against a different adversary:

• Tamper-evidence — the hash chain (below) makes modification, deletion, and insertion detectable to a verifier holding an independent reference point. It says nothing against a party who holds that reference point and can re-chain.
• Integrity (message authentication) — a keyed authenticator binds a record to a holder of the key. The compiled policy is identified by its SHA-256 hash; the compiled ontology bundle by its SHA-256 hash; the canonical action is serialised to canonical JSON (deterministic key ordering) and fingerprinted. A keyed integrity authenticator over the canonical Evidence Record binds the decision to these artefacts. If the policy, ontology, or action representation is changed, the corresponding hash will not match; if the record is altered, the authenticator will not verify.
• Third-party non-repudiation — the property that any party, not merely the key-holder, can verify the record and that the producer cannot later disown it. This requires an asymmetric signature.

The distinction is load-bearing and was previously blurred. A symmetric authenticator such as HMAC-SHA256 satisfies Clause 6’s collision-resistance minimum and is unforgeable under chosen-message attack as a MAC, but it has no public key: anyone able to verify it is also able to forge it. HMAC therefore provides operator-internal integrity only — it cannot deliver “verifiable by any party with the relevant public keys,” because no such public key exists, and a dishonest operator who holds the key could mint a valid authenticator over a false record. Public, non-repudiable, third-party verification — the property the rest of this document promises (“a signed warrant any third party can verify”) — requires an asymmetric signature over the record hash (for example Ed25519). This architecture treats asymmetric signing of evidence records as a stated requirement for third-party non-repudiation; where an implementation ships only HMAC, the honest claim is operator-internal integrity, and the third-party-verification claim is not yet met. Each binding is independently verifiable to the extent the corresponding property is in place — not beyond it.

Hash-chained ledger. Evidence Records compose into the Decision Ledger — a tamper-evident chain. The chain begins with a genesis hash:

$$h_0 = \texttt{0}^{64} \quad \text{(the 64-character hexadecimal string of zeros — null SHA-256 digest)}$$

Each subsequent Evidence Record includes the hash of the previous record. Let $R_n$ be the record obtained by inserting the fields $\text{prev\_hash} = h_{n-1}$ and $\text{seq} = n$ into $\text{payload}_n$ at the top level before canonical serialisation. The record hash is:

$$h_n = \text{SHA-256}(\text{canonical\_json}(R_n))$$

The Decision Ledger therefore has the form $h_0 \to r_1(h_1) \to r_2(h_2) \to \cdots \to r_n(h_n)$, where each Evidence Record’s hash covers its payload, the previous hash, and the sequence number.

This structure provides three tamper-detection properties. Modification of any Evidence Record breaks the hash computation for the next record — the stored prev_hash will not match the recomputed hash. Deletion of any Evidence Record creates a gap — the prev_hash of the next record references a record that no longer exists. Insertion of a record between two existing records produces hash mismatches on both sides — the new record’s prev_hash matches its predecessor, but the original successor’s prev_hash still references the original predecessor.

The chain is self-referential without an external anchor. These three properties detect tampering only relative to a reference point a verifier already trusts. Against a dishonest operator who controls the whole store, they are insufficient on their own: an operator can silently re-chain the entire ledger from genesis, recomputing every hash, and present an internally consistent but falsified history. Detecting this requires the ledger head to be externally anchored — its head hash published or committed where the operator cannot quietly rewrite it: notarised to a transparency log, co-signed by a counterparty, or periodically checkpointed to an independent witness. This is the constitution’s requirement that the trust root be “explicitly defined, independently inspectable, and independent of the governance system under verification” (Clause 6); self-attested trust roots do not satisfy it. Tamper-evidence is real, but it is tamper-evidence against a party who does not hold a trusted reference point — and the external anchor is what supplies that reference point to the auditor.

Verification cost. Verifying a record by re-hashing the entire history from genesis is $O(n)$ and does not scale to a ledger positioned as ever-growing infrastructure. The structural answer, stated in Section 6, applies here: periodic signed checkpoints (Merkle roots over the sub-chain heads) reduce verification of any record to an $O(\log n)$ inclusion proof against a trusted checkpoint, so verification cost is independent of ledger age while tamper-evidence is preserved.

Independent reconstructability. The Evidence Record contains sufficient information to reconstruct the decision without the originating system. An auditor who obtains a record and the referenced policy and ontology bundles (identified by their content hashes) can assemble the same canonical inputs and replay the evaluation. Replay equivalence — the constitutional requirement that identical resolved inputs produce a byte-identical deterministic receipt core (Clause 5) — means the replayed evaluation must produce the same decision, the same rule trace, and the same evidence hashes; the full envelope replays identically once ledger state is also fixed. Replay uses the preserved resolved inputs exactly as they were materialised during the original resolution phase, including the original timestamp artefact. Runtime metadata that is not deterministic — such as evaluation duration — is excluded from the canonical hashed Evidence Record and therefore does not affect replay equivalence. If replay with preserved inputs does not produce a byte-identical record, either the record was tampered with or the evaluation was non-deterministic. Both are governance failures.

Consequence markers. The Evidence Record records that an action was authorised; the consequence marker records that the authorised action occurred. Clause 6 requires this contract: a consequence marker, cryptographically linked to the evidence record, for every external consequence. In this architecture, that marker is required for any action that passes the irreversibility test: the action produces an external state change that the requesting system cannot unilaterally undo (a transfer posted, a record deleted, a message transmitted, a deployment triggered). Every such marker must carry three required fields: (1) an execution event identifier stable enough to be referenced by the downstream system; (2) a cryptographic link to the corresponding Evidence Record’s record_hash, so that authorisation and consequence are mutually verifiable; and (3) a time-authority timestamp asserting when the consequence was observed, sourced from the same trusted time authority that issued the evaluation timestamp. The marker is emitted by, or verifiably derived from, the enforcement boundary; best-effort logging does not satisfy this requirement. Where the architecture cannot yet guarantee a marker for a class of consequence — the gap recorded in current implementations between authorised forward and outcome append — that gap is itself a disclosure obligation: the system must declare the unmarked classes explicitly rather than allow silent gaps in the consequence record.

Over time, the Decision Ledger transforms governance from an internal operational practice into independently auditable infrastructure. The ledger begins at genesis and accrues from that moment forward. Starting the ledger later means a new genesis — and the gap between the old ledger’s end and the new ledger’s beginning is permanent and detectable. There is no way to backfill Evidence Records retroactively without breaking the ledger’s integrity properties.

The Decision Ledger is what makes governance infrastructure, not just a runtime control. A runtime control enforces policy in the moment and leaves no trace. Infrastructure produces durable, independently verifiable artefacts whose integrity can be confirmed by any authorised party. The ledger is the output that makes governance real.

11. Why Governance Must Be Independent of AI Vendors

Enterprises deploy autonomous AI systems from multiple vendors, across multiple environments, using frameworks that evolve rapidly. A financial services firm may use one model provider for document analysis, another for customer interaction, and a third for internal workflow automation. These systems interact with the same databases, the same APIs, and the same infrastructure. The governance question — was this action authorised? — must be answerable regardless of which vendor’s model proposed the action.

If governance is coupled to a specific model provider, it inherits that dependency. Change the model and governance semantics may change. Switch providers and governance controls may not transfer. Upgrade a framework and policy enforcement may silently alter. This coupling is not a commercial inconvenience — it is an architectural failure. Governance that changes when the system it governs changes is not governance; it is a feature of the governed system. And features of the governed system are controlled by the governed system’s vendor, not by the organisation that needs the governance.

The independence requirement operates across three dimensions.

Model-neutral. The authorisation layer evaluates canonical actions, not model outputs. The canonical action representation abstracts away model-specific formats, tool-calling conventions, and output structures. Whether the action was proposed by a Claude model, a GPT model, an open-source model, or a model that does not yet exist, the authorisation plane receives the same canonical representation: actor, intent, target, parameters, delegation, policy identity. The evaluation is indifferent to the model’s identity. It evaluates the action.

Framework-neutral. Governance semantics must be invariant across SDKs, toolchains, and orchestration frameworks. The Governance Constitution’s Clause 9 (Provider Neutrality) is the substitution test — operationally distinct from Clause 8 (which covers evolution; see Section 5). Clause 9 requires that replacing a provider, framework, or infrastructure component must not change authorisation outcomes in the absence of an explicit policy change. This means the canonical vocabulary, the evaluation logic, and the evidence format must not depend on any specific framework’s conventions, lifecycle hooks, or integration patterns. If a framework upgrade silently alters what is allowed, governance is not framework-neutral and cannot be honestly audited as a stable control.

Framework neutrality has a subtlety that only becomes visible under adversarial pressure. Adapters translate framework-specific events into canonical actions, and those adapters operate under a canonical schema — the structure of fields, types, and normalisation rules that defines what a canonical action is. A framework upgrade that changes the adapter’s schema (moving a target field from a flat string to a nested object, say) changes the shape that policies pattern-match against. Existing delegations remain syntactically valid but semantically misaligned: scope patterns authored against the old schema either vacuously match the new shape (silent widening) or vacuously fail (silent narrowing). No policy change event fires, yet the deployment’s authority distribution has moved. The Governance Constitution’s canonical schema binding (Clause 9) closes this: provider neutrality holds only within a fixed canonical-schema identity, where the schema identity is the cryptographic content hash of the schema under which adapters project runtime events into canonical actions. The schema identity is recorded in every Evidence Record and every compiled policy; policies are valid only against the schema identity they were compiled against; adapter schema changes are constitutional drift events under Clause 10 and require versioned re-compilation of every affected policy before the new schema may produce evaluations. Framework neutrality becomes a claim that can be honestly audited, bounded by an artefact identity that the Decision Ledger can verify.

Runtime-neutral. The authorisation layer must operate wherever the action boundary exists — in cloud environments, on-premise infrastructure, at the edge, in containers, in serverless functions. The evaluation function’s behaviour must not depend on the runtime environment. A decision rendered on one infrastructure must be identical to the decision rendered on any other infrastructure, given the same inputs. This is a direct consequence of determinism (Section 6): if the evaluation function is pure, its output depends only on its inputs, not on where it runs.

There is a deeper structural argument. The entity being governed should not also control the governance mechanism. This is not a novel principle — it is the foundation of auditing, regulatory compliance, and institutional governance across every regulated industry. Financial auditors must be independent of the firms they audit. Regulatory bodies must be independent of the industries they regulate. The same structural requirement applies to the governance of autonomous AI action. If the governance mechanism is provided by the same vendor that provides the reasoning system, the vendor controls both what the system does and what it is allowed to do. Separation of concerns at the organisational level — not just the architectural level — requires that governance be independent.

Governance must outlast the systems it governs. Model providers will be replaced. Frameworks will evolve. Runtimes will change. The governance layer — with its evidence chain, its policy history, its delegation records — must survive these transitions. An evidence record produced under one vendor’s model must remain interpretable, replayable, and verifiable after that vendor has been replaced. This is only possible if the governance layer is architecturally independent of the systems it governs.

Independence is not a strategic positioning choice. It is a structural requirement of any governance layer that claims to be durable.

A Two-Sided Ideality Ledger

The argument so far has tallied the benefits of the layer and the cost of doing without it. An honest case must also debit what the gate itself introduces — because inevitability follows from net ideality, not gross benefit, and a reader doing the calculation should be able to see both columns. The gate adds three new harms, and the architecture’s claim is not that they vanish but that each is driven toward zero by a stated mechanism.

Debit the gate introduces	Why it is a real harm	Mechanism that drives it toward zero
A new mandatory in-path dependency on every consequence-producing action	A transient outage of the resolution dependencies (time authority, revocation) can fail-close the whole fleet — fail-closed correctly refuses degrade-to-allow, but its cost is a denial-of-service lever	Bounded freshness window as the explicit integrity-vs-availability knob: the common case is a local cached read, so only a sustained genuine outage halts privileged action; resolution dependencies engineered for high availability and caching
A new high-value attack target	Compromise the gate and you hold authority over every governed system — concentration is a forge-everything target	The concentration is also an asset: one small, formally analysable, tamper-evident plane is more hardenable and more auditable than diffuse embedded controls, and its own compromise is detectable and replayable through externally anchored evidence (Section 10). Smaller is harder to subvert and easier to watch
A new operational burden	Policy authoring, and schema re-compilation on every adapter change (Section 11), are ongoing costs the prior architecture did not carry	Versioned, content-addressed policy and schema make the burden explicit and auditable rather than ambient; drift that would otherwise be silent becomes a reviewable event (Clause 10)

Two failure modes must be kept distinct, because conflating them is what tempts operators to widen freshness windows or bypass the gate. An integrity-critical denial — refusing an action whose authority cannot be positively verified — is the gate working correctly. An availability-of-governance failure — the gate halting actions because its own dependencies are unreachable — is a different failure mode, a property of how well the resolution substrate is engineered, not of the governance semantics. The architecture is sound on the first by construction; it is operable on the second only to the degree the time and revocation services are made highly available and cacheable within their freshness bounds. Stating this is what separates a credible fail-closed stance from an aspirational one.

Independence and the in-path location are two different axes that this ledger keeps apart: different control is a property of policy ownership, key custody, and evidence anchoring; inline is a property of where the enforcement point sits. A plane can be model-swap-invariant yet still captured if it is operated by the same party whose actions it governs and whose fate it shares — so swap-invariance is a necessary symptom of independence, not its definition.

12. Evolution Toward an Authorisation Layer

Sections 1 through 11 have established what governance of autonomous AI action requires and why it must be independent. The architectural argument is complete. This section makes the historical argument: these requirements converge on an independent authorisation layer, and the convergence follows a trajectory the technology industry has traversed before.

12.1 The Pattern

Every major infrastructure layer follows the same trajectory: a capability begins embedded in applications, separates into a standalone product, converges on a platform standard, and becomes infrastructure so fundamental that serious systems cannot operate without it.

Each transition is driven by the same structural forces: heterogeneity demands neutrality (the capability must work across diverse systems), audit demands evidence (decisions must be provable), scale demands automation (manual processes cannot keep pace), and trust demands independence (the control mechanism must be independent of the systems it controls). These forces apply to governance of autonomous AI action with the same structural pressure they applied to identity, networking, orchestration, and payments.

12.2 Identity

The login screen began as an application feature. Each application managed its own user database, its own authentication logic, and its own session management. In the 1990s, directory services like LDAP externalised identity into standalone products — centralised user stores that multiple applications could authenticate against. OAuth and OpenID Connect transformed identity into a platform standard: federated, token-based, and interoperable across vendors. Today, identity is foundational infrastructure. No serious application is built without it. No enterprise operates without an identity provider. The question “do you have identity infrastructure?” is rhetorical — the answer is always yes.

The key transition: identity separated from the application and became an independent service. Before the separation, every application reinvented authentication — each with its own user table, its own password hashing, its own session management, and its own vulnerabilities. After separation, applications delegated identity to a shared, auditable, standards-based layer. The arguments against separation were familiar: “our application’s identity needs are unique,” “we cannot afford the integration overhead,” “it is simpler to manage our own users.” These arguments lost. The structural forces — heterogeneity, audit, scale, trust — made separation inevitable. First embedded control, then centralised control, then neutral infrastructure.

12.3 Networking

Networking protocols began embedded in application logic. Early networked applications managed their own routing, connection handling, and protocol negotiation. BGP and standardised routing protocols externalised network decision-making into dedicated infrastructure. Software-defined networking (SDN; McKeown et al., 2008) abstracted the network control plane from the data plane: routing decisions are made by a centralised controller, and network devices execute those decisions without making independent routing judgements. Today, programmable network infrastructure is a standard architectural primitive. The control plane is independent of the data path.

The key transition: routing logic separated from application code and became an independent control plane. Before SDN, every network device made its own forwarding decisions based on locally maintained routing tables. After SDN, a centralised controller renders forwarding decisions, and network devices execute them. The SDN pattern — deciding independently, executing separately — is structurally identical to the three-plane architecture described in Section 5.

12.4 Container Orchestration

Deployment logic began as shell scripts and ad-hoc automation. Configuration management tools — Chef, Puppet, Ansible — externalised deployment into standalone products. Kubernetes transformed container orchestration into a platform: declarative, self-healing, and vendor-neutral. Today, Kubernetes is infrastructure. The question is not whether to use container orchestration but which implementation to deploy.

The key transition: deployment logic separated from applications and became declarative infrastructure. Before separation, deploying an application meant writing bespoke scripts that encoded operational knowledge in imperative procedures. After Kubernetes, applications declare their desired state, and the orchestration layer converges the actual state toward it. The governance analogy is direct: autonomous AI systems propose actions; the authorisation layer ensures that only authorised actions execute.

12.5 Payments

Payment processing began embedded in merchant applications. Each merchant managed its own payment logic, fraud detection, and settlement — a fragmented landscape where every point of sale was an island. Payment gateways externalised processing into standalone products. Visa, Mastercard, and the card network infrastructure transformed payments into a platform: standardised, interoperable, and trust-bearing. Today, payment infrastructure is foundational. Every transaction flows through an authorisation network that evaluates the transaction, renders a decision (approve or decline), and produces a record — before the transaction executes.

The structural parallel to governance of autonomous AI action is close on the points that matter to this thesis. A customer presents a card (delegation artefact). The merchant submits the transaction (proposed action). The card network evaluates it against the cardholder’s account constraints (policy evaluation). The network renders an authorisation decision (ALLOW or DENY). The decision is recorded (evidence). The merchant can only execute the transaction if the network authorises it (pre-execution governance). The receipt proves the authorisation occurred (evidence-bound governance). Replace “customer” with “human principal,” “card” with “delegation token,” “merchant” with “autonomous AI system,” and “card network” with “authorisation layer,” and the structural pattern — independent pre-execution authorisation plus a durable receipt — carries over directly.

The analogy must be narrowed deliberately, because the parallel is structural and not operational. Card networks achieve their availability partly through mechanisms this architecture explicitly rejects: stand-in processing (when the issuer is offline, the network approves on its behalf), asynchronous settlement, and chargeback reversibility. Those are degraded-mode, approve-when-unsure, reverse-later behaviours — precisely the “log and allow” and “no degraded mode” that Section 6 forbids. The reason for the divergence is the irreversibility profile of the governed action: a card transaction is, in the common case, chargeback-reversible, so a payment network can rationally fail open and reconcile afterwards; many autonomous-agent actions (a deployment triggered, data exfiltrated, a record deleted) are not reversible, so governance of those actions must fail closed. The payments network is the right exemplar for independent pre-execution authorisation with a proof artefact, and the wrong exemplar for what to do when the authoriser is unsure — borrow the structure, not the availability model.

The key transition: payment authorisation separated from merchants and became an independent network. Before the separation, each merchant made its own credit decisions — with predictable consequences for fraud and trust. After it, an independent network rendered authorisation decisions before transactions executed, and the evidence record proved to all parties that governance occurred. First embedded control, then centralised control, then neutral infrastructure.

12.6 Governance of Autonomous AI Action

Governance of autonomous AI action is currently transitioning through the same trajectory.

Feature stage (current dominant pattern). Guardrails embedded in frameworks, application-level checks, prompt engineering constraints. Governance logic is coupled to specific models, frameworks, and applications. Each deployment reinvents its controls. There is no shared vocabulary for describing actions, no standard format for policy, and no mechanism for producing evidence that governance occurred. This is where most enterprise deployments sit today — functionally equivalent to the era when each application managed its own user database.

Product stage (emerging). Policy engines, governance platforms, and centralised rule systems that externalise governance from individual applications. Controls become configurable and auditable, but remain coupled to specific vendor ecosystems or framework integrations. An organisation using a governance product can demonstrate that it has policies, but the policies may not be independently verifiable, the evidence may not survive vendor changes, and the governance semantics may be implicitly coupled to a specific model provider or framework version. This stage parallels the LDAP era of identity: centralised but not yet federated, useful but not yet infrastructure.

Platform stage (near-term). Standardised governance interfaces, canonical action vocabularies, and interoperable policy formats. Governance becomes vendor-neutral and composable across systems. Multiple autonomous AI systems from different providers are evaluated against a single compiled policy using a shared canonical vocabulary. Evidence Records become interoperable — a record produced by one deployment is structurally identical to a record produced by another. This stage parallels the OAuth/OIDC moment for identity: the point where federation and interoperability become expected properties rather than differentiating features. This is also where a real adoption gap is closed honestly. The composition model of Section 5 assumes each handoff carries an explicit, schema-stable, content-hashed coordination artefact and a monotonically narrowing delegation — but today’s multi-agent systems (planner/executor splits, agent-to-agent protocols, swarm and handoff patterns, dynamically spawned sub-agents) mostly pass free-form messages or shared scratchpad state with no carried authority token and no stable schema. The criteria therefore describe how agents must be built to be governable, not how most are built now; bridging that distance — adapters that project native framework events onto schema-bound coordination artefacts — is precisely the platform-stage work, the standardisation event that turns the criteria from an aspiration into a default.

Infrastructure stage (destination). The authorisation layer for autonomous AI action becomes foundational — a standard architectural component without which autonomous AI systems cannot credibly operate. Decision Ledgers become auditable infrastructure. Evidence Records become the proof artefacts that regulators, auditors, and counterparties require. The question “do you have governance infrastructure?” becomes as rhetorical as “do you have identity infrastructure?” Not having it is not a competitive disadvantage — it is a disqualification from regulated markets, enterprise procurement, and high-stakes deployment.

12.7 Common Structural Forces

The same four forces drove every prior transition. They are now driving governance.

Heterogeneity demands neutrality. Enterprises deploy autonomous AI systems from multiple vendors, using multiple frameworks, across multiple environments. Governance that is coupled to one vendor cannot govern the others. The governance layer must be neutral across the ecosystem it governs — the same structural force that drove identity from per-application databases to federated protocols.

Audit demands evidence. Regulatory and institutional requirements demand proof, not assertion. “We have policies” is insufficient; “here is cryptographic proof the policy was evaluated” is required. The governance layer must produce durable, independently verifiable evidence — the same structural force that drove financial transaction processing from merchant records to network-level authorisation receipts.

Scale demands automation. Autonomous AI systems execute hundreds or thousands of actions per minute. Manual review cannot keep pace. Governance evaluation must be automated, deterministic, and real-time — the same structural force that drove network routing from manual configuration to software-defined control planes.

Trust demands independence. The governance mechanism must be independent of the systems it governs. A model provider that also controls the governance mechanism controls both the actor and the rules — an untenable concentration. The governance layer must be organisationally and architecturally independent — the same structural force that drove financial auditing to require independent auditors.

The TRIZ S-curve model provides a complementary lens. The current ecosystem is transitioning from Stage 1 (framework-embedded governance, characterised by rapid feature accumulation and vendor differentiation) through Stage 2 (product governance, characterised by centralisation, configurability, and vendor-specific platforms) to Stage 3 (platform governance, characterised by standardisation, consolidation, and interoperability). Stage 4 (infrastructure governance, characterised by ubiquity, commoditisation, and foundational status) is the destination. The trajectory is not speculative. It is the same structural trajectory that every major infrastructure layer has followed.

A rigorous reading of the S-curve must also ask what disanalogy could stall the curve short of Stage 4 — leaving governance a useful product (Stage 2) that never becomes infrastructure. The strongest such risk is latent in this paper’s own disclosures. Identity, payments, and SDN reached infrastructure status because a shared trust root and a shared schema were standardisable: OAuth and OIDC standardised federation, the card networks standardised the inter-bank trust root, OpenFlow standardised the controller-switch interface. The corresponding standardisation event for governance is the cross-root composition problem (Section 5), which this paper concedes is not yet doctrinally specified, together with the canonical-schema binding that makes cross-deployment evidence comparable (Section 11). The honest framing is therefore directional rather than triumphal: governance reaches infrastructure status when, and to the extent that, cross-root composition and a shared canonical schema are standardised — exactly as identity reached it only when federation was standardised. The open problem is not a refutation of the inevitability thesis; it is the predicted next standardisation event on which Stage 4 turns.

The question is not whether governance of autonomous AI action separates into an independent layer. It is when — and the gating condition is named, not waved away.

13. The Control Plane for Autonomous AI Systems

The three-plane separation described in Section 5 positions the authorisation layer as a control plane for autonomous AI action. This is a structural parallel, not a metaphor — the same architectural pattern recurs wherever systems grow complex enough that deciding must be separated from executing.

Control plane / data plane separation is the defining architectural pattern of scalable infrastructure:

Domain	Control Plane	Data Plane
Networking	SDN controller	Network switches and routers
Cloud orchestration	Kubernetes API server	Container runtimes and nodes
Identity	OAuth/OIDC provider	Application sessions and tokens
Payments	Card network (Visa, Mastercard)	Point-of-sale terminals and merchant systems
Autonomous AI action	Authorisation layer	Reasoning and execution systems

In every case, the control plane shares the same properties: it is independent of the data path (routing decisions are not made by routers in SDN; authorisation decisions are not made by models in governance). It applies deterministic decision semantics (given the same routing table and packet header, the same forwarding decision; given the same policy and canonical action, the same authorisation decision). It is observable and auditable (routing tables can be inspected; evidence chains can be verified). And it survives replacement of individual components (replacing a switch does not change routing policy; replacing a model does not change governance policy).

The authorisation layer for autonomous AI action exhibits all four properties. It is independent of the reasoning and execution systems it governs. It renders deterministic decisions based on compiled policy and canonical inputs. Its evidence chains are independently verifiable. And it survives the replacement of any individual model, framework, or runtime — because its evaluation is defined by policy, not by the systems it evaluates.

The pattern recognition matters because it makes the architecture immediately comprehensible to the audience that funds, deploys, and operates enterprise infrastructure. An executive who understands SDN understands that network decisions should not be made by individual switches. An executive who understands payment networks understands that transaction authorisation should not be embedded in merchant applications. The same executive can understand that governance decisions for autonomous AI action should not be embedded in the reasoning systems that propose those actions. The authorisation layer is not a security tool bolted onto autonomous AI systems. It is the control plane that makes autonomous AI action governable.

The naming also clarifies what governance is not. Governance is not a feature of the reasoning system (any more than routing is a feature of a web server). Governance is not a monitoring layer that observes actions after the fact (any more than SDN is a packet capture tool). Governance is not a guardrail that constrains model outputs (any more than a firewall is a content filter). Governance is the control plane: the independent, deterministic, evidence-producing layer that decides whether proposed actions proceed. The claim that the alternatives collapse is definitional, not merely rhetorical: a deciding component is either independent of the data path it governs or it is not. If it is not — if the reasoning system, the execution layer, or a model-output filter renders the decision — then the deciding function lives inside the data plane, and the governed system controls its own governance. The three named alternatives are exactly the three places the decision can fall inside the data plane (the reasoning system, the post-execution monitor, the output guardrail); each is a control-plane-into-data-plane collapse, and each produces the same structural failure. The control plane is what remains once those collapses are excluded by definition.

14. The Ambit Infrastructure Vision

The trajectory described in the preceding sections converges on a single destination: the authorisation layer for autonomous AI action. Ambit’s vision is to build that layer.

The destination is not a product. It is an inevitability.

Autonomous AI systems can scale only if authorisation becomes infrastructure. Three structural pressures make this convergence unavoidable, and they are accelerating simultaneously.

Capability pressure. Models become more powerful with each generation. Each increase in capability widens the action space — more tools, more complex delegation chains, more coordination topologies, more categories of consequence. The governance gap does not shrink as capability grows. It widens.

Risk pressure. Enterprises deploying autonomous AI systems in consequential domains — financial services, healthcare, infrastructure, government — require deterministic guarantees about action authorisation. A system that can move money, modify patient records, or alter infrastructure without verifiable authorisation is not deployable in any regime that demands accountability.

Regulatory pressure. Regulatory frameworks increasingly require not just policy but proof. The regulatory trajectory — from principles to requirements to enforcement — follows the same path that drove financial transaction processing from merchant assertions to network-level authorisation receipts.

These pressures do not create demand for a product. They create demand for infrastructure. Any serious autonomous AI system will eventually require an independent authorisation layer — for the same structural reasons that every serious application requires identity infrastructure, every serious network requires a control plane, and every serious financial transaction requires an authorisation network.

The governance of autonomous AI action will converge on an independent authorisation layer. Not because a company chooses to build it, but because the architecture of autonomous systems leaves no alternative. The question is not whether this layer will exist. It is who builds it, and whether the organisations that need it recognise the requirement in time.

The Governance Constitution encodes the invariants that the authorisation layer must satisfy:

No action without evaluation. No evaluation without delegation. No delegation without scope. No decision without evidence. No evidence without integrity. No composition without governance.

That is the governance contract. It is not optional — it is the structural requirement of any system that must be simultaneously autonomous and governed. The authorisation layer is the mechanism that satisfies it.

Ambit Systems exists to build that mechanism.

Selected References

Altshuller, G.S. (1999). The Innovation Algorithm: TRIZ, Systematic Innovation and Technical Creativity. Technical Innovation Center, Worcester, MA.

Dennis, J.B. & Van Horn, E.C. (1966). “Programming Semantics for Multiprogrammed Computations.” Communications of the ACM, 9(3), 143–155.

Hardy, N. (1988). “The Confused Deputy: (or why capabilities might have been invented).” ACM SIGOPS Operating Systems Review, 22(4), 36–38.

McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S. & Turner, J. (2008). “OpenFlow: Enabling Innovation in Campus Networks.” ACM SIGCOMM Computer Communication Review, 38(2), 69–74.

Saltzer, J.H. & Schroeder, M.D. (1975). “The Protection of Information in Computer Systems.” Proceedings of the IEEE, 63(9), 1278–1308.