From Confused Deputies to Execution Governance

Research programme. The Governance of Autonomous Action establishes the conceptual foundations of execution governance. This paper develops the architecture. The Ambit Infrastructure Thesis examines why this governance layer becomes infrastructure.

Introduction

Modern autonomous systems expose a structural weakness in contemporary computing. They increasingly interact with external tools, APIs, and infrastructure: reading data, sending messages, updating databases, and triggering real-world processes. Yet the mechanisms used to govern these actions are largely inherited from earlier generations of computing — systems designed for human users and relatively predictable software behaviour.

This mismatch between autonomous capabilities and legacy governance models has produced a series of failures that are now widely visible: prompt injection attacks, tool misuse, unintended data exfiltration, and uncontrolled agent interactions. To understand why these failures occur, it is necessary to revisit a sequence of foundational ideas in computer security and systems architecture: the confused deputy problem, capability-based security, and the separation of control and execution in distributed systems. Together, these ideas explain why current governance mechanisms fail and what architecture must replace them.

This paper argues for a specific architectural response. Execution governance is the deterministic evaluation of proposed actions at the execution boundary, before they produce consequences, together with tamper-evident evidence for every decision. The execution boundary is the point at which a proposed action transitions from internal system intention to an operation capable of producing external consequences — a database write, an API call, a message sent, a process triggered.

Because this is the layer at which the architecture is stated formally, the paper first fixes the adversary it claims to defend against. Every guarantee below is conditional on that model, and the conditions are named rather than assumed.

The intellectual lineage begins with the confused deputy problem.

Threat Model and Trusted Computing Base

The guarantees this paper makes are not unconditional. They hold relative to a stated adversary and a stated trusted computing base (TCB). Naming both before the invariant is what converts the load-bearing claims — complete mediation, tamper resistance, deterministic replay — from asserted structural facts into precise conditional statements that survive adversarial scrutiny.

Adversary. We assume a capable adversary who may: compromise the reasoning plane (prompt injection, indirect context poisoning, a confused or malicious agent, multi-agent collusion, memory-mediated escalation); supply malformed or smuggling-shaped action payloads; capture and replay previously authorised actions; attempt to race the interval between evaluation and execution; and attempt to disrupt the resolution dependencies (revocation, policy distribution, time) on which fail-closed decisions rest. The adversary does not hold the credentials that the governance plane custodies, cannot forge the plane’s signing keys, and cannot subvert the plane’s own code or clock. The boundary between what the adversary controls and what is trusted is the TCB.

Trusted computing base. The architecture trusts: (1) Interposition — that consequential actions have no route to their target except through the governance plane (defined below); (2) The plane’s integrity — its evaluation code, its policy- and receipt-signing keys, and its access to a trusted time authority; (3) An independently held commitment to the evidence chain head, against which a verifier checks the receipt stream. Everything outside this base is treated as hostile.

Interposition (the complete-mediation precondition). Complete mediation is not a property the architecture confers by existing; it is a property a deployment must establish and the architecture then depends on. A governed action must have no path to consequence that does not traverse the plane. In practice this is achieved by placing the plane on the only path to the credentials or the egress: the plane (or a co-located sidecar) custodies the real credential to the target and releases it only on ALLOW; a governing MCP proxy mediates every tool-call request; an egress gateway holds the sole route to the external network; or the orchestrator’s tool-dispatch is wrapped so no tool fires un-mediated. An action issued outside this interposition does not bypass governance — it physically cannot execute, because it never reaches a credential or a route. This is the architectural form of the Constitution’s requirement that all execution paths capable of external consequence pass through evaluation; where a deployment cannot establish it for some path, that path is a disclosed ungoverned gap, not a silently trusted one.

The honest source-independent claim must be stated exactly, because it is the architecture’s strongest move and easily overstated. Governance does not detect or prevent a component being induced to propose an attacker-chosen action — prompt injection, context poisoning, and confused-deputy manipulation all succeed at the level of proposal, and a hostile in-scope action is, by design, indistinguishable from a benign one. What governance does is bound 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 a malicious one, with no dependence on the model’s cooperation. The load-bearing corollary is therefore that governance is only as strong as the tightness of the delegation — an over-broad delegation re-opens the gap, because everything it permits remains permitted no matter who or what proposes it. This is why scope-narrowing, not proposal-filtering, is the real control, and why the shared context the examples use — itself the injection surface — must be governed by what the delegation authorises rather than trusted because it is well-formed.

Every enumerated bypass discussed later — an out-of-band credential, an ungoverned egress, a raw-socket code-execution plane — is therefore not a refutation of the architecture but a named case the deployment must foreclose by extending interposition to cover it, or disclose as a residual gap. The remaining undecidable case is the code-execution plane: where an actor may introduce arbitrary executable capability, the plane can decide the capability question (may this actor run code under this delegation — a decidable yes/no) but cannot decide the behaviour of the code it admits. That behaviour is contained downstream by the runtime boundary and counted as residual risk measured by the weakest ungoverned plane, not governed by the evaluator.

The Confused Deputy Problem

The confused deputy problem describes a situation in which a program misuses its authority on behalf of another entity. The term was introduced by Hardy (1988) to describe a class of security failures that arise when software components possess authority that they do not carefully distinguish from the authority of their callers.

A classic example illustrates the issue. Consider a compiler program that can write to system billing files. The compiler has the necessary permissions because it must update billing records whenever users submit compilation jobs. A user invokes the compiler and passes a file path argument. If the compiler naively writes to the supplied path without verifying its legitimacy, the user can trick the compiler into writing to a sensitive system file. The compiler has not been malicious, but it has acted as a deputy performing work on behalf of another party. Because the compiler used its own authority rather than the authority of the caller, it became confused.

This problem reveals a deeper structural issue. In traditional security architectures, programs operate with ambient authority — permissions that exist implicitly in the environment rather than being explicitly tied to specific operations. When software executes under ambient authority, it becomes difficult to determine whether an action is truly authorised by the party requesting it or merely enabled by the privileges of the software component executing it.

The confused deputy problem therefore exposes a structural weakness in systems where authority is implicit rather than explicitly delegated. Systems that rely on identity and permission lists often fail to capture the true flow of authority through a program’s execution path. This weakness, first identified in the 1980s, becomes critically dangerous when the deputies themselves are autonomous. In traditional systems, the deputy was deterministic software executing a fixed code path. In autonomous systems, the deputy generates novel actions through probabilistic reasoning — creating confused-deputy failures that no code review could have anticipated.

Capability-Based Security

Capability-based security emerged as a response to these weaknesses. Researchers such as Dennis and Van Horn (1966), along with later contributors including Miller (2006) and Hardy (1988), developed architectures in which authority was represented explicitly through capabilities. A capability is essentially a token that simultaneously identifies an object and grants permission to use it. Possession of the capability is sufficient to exercise the associated authority.

In capability-based systems, authority is not inferred from identity. Instead, it is carried explicitly in the form of capabilities passed between components. A process cannot access an object unless it holds the capability required to do so. This design eliminates ambient authority and ensures that programs only act with the permissions they have been explicitly granted.

Capability systems possess several important properties. They naturally enforce the principle of least privilege (Saltzer & Schroeder, 1975), because programs only receive the capabilities they require. They also significantly reduce the risk of confused deputy failures by eliminating ambient authority, ensuring that programs act only with explicitly granted permissions. Most importantly, capability systems allow developers to reason locally about authority. By examining the capabilities held by a component, it is possible to determine exactly what actions it can perform.

For these reasons, capability-based security was widely regarded as technically superior to traditional access control models. Several experimental operating systems adopted capability architectures, demonstrating strong security guarantees and elegant design principles. The seL4 microkernel (Klein et al., 2009) later demonstrated that capability-based designs could be formally verified — proving that the implementation correctly enforces its security policy.

Yet despite their advantages, capability systems did not become the dominant organising model for mainstream enterprise infrastructure. The reasons for that failure are instructive, because any architecture that governs autonomous action must overcome the same obstacles.

Why Capability Systems Were Marginalised

The marginalisation of capability systems was not caused by theoretical flaws. Instead, it resulted from practical challenges that became increasingly difficult to manage as computing systems grew more complex and distributed.

The most significant challenge was revocation. Once a capability is granted, it may be copied and passed through multiple layers of a system. Revoking that authority requires tracking every instance of the capability wherever it may have propagated. In large systems with complex interactions, this becomes extremely difficult.

Another challenge arose from the rise of distributed computing. Capability systems work best when the entire system is designed around capability semantics. However, modern software environments involve multiple processes, machines, services, and organisations. Passing capabilities safely across these boundaries introduces additional complexity and coordination requirements.

At the same time, enterprise computing environments increasingly favoured identity-based governance models. Access control lists, role-based access control, and identity management systems aligned well with organisational structures and compliance frameworks. These systems allowed administrators to manage permissions through centralised identity records, even though they lacked some of the security advantages of capability-based designs.

As a result, the industry standardised on identity-centric models such as ACLs and RBAC. Capability systems remained active in research, language design, microkernels, and specialised security architectures, but were marginalised from mainstream enterprise infrastructure.

The consequences of that decision now confront us.

The Consequences for Modern Systems

The decision to favour identity-based access control introduced a subtle but important limitation. Access control systems answer the question of who may access a resource. They do not answer the question of whether a specific action should occur at a particular moment.

This is the distinction between permission and authority, and it is precise enough to state as two decidable predicates over a canonical action $a$ (the canonical action is defined formally in The Emerging Governance Architecture below). $\mathrm{Capable}(a)$ holds when the action is technically reachable — the actor possesses some path, credential, or tool by which the operation could occur. $\mathrm{Authorised}(a)$ holds iff $G(a, D, P) = \mathrm{ALLOW}$: the action is authorised under the currently-distributed policy version $P$, under a delegation chain $D$ that is unexpired, unrevoked, and in-scope at the evaluation instant, with every temporal and contextual precondition satisfied. The “should” of authority is therefore a decidable predicate over resolved facts — not a normative or ethical judgement, and not a property of the actor’s intent. The governing property of the architecture is that execution requires both: $\mathrm{Capable}(a) \wedge \neg\,\mathrm{Authorised}(a) \Rightarrow \mathrm{DENY}$. The can/should gap is exactly the gap between static identity-permission membership and freshness-checked, delegation-bounded, time-indexed authorisation; execution governance closes it by making the second predicate, not the first, the gate on consequence.

In many traditional applications, this distinction was manageable. Software components behaved deterministically, and human users initiated most actions. But as systems became more automated and interconnected, authority began to propagate through chains of services, scripts, and workflows. The effective authority of the system became difficult to predict.

Autonomous systems amplify this problem dramatically. Modern agents interact with tools, retrieve information, modify state, and coordinate with other agents. Each of these interactions introduces new paths through which authority can flow. The resulting authority graphs are dynamic, compositional, and frequently unintended — properties that identity-based access control was never designed to govern.

This is not simply a policy failure. It is a structural property of how authority flows through systems composed of autonomous actors. The historical response to this kind of structural problem — from confused deputies to capability systems to distributed control planes — offers both a diagnosis and a direction.

Why Existing Infrastructure Governance Fails

A distributed systems engineer encountering these governance challenges may reasonably ask: why can’t existing infrastructure solve this? Modern infrastructure already includes policy enforcement at multiple layers, and each of these mechanisms solves real problems within its own domain. However, none of them addresses the specific problem of execution governance for autonomous systems.

Service meshes govern transport. A service mesh can enforce mutual TLS, rate limiting, and routing policies between services — and does so effectively. But it operates at the network layer: it can determine whether service A is permitted to call service B, not whether the action that service A is performing on behalf of an autonomous agent should occur. Transport policy cannot evaluate intent.

Policy-as-code engines such as OPA and Cedar evaluate attributes against declarative rules. They answer questions like “does this principal have permission to access this resource?” and can do so with considerable sophistication. A policy engine is a decision component — and a valuable one. However, a decision component is not a governance architecture. Execution governance requires an architecture around the decision: canonicalisation of the proposed action, validation of delegation chains, resolution of temporal authority, deterministic evaluation, and production of tamper-evident evidence. Policy engines do not by themselves establish this architecture.

Role-based access control answers the question of who may access a resource. It does not answer the question of whether this action, now, by this delegate, under these constraints, should be permitted. RBAC maps identities to static permission sets. It cannot express time-bounded delegation, scope narrowing across delegation chains, or the requirement that every decision produce verifiable evidence.

Guardrails — input and output classifiers embedded in the execution path of AI systems — are probabilistic filters. They estimate whether a prompt or response falls within acceptable bounds. But probabilistic classification is not governance, and the two occupy different planes. A guardrail cannot produce a deterministic, reproducible decision. It cannot generate a tamper-evident record that a specific action was evaluated against a specific policy at a specific time. And because guardrails are embedded within the execution path rather than separated from it, they do not constitute an independent governance plane.

The relationship is one of division of labour, not redundancy. Guardrails are advisory, in-path, and legitimately probabilistic content estimators; the governance gate is the deterministic authority over commit. Crucially, the gate does not adjudicate payload semantics. It cannot decide whether an email body is an exfiltration attempt encoded in prose, whether retrieved text carries a prompt injection, or whether a field contains personal data — none of these reduce to the facts (actor, intent, target, delegation, policy) over which the gate is deterministic. Content-level threats therefore remain a guardrail and upstream concern. The gate’s distinct contribution is narrower and more robust: even a successful injection cannot widen authority. A poisoned proposal that exceeds the presented delegation is denied on exactly the same basis as a buggy or malicious one. The two mechanisms are complementary — guardrails reduce the rate of harmful proposals; the gate bounds the consequence of any proposal that gets through to whatever the delegation authorises.

Each of these mechanisms solves a legitimate problem: transport security, attribute-based access, identity management, content safety. The issue is not that they are useless but that they operate at the wrong boundary. None of them produce tamper-evident evidence that a governance decision occurred. A service mesh logs traffic. A policy engine returns allow or deny. A guardrail filters content. But none of them generate a cryptographically chained record linking a proposed action, the policy under which it was evaluated, the delegation context, and the resulting decision — a record that can be independently verified and replayed.

Execution governance for autonomous systems requires all of these properties simultaneously: evaluation of intent, not just transport; dynamic delegation and temporal constraints, not just static attributes; deterministic decisions, not probabilistic classification; and tamper-evident evidence for every decision.

This is a distinct architectural layer, not an extension of existing infrastructure. It is not merely a policy decision point attached to agent tooling; it is the execution-governance control plane that canonicalises action, validates delegation, resolves current authority, and emits replayable evidence before consequence is admitted.

Authority Propagation

Capability researchers recognised that authority propagates along reference paths. If one component holds a capability to another object, and that object holds a capability to a third resource, the first component can potentially reach that resource through the chain of references.

The effective authority of a system therefore depends not only on explicit permissions but also on the topology of relationships between components. This phenomenon was anticipated in early protection models. Lampson’s (1974) protection-graph framework showed that authority emerges from the structure of relationships between subjects and objects, and that as systems grow more complex, unintended authority paths arise from the composition of otherwise legitimate relationships. In complex systems, the total authority available to a component may exceed the authority originally granted to it. This emergent authority arises from the structure of the system itself. In autonomous multi-agent systems, these authority paths are no longer static — they are created dynamically through shared context, tool outputs, event triggers, and runtime composition.

Autonomous systems create particularly rich authority graphs. Agents communicate with each other, invoke tools, read and write shared memory, and respond to events generated by other agents. These interactions create dynamic networks through which authority can propagate in ways that no single permission grant intended.

A concrete example illustrates the operational danger. Consider two agents operating within the same orchestration framework. The first agent holds a database credential scoped to customer records. The second agent has access to an external email API. Individually, each agent’s authority is well-bounded — one can read data but not transmit it externally, the other can send messages but has no access to sensitive data. But if both agents share a workspace — a common pattern in multi-agent architectures — the first agent can retrieve customer records and write them to the shared context. The second agent can then read that context and transmit the data externally. No single delegation authorised this exfiltration path. It emerged from the topology of relationships between agents, tools, and shared state. The authority graph contained a path that no individual permission grant intended to create.

This is not a hypothetical concern. Multi-agent systems routinely share context through message queues, shared memory, tool outputs, and orchestration state. Each shared surface creates potential authority paths. Traditional access control sees two agents with appropriately scoped permissions. An authority-propagation analysis sees an unintended channel from database to external network. The shared workspace is also precisely the injection surface: it is where a poisoned tool output or a colluding agent plants the instruction the next agent acts on.

It is essential to be exact about what per-action governance does and does not catch here, because the honest answer is the point. Evaluating each action independently at the execution boundary does not, on its own, prevent this exfiltration. Each individual step — the first agent’s read, its write to shared context, the second agent’s read, the second agent’s send — is independently within scope and independently authorised. Per-action evaluation is by construction memoryless across actions, while the harm is intrinsically multi-action: it lives in the composition, in a path through the authority graph that no single delegation created and that the per-action evaluator never computes (authority-graph reachability is a global analysis, not a local one). A paper that claimed the base architecture defeated this example would be overclaiming.

What would catch it is a stronger, but still deterministic, evaluation input: attested provenance. If the canonical action carries the provenance (a taint label) of the data it transmits, and the policy governing the second agent’s send accounts transitively for the scope of that data, then the send is denied — not because the evaluator remembers the earlier read, but because the resolved context presented for the send carries the fact that the payload originated in customer records. This preserves the purity of $G$ (the decision remains a function of currently-resolved facts, not of evaluation history) while making the emergent path visible to a single evaluation. The two preconditions this depends on — provenance that survives the write to shared context (it must not be stripped on write), and a policy that reasons over it — are exactly what governed composition requires, and exactly where this paper’s base architecture stops. The mechanism is specified by the Constitution’s Clause 11 and discussed under Limitations below; the residual frontier — a prohibited outcome deliberately split into $N$ individually in-scope actions across $N$ correctly-narrowing agents — is a named open problem, not a solved one.

Understanding and constraining this propagation is the problem execution governance is built to confront. The base architecture supplies the necessary substrate — per-hop authority traceability and monotonic narrowing, defined below — and the provenance-carrying canonical action is what extends it to the composed path; the cross-trust-root case remains open.

The Distributed Systems Parallel

A remarkably similar problem emerged in distributed systems engineering. As computing infrastructure scaled to thousands of services and machines, engineers discovered that it was no longer feasible to rely on individual components to enforce policies correctly. Systems became too complex, failures too frequent, and interactions too dynamic for local governance to maintain global invariants.

The solution was the introduction of a control plane.

Distributed systems architecture began to distinguish between the control plane and the data plane. The data plane performs operational work — processing requests, forwarding packets, or executing tasks. The control plane determines how the system should behave by distributing policies, scheduling workloads, and coordinating state.

This separation proved essential for managing large-scale systems. Components in the data plane could remain simple and focused on execution, while the control plane maintained global consistency and governance. The insight was architectural: governance at scale requires a structurally independent layer, not better-behaved components.

Examples of this architecture appear throughout modern infrastructure. In networking, routing protocols form the control plane while packet forwarding constitutes the data plane. In container orchestration systems such as Kubernetes, schedulers and controllers define desired system state, while container runtimes execute workloads. Service meshes introduce policy and routing control planes that govern communication between services.

The key insight behind these architectures is that governance must be separated from execution. When the number of components, the complexity of their interactions, and the consequences of their actions exceed what local enforcement can manage, a structurally independent governance layer becomes necessary — not as an optimisation, but as an architectural requirement.

Autonomous systems have now reached this threshold. The solution follows the same pattern: treat every autonomous action the way distributed systems treat infrastructure changes — through a control plane that evaluates each action before it executes. The architecture is easiest to understand as a control loop: canonical action enters the governance plane at the execution boundary; the governance plane renders ALLOW, DENY, or ESCALATE; and every outcome produces evidence.

Autonomous Systems Require a Control Plane

Autonomous systems are beginning to exhibit the same structural challenges that distributed systems faced a generation earlier. Agents perform actions across multiple domains: they call APIs, access data stores, trigger workflows, and interact with external environments. In production deployments, thousands of agents may execute millions of actions per day across shared infrastructure, often under heterogeneous policies, credentials, and delegation contexts. Each of these actions carries potential consequences that extend beyond the agent’s local context.

If governance mechanisms remain embedded within individual components, the system cannot reliably enforce global constraints. Agents may act based on incomplete context, inconsistent policies, or outdated delegation state. Authority may propagate through paths that no single component can observe.

The architecture required to address this problem mirrors the control-plane separation found in distributed systems. Instead of allowing agents to execute actions directly, systems introduce a governance layer that evaluates proposed actions before execution occurs.

In this model, agents generate intentions or proposed actions. These proposals are passed to a governance mechanism that determines whether the action is authorised under current policies, delegations, and constraints. Only actions that pass this evaluation are permitted to execute. Actions that fail are denied, and the denial itself becomes part of the evidence record.

The governance layer thus functions as an execution-governance control plane — structurally independent from the systems it governs, evaluating every action at the execution boundary where intention becomes consequence.

From Capabilities to Execution Governance

Capability-based security introduced the idea that authority should be carried explicitly rather than inferred from identity. This was the right insight, and it remains foundational. However, capability systems primarily focused on making authority portable: a capability token could be passed between components, and possession was sufficient to act.

Autonomous systems require an additional architectural step. It is not enough to know who holds authority; the system must determine whether a specific action is authorised at the moment it would produce consequences. This is the deepest shift from capabilities to execution governance: capability systems made authority portable, while execution governance makes authority re-validated at the moment consequence would occur.

Instead of granting persistent permissions that remain valid until revoked, the system evaluates authority dynamically at the boundary where actions occur. Each proposed action is examined against current policies, current delegation state, and current constraints — not the state that existed when authority was originally granted, but the state that exists now, at the moment of execution.

This evaluation produces both a decision and verifiable evidence that the decision occurred. Authority is not simply granted once and trusted indefinitely. It is verified every time it is exercised. This shifts revocation from token invalidation to fresh boundary evaluation: updated policies and revoked delegations affect future decisions without requiring the system to trace and retract every propagated token.

The resulting architecture is designed to satisfy the three properties of a reference monitor (Anderson, 1972), each conditioned on the trusted computing base stated earlier: complete mediation — every consequential action passes through the governance layer, given enforced interposition; tamper resistance — the plane is structurally independent and its evidence cryptographically bound, given a defended plane TCB (code, keys, clock) and an externally-witnessed chain (structural independence is necessary, not sufficient, for this property); and verifiability — the evaluation is a deterministic, replayable pure function, given the canonicalisation soundness requirement. Classical reference monitors mediate access to resources. Execution governance extends this model to action commitment: mediating not whether a subject may reach an object, but whether a proposed action may produce consequences, under what delegation, at what moment. It further strengthens the model by requiring that every mediation produce cryptographic evidence — a property classical reference monitors did not demand.

The Emerging Governance Architecture

Combining these ideas produces a coherent architecture for governing autonomous systems. The architecture is precise and its control loop is explicit.

An autonomous system proposes an action. The action is canonicalised into a standard representation — actor, intent, target, and parameters — to which the resolution phase adds the delegation context, the policy identity, and a trusted evaluation timestamp before evaluation begins.

Canonical action. The canonical action is the output of a deterministic, model-external canonicalisation: a fixed transformation that takes a runtime action and produces a stable, serialisable representation without an LLM anywhere in the loop. Canonicalisation is defined per tool contract — each integrated tool or MCP server ships a declared, content-hashed schema, so the system never attempts open-domain natural-language-to-canonical mapping. The transformation has three load-bearing properties, and they are soundness prerequisites, not engineering niceties — determinism of $G$, replayability, and the hash chain’s tamper-evidence all rest on them:

• Injectivity over semantically-relevant fields. Two different actions must never collapse to the same canonical form. A canonicalisation that lets a benign and a harmful action share one representation lets the policy authorise the wrong one.
• Parser-equivalence (no semantic gap). The canonical form the policy evaluates must be the operation the target executes — the target must execute only the canonical form, never a re-parse of the raw payload. This closes the SQL-/HTTP-smuggling class, where the evaluator and the target disagree about what an ambiguous string means.
• Determinism, totality, and byte-exact serialisation. Over admissible inputs the transformation is total and deterministic, with a fixed key order, normalised number and Unicode forms, and no insignificant whitespace, so canonical_json is bit-identical across independent implementations. The canonicalisation rules and serialisation format are themselves versioned and identified by an immutable spec identifier carried in every receipt.

Any payload whose shape is unrecognised or ambiguous under the relevant tool contract resolves to ESCALATE or DENY — the system never best-effort canonicalises an input it cannot represent soundly. Because canonicalisation is model-external and per-contract, the governance plane is defined by policy and delegation semantics rather than by any specific model, framework, or runtime, and that neutrality holds only within a fixed canonical-schema identity — the content hash of the schema under which the action was projected, recorded in every receipt and every compiled policy.

The execution-governance control plane evaluates this canonical action against current policies and validated delegation state using deterministic logic. The evaluation produces exactly one of three outcomes: ALLOW, DENY, or ESCALATE. If allowed, the action executes against the target system. If denied, the action is blocked. If escalated, the action is suspended and does not cross the commit boundary (the ESCALATE contract is stated below). Whatever the outcome, the evaluation produces a tamper-evident governance receipt.

Every receipt binds together the proposed action in canonical form; the policy identity and version under which the action was evaluated; the canonicalisation spec identifier and canonical-schema identity used to produce the canonical action; the delegation context, including scope, temporal bounds, and revocation status; and the resulting decision together with the reasons that determined it. This binding is cryptographic — altering any component invalidates the receipt. Each receipt is hash-chained to its predecessor (Schneier & Kelsey, 1999), creating an append-only evidence stream. Concretely: a genesis hash $h_0$ anchors the chain, defined as the 64-character hexadecimal string of zeros (the null SHA-256 digest representing “no prior 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. Each subsequent receipt produces:

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

The chain begins at a fixed genesis value and each subsequent receipt commits to its predecessor.

What the chain guarantees, precisely. It is necessary to separate three properties that are easily conflated, because the chain delivers them to different degrees:

• Tamper-evidence. Modification of a recorded receipt breaks the linkage and is detected — but only by a verifier who holds an independently-held commitment to a chain head. An adversary with write access to the store and the receipt-signing key can recompute an entire consistent suffix; against such an adversary the bare chain alone proves nothing. Detection therefore assumes the verifier compares against an external anchor the adversary does not control.
• Completeness. A receipt existing for every consequential action is not a property of chaining; it requires that an action cannot commit unless its receipt is committed. The architecture supplies this through interposition and an immutable consequence marker emitted by the enforcement boundary and cryptographically linked to its evidence record, enabling independent completeness verification — not through the hash chain.
• Non-equivocation and anti-truncation. That there is exactly one chain, and that its tail has not been silently dropped or forked, requires external witnessing: periodic publication of chain heads to an independent anchor, per-record signatures, or a witnessed monotonic counter. Hash-chaining alone does not detect a dropped suffix or a parallel fork.

The trust root anchoring the chain must therefore be explicitly defined, independently inspectable, and independent of the governance system under verification; a self-attested chain head does not satisfy independent verifiability. Third-party non-repudiation, where any holder of the corresponding public key can verify authorship, requires asymmetric signatures over the record hash, not the hash chain itself. With these conditions met, the stream can be independently verified and replayed without access to the originating system; without them, “independently verifiable” is an overclaim.

Serialisation and the global-order bottleneck. A single global chain with a monotonic $\text{seq}$ is a single-writer total-order structure: every receipt depends on $h_{n-1}$, so all writers serialise through one append point. That cannot sustain the scale this paper itself posits (thousands of agents, millions of actions per day). The architecture therefore uses per-actor or per-tenant sub-chains — each with its own genesis $h_0$ and its own $\text{seq} = n$ — interleaved freely, and cross-anchored periodically into a Merkle checkpoint (or inter-chain hash) published to the external trust root. This preserves tamper-evidence and non-equivocation across the whole fleet while replacing the global serialisation point with parallel appends and $O(\log n)$ inclusion proofs against each checkpoint.

This architecture resolves several problems that plagued earlier approaches. Because authority is evaluated at execution time, the revocation problem that plagued capability systems dissolves — stale or revoked delegations are caught at the next evaluation, without requiring the system to trace every propagated token. Because governance occurs at the execution boundary, authority propagation across complex agent networks can be examined and constrained. Because decisions produce verifiable evidence, organisations can audit and replay governance decisions independently.

The architecture is also designed to fail closed, and the rule is universal rather than a list of cases. ALLOW requires that every authorising precondition — the current policy version, an unexpired, unrevoked, in-scope delegation, and every temporal and contextual constraint — be positively verified as current at evaluation time. If any precondition cannot be so verified, for any reason whatsoever, $G$ yields DENY or ESCALATE and never ALLOW. The familiar cases are instances of this closure, not its definition: stale, unverifiable revocation state denies; a node that cannot confirm it holds the current policy version denies until currency is established; disagreeing time sources that leave a delegation’s temporal validity unverifiable deny. There is no fourth degraded mode to enumerate, because the rule quantifies over the entire unverifiable space.

This is a deliberate inversion of the availability-first defaults that characterise most distributed systems. In execution governance, integrity takes precedence over availability. A system that continues to execute under degraded governance conditions is not governed at all.

The cost is real and must be stated, not waved away. The mandatory in-path authoriser is itself a new single point of failure: a high-value forge-everything target and a denial-of-service lever, since an adversary who disrupts the revocation, policy, or time dependencies converts fail-closed into a fleet-wide halt of privileged action. “Governance-plane redundancy” does not dissolve this for free — replicating a currency-verifying, fail-closed component re-imports a coordination cost (which replica holds current policy; what happens when replicas disagree on revocation state; coordination delay converting directly into denials). The architecture resolves the residual tension by separation in condition: a declared, bounded freshness window is the explicit integrity-versus-availability tuning knob. Within the window, the plane serves revocation and policy state from a recently-synced replica as a local cached read rather than a synchronous quorum on every action; only a genuine outage that outlasts the window halts privileged action. The window length is therefore a deliberately set parameter, bound into the policy identity so that two evaluators agree on the staleness tolerance they apply. Two countervailing facts keep the trade positive: concentrating mediation into one small, formally-analysable plane is more hardenable than diffuse embedded controls — the smaller-is-harder argument the seL4 result already demonstrates for capability kernels — and because the plane’s evidence is tamper-evident, compromise of the authoriser is itself detectable and replayable rather than silent. An integrity-critical denial (a correct refusal under uncertainty) and an availability-of-governance failure (the plane being unable to decide at all) are distinct failure modes and must be operated as such.

Most importantly, this architecture separates reasoning from authority. Autonomous systems can generate plans and suggestions, but the governance layer retains final control over what actions are permitted.

This architecture can be stated as a single invariant. The invariant holds relative to the threat model and trusted computing base stated earlier — most centrally, it presupposes interposition, that consequential actions have no route to a target except through the plane.

Execution Governance Invariant. No action that produces external consequences may execute unless it has been evaluated at the execution boundary against current policy and validated delegation state, and that evaluation has produced tamper-evident evidence. ESCALATE is counted as non-execution: an escalated action has not crossed the boundary.

The evaluation itself is a pure function. Let $I$ denote the canonical action input, $D$ the validated delegation state, and $P$ the policy identity:

$$d = G(I, D, P)$$

where $d \in \{\mathrm{ALLOW}, \mathrm{DENY}, \mathrm{ESCALATE}\}$.

The frozen input tuple, and the scope of determinism. $D$ and $P$ are not free variables resolved at wall-clock convenience; they are snapshotted at the boundary. $D$ is the validated delegation state together with its revocation epoch and the trusted evaluation timestamp; $P$ is an immutable policy identity (a content hash, never “latest”) that also pins the canonicalisation spec, the canonical-schema identity, the outcome-precedence order, and the freshness-window length. For fixed inputs $(I, D, P)$, $G$ is deterministic and replayable — anywhere, at any time, by any conformant evaluator. Determinism is over the inputs, not over wall-clock: because $D$ and $P$ are evaluated against current state, two evaluations of the same proposed action at different times may legitimately differ (a delegation revoked between them flips ALLOW to DENY), and this is not a contradiction with purity but its direct consequence — the freshness and revocation epoch are members of the tuple. The evidence record binds that exact tuple, so replay re-derives both the output and its input provenance. (The byte-identical guarantee is over the deterministic receipt core; a full emitted receipt envelope may additionally depend on explicit ledger state and emission metadata, and replays identically only when those are also fixed.)

Delegation validity and monotonic narrowing. $D$ is valid only if it passes a decidable predicate. A single delegation is valid at time $t$ iff it is unexpired, unrevoked, and the action falls within its granted scope. A chain $c_0 \to c_1 \to \dots \to c_k$ is valid iff, for every hop, $\mathrm{scope}(c_{i+1}) \subseteq \mathrm{scope}(c_i)$ and the validity window $[\,t^{\text{from}}_{i+1}, t^{\text{to}}_{i+1}]$ is contained in its parent’s. Monotonic narrowing is exactly this per-hop subset condition: sub-delegation may preserve or narrow a delegator’s authority and must never widen it, evaluated over a single derived permission set with path-prefix and normalisation edge cases resolved by the canonicalisation spec. Each hop is a constant-time containment check, so validating a chain of depth $k$ is $O(k)$. Chain depth must be bounded; an unbounded chain makes per-action validation cost unbounded and is itself a denial-of-service surface, so the bound is a policy parameter.

Cost model. A single evaluation is $O(d + r + c)$ — linear in delegation-chain depth $d$, the number of applicable compiled rules $r$, and the number of constraints $c$ — with no unbounded search or fixpoint iteration. The policy is a compiled bundle: compilation is an offline step whose output is content-hashed into $P$, satisfies the correctness property that the compiled form decides every canonical action identically to its source policy, and indexes rules so evaluation touches only the applicable ones rather than scanning the whole policy.

Total outcome precedence. For “identical inputs produce identical decisions” to hold across independent implementations, the three-way outcome must be resolved by a total order, not left to evaluation order. Rules combine under deny-overrides — $\mathrm{DENY} > \mathrm{ESCALATE} > \mathrm{ALLOW}$ — with a deterministic tie-break (lowest rule identifier) so that no two contributing rules can leave the result ambiguous. This precedence is fixed as part of policy identity $P$; without it, two faithful evaluators could diverge while each being internally deterministic, silently breaking cross-implementation replay.

The ESCALATE contract. ESCALATE is a first-class outcome with fully defined semantics, not an undefined third state. (1) It suspends the action fail-closed: the action does not cross the commit boundary while escalated, and the invariant counts it as non-execution. (2) Its resolution is itself a fresh canonical action re-entering the boundary as a new governed input $(I', D', P')$ with its own receipt cryptographically linked to the escalation record; the out-of-band human decision is captured as an explicit authority artefact, so $G$ remains a deterministic classifier and replay reproduces the presence and contents of that artefact, never the human judgement itself. (3) A declared timeout bounds the wait; on expiry the action resolves to DENY, preserving fail-closed and foreclosing a timeout-to-ALLOW bypass. (4) Escalation requests are rate-limited, so an adversary cannot weaponise ESCALATE into a flooding denial-of-service. (5) In unattended or asynchronous agent loops with no human present, the default is therefore explicit: block, then DENY on timeout.

Anti-replay and the check-to-commit window. Replayability for audit (identical inputs reproduce the identical decision) is a virtue; replay resistance of execution is a separate property the pure function does not provide and must be added. Because $G$ is stateless over $(I, D, P)$, a captured ALLOW or a re-injected identical action would re-authorise and re-execute a consequential operation — a second payment, a second send. The canonical action therefore binds a nonce or monotonic action-id into $I$ and into the receipt’s $\text{seq}$, and the plane (or target) rejects a previously-committed action-id, making each authorisation single-use. Distinct from replay is the time-of-check/time-of-use window between ALLOW on snapshot $(I, D, P)$ and the action committing: purity guarantees the decision is reproducible, not that it is still valid at commit. The architecture closes this by binding, not by hoping determinism removes it — the authorised artefact is content-addressed and presented atomically at commit, the target executing only the exact artefact whose hash matches the immediately preceding receipt and refusing any payload that differs. Binding is symmetric — it covers the target as well as the action — so a symlink, DNS-rebind, or mutable-row swap that re-points the target after ALLOW fails the check rather than silently redirecting the authorised operation. The authorise-to-execute step is treated as a critical section atomic with respect to policy and delegation changes; the residual TOCTOU exposure — a delegation revoked in the microseconds after ALLOW for an already in-flight action — is stated honestly as a bounded window, not dissolved by appeal to “the next evaluation”, because there is no next evaluation for an action already in flight.

The architecture addresses five classes of governance failure: reasoning error, in which an autonomous system proposes an unsafe action; capability escalation, in which delegated authority is widened, stale, or unverifiable; policy drift, in which governance rules change without replayable traceability; execution ambiguity, in which no pre-execution record establishes the authority that enabled an action; and evidence tampering or gaps, in which governance records are absent, incomplete, or altered after the fact.

The Commit Boundary

The execution boundary described above corresponds to what distributed systems engineers recognise as a commit boundary — the point where a proposed state change becomes durable and visible to other systems. Before commit, an operation is provisional and reversible. After commit, it is part of the system’s authoritative history. In autonomous systems, every consequential action crosses such a boundary: a database transaction commits, an API request is accepted, a message is transmitted, a workflow is triggered. The execution-governance control plane sits precisely before that moment.

The mediated set warrants one clarification, because complete mediation is only meaningful relative to a precisely-bounded set of events. The Introduction characterises the boundary modally — an operation capable of producing external consequences — while the commit-boundary framing characterises it actually — a change that becomes durable and visible. These are reconciled by taking the modal set as primary: the mediated set is every operation capable of external consequence, of which the committing actions are the principal case. The remaining members are externally-observable-but-non-committing actions — a metered or non-idempotent read, for instance — which are mediated on the same basis because they too produce a consequence beyond the actor’s boundary. Not every agent action presents a clean atomic commit point — streaming responses, paginated or long-running calls, file and stdio transports, and tools that fan out to further side effects all blur it — and the design stance for these is explicit: the gate governs the request to perform the action (the call the agent can be prevented from issuing), not the internal runtime behaviour of the downstream tool. A tool that produces unbounded or unobservable downstream side effects must itself be modelled as a governed target; otherwise its fan-out is residual risk, not mediated consequence. This keeps the reference-monitor claim honest about exactly what is and is not interposed.

This correspondence clarifies why deterministic evaluation is not merely desirable but necessary. In transactional systems, the commit decision is deterministic — a database’s constraint checker does not probabilistically decide whether to accept a transaction. The same requirement applies to governance of autonomous action: the reasoning that proposes an action may be probabilistic, but the commit decision must be deterministic. A system that probabilistically decides whether to commit an action cannot prove that the action was authorised. This is why a probabilistic classifier cannot be the commit gate — not that classifiers are useless, but that the authority over commit must be deterministic. Guardrails retain their proper role one plane upstream, estimating the content of proposals; what they cannot do is render the authoritative, reproducible commit decision the boundary requires.

The governance receipt chain is structurally equivalent to a write-ahead log. In transactional systems, the write-ahead log records the decision to commit before the state change takes effect, ensuring that the decision is durable even if the system fails during execution. The governance receipt serves the same function: it records the authorisation decision before the action executes, ensuring that evidence exists independently of whether execution succeeds. Both structures are append-only, ordered, and sufficient to reconstruct the decision history from the log alone. The governance chain extends this with cryptographic binding and hash-chaining — properties drawn from secure audit logs (Schneier & Kelsey, 1999) that make the log tamper-evident rather than merely durable.

In transactional systems, the commit validator is never embedded in the application logic that proposes the state change. The database’s constraint checker is independent of the application. The payment network’s authorisation system is independent of the merchant. The same structural requirement applies: the commit gate for autonomous action must be independent of the reasoning system that proposes the action. This independence is not a security preference — it is a structural requirement of any commit boundary. A system that validates its own commits is a system without external accountability.

A Structural Analogy: Event Streams

The execution governance architecture aligns with event sourcing — a pattern in which system state is represented not as a snapshot but as a sequence of events, each recording a change. Every governance decision becomes an event in a controlled stream, recording not only what action was taken but the decision that authorised it. The governance layer functions as a gatekeeper: only actions that pass evaluation are admitted into the system’s event history. Governance receipts do not replace domain events; they accompany them by recording the authorisation decisions that admitted each consequential action into execution.

This structure satisfies a critical requirement: independent verification. Because the governance logic is deterministic and the evaluation inputs are preserved, an auditor holding the externally-anchored chain head can replay the decision stream and verify that every recorded consequential action was properly authorised. The system does not merely assert that governance occurred; it produces a historical record an independent party can re-derive and check.

Limitations and Open Questions

This paper describes the architecture’s structure and invariants. Several important questions remain open:

1. Governance plane security (the trusted computing base). Structural independence is necessary but not sufficient for tamper resistance: the plane’s own code, signing keys, and clock are inside the adversary’s scope, and subverting the evaluation layer voids the invariant. Two obligations follow that the architecture states rather than waves away. First, key custody: the receipt- and policy-signing keys must have a declared custody and compromise model, because a plane that compromises its own key can forge a chain that passes “independent” verification — which is exactly why third-party non-repudiation requires asymmetric signatures and the chain head must be externally anchored. Second, the net trade. Concentrating all mediation into one plane creates a new high-value attack surface, but the trade is positive on the ideality ledger precisely because that surface is small: a single, formally-analysable, tamper-evident plane is more hardenable — and, as the seL4 result shows for capability kernels, potentially formally verifiable — than diffuse controls embedded across every agent, and its own compromise is detectable and replayable rather than silent. The protection model is an open obligation; the smaller-is-harder argument is why it is a tractable one.

2. Cross-action composition. Per-action boundary evaluation is by construction memoryless across actions, so it does not on its own prevent harm that lives in a sequence — including the flagship two-agent exfiltration, whose every step is individually in scope. Two distinct gaps remain. The first is addressed in principle by carrying attested provenance on the canonical action (taint that survives the write to shared context) and a policy that reasons over it, evaluated as a deterministic function of resolved context; the Governance Constitution’s Clause 11 (Composition Closure) specifies the positive three-part criterion for governed composition — per-component Evidence Records at the action boundary, a delegation chain verifiable end-to-end that narrows monotonically, and a coordination artefact with a declared, content-hashed schema — which closes the within-trust-root case. The second is a genuine open frontier on two axes: cross-trust-root composition (linking Evidence Records produced by planes that depend on different time authorities, schema registries, or evidence anchors, which needs a trust-bridging artefact not yet doctrinally specified), and decomposition / collusion (a prohibited outcome deliberately split into $N$ individually in-scope actions across $N$ correctly-narrowing agents). A content hash binds the shape of a coordination artefact, not its truthfulness; a component can emit a schema-valid, correctly-narrowed artefact asserting false context, so the sufficiency claim holds only within a shared trust root, and across roots is necessary but not sufficient.

3. Fail-closed availability cost. Fail-closed is architecturally correct but imposes real cost, and the in-path authoriser is itself a new single point of failure and denial-of-service lever. The body states the resolution — a bounded, policy-pinned freshness window as the explicit integrity-versus-availability tuning knob, served from a recently-synced replica rather than a per-action quorum — and the residual obligation is empirical: governance-plane reliability must be engineered high enough, and the window set tightly enough, that integrity is preserved without sacrificing availability in practice.

4. Canonicalisation soundness. Canonicalisation is a load-bearing soundness prerequisite, not an engineering footnote: the determinism of $G$, replayability, and the chain’s tamper-evidence all rest on it. The body states the obligations — injectivity over semantically-relevant fields, parser-equivalence with the target, and total, byte-exact, deterministic serialisation, bounded by a per-tool-contract schema so the system never solves open-domain mapping. What remains open is coverage: every integrated tool must ship a sound, content-hashed contract, and ambiguous or unrecognised shapes must ESCALATE or DENY rather than be best-effort canonicalised. The specification effort scales with the integration surface; it is bounded per tool but not zero.

5. Policy correctness. Deterministic evaluation guarantees that every action is assessed consistently under the stated policy, but does not guarantee that the policy itself is correct. A deterministically evaluated bad policy produces reproducible but wrong decisions, faithfully recorded — the chain records a miscompiled or mis-specified policy as uselessly as a correct one. The architecture ensures governance is verifiable, not that it is wise.

6. Latency and throughput. The architecture is a synchronous, on-path gate evaluated before every consequential action, so its cost cannot be assumed away. The body separates the hot path (a local, pure $O(d + r + c)$ evaluation over cached, freshness-bounded resolved inputs, with the evaluator co-located as a sidecar so the in-path cost is a local call, not a network round trip, and decisions cached for identical $(I, D, P)$ tuples) from the slow path (I/O resolution of revocation, policy, and time, and durable receipt persistence, which appends after the decide and need not block commit), and replaces the global chain with cross-anchored per-actor sub-chains. The governing principle is that governance cost should scale with consequence — the irreversibility of the action — not with raw action volume. What remains open is empirical: realistic per-action latency budgets, tail behaviour under escalation and under freshness-window misses, and verification cost at scale (a year of millions-per-day is $10^8$–$10^9$ records; full sequential replay is $O(n)$ and an offline batch, which signed periodic checkpoints and Merkle inclusion proofs bound to the suffix or to $O(\log n)$ for single-receipt proofs).

These are engineering and specification challenges, not architectural flaws, but they must be addressed before the architecture can be considered complete.

Conclusion

The governance challenges of autonomous systems are not new. They are the convergence of longstanding ideas in security and systems design. The confused deputy problem revealed the dangers of ambient authority. Capability-based security made authority explicit and portable. Distributed systems engineering demonstrated that governance at scale requires structural separation from execution.

These ideas converge on a single architectural requirement: an execution-governance control plane that evaluates every proposed action at the execution boundary using deterministic logic, producing tamper-evident evidence for every decision. This architecture transforms governance from a collection of policies and monitoring tools into a structural property of the system itself.

Every previous generation of computing infrastructure encountered this inflection: the moment when the scale and autonomy of the system exceeded the capacity of embedded controls, and governance became an independent architectural layer. Identity infrastructure, network control planes, payment authorisation networks — each emerged when the cost of ungoverned action became structurally unacceptable. Autonomous systems have reached that threshold. The execution-governance control plane is the architectural response.

---

References

Anderson, J.P. (1972). Computer Security Technology Planning Study. Technical Report ESD-TR-73-51, Air Force Electronic Systems Division.

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.

Lampson, B.W. (1974). “Protection.” ACM SIGOPS Operating Systems Review, 8(1), 18–24.

Klein, G., Elphinstone, K., Heiser, G., Andronick, J., Cock, D., Derrin, P., Elkaduwe, D., Engelhardt, K., Kolanski, R., Norrish, M., Sewell, T., Tuch, H. & Winwood, S. (2009). “seL4: Formal Verification of an OS Kernel.” Proceedings of the 22nd ACM Symposium on Operating Systems Principles (SOSP ‘09), 207–220.

Miller, M.S. (2006). Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. PhD dissertation, Johns Hopkins University.

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

Schneier, B. & Kelsey, J. (1999). “Secure Audit Logs to Support Computer Forensics.” ACM Transactions on Information and System Security (TISSEC), 2(2), 159–176.