The thesis in one sentence

An agent action that cannot produce its proof packet at the moment of execution is an agent action that should not execute.

This is not a slogan. It is an enforcement boundary. Inside the MAIA substrate, every typed action passes through a proof gate before the runtime applies it: a typed declaration of the inputs read, the policy clauses consulted, the classification floor enforced, the reversibility guarantee given, and a signature linking the proof to the actor, the time, and the audit chain. No packet, no action.

The argument of this paper is that this is the only honest architecture for defence-grade autonomy. Every weaker model — "log it, then decide if it was OK" — pays the cost of remediation in the worst possible moment, after the action has already propagated into shared infrastructure.

The shape of a proof packet

A proof packet is a typed record produced atomically with the action proposal. It carries six things:

  1. Inputs. The entities, properties, and signals the agent read. References, not copies — the packet stays small, but every reference is content-addressed against the persisted ledger so the inputs can be reconstructed at any later time.
  2. Policy clauses. The named rules from the tenant's policy bundle that gated this action. Each clause is cited by stable identifier and version hash, so an inspector looking back can verify the exact policy that authorised the action and tell whether the policy has drifted since.
  3. Classification floor. The maximum classification of any input. The action inherits this floor by construction: its outputs cannot be down-classified without an explicit de-classification action that itself carries a proof packet. This is the only mechanically enforceable model that survives an inspector-general review.
  4. Severity. AUTO / REVIEW / CRITICAL, derived from the policy bundle. AUTO actions execute on the authorising agent's authority. REVIEW gates to an operator queue. CRITICAL gates to a second human-in-the-loop with a separation-of-duties check against the proposing agent.
  5. Reversibility guarantee. A typed declaration of how the action can be reversed: a named inverse action, the maximum time-to-roll-back, the maximum reachable blast radius after rollback. Actions without a reversibility guarantee are explicitly tagged as terminal and require CRITICAL severity.
  6. Signature. An HMAC-SHA256 (Phase 1) or Ed25519 (Phase 2) signature over the canonicalised packet, keyed to the agent identity, witnessed by the tenant runtime, optionally counter-signed by an RFC 3161 timestamp authority. The signature is what makes the proof packet a primary record for after-action review.

The packet is small — a few hundred bytes on average — and it is produced atomically with the proposal, not after. This is the load-bearing difference between Policy-by-Proof and log-then-audit.

Why log-then-audit is not enough

Most enterprise-AI platforms ship one of two patterns. Either the agent executes and an audit log records what happened, or the agent executes and the post-hoc compliance pipeline samples a fraction of actions for review.

Both fail in the regime that matters. In a defence operation, the cost of a bad action is not measured in dollars or in customer churn; it is measured in disclosure events, in inter-agency reputation, in inspector-general findings. By the time a sampled post-hoc review surfaces a violation, the information has propagated into coalition partner systems, into reporting cycles, into operational plans that have been executed in the field.

The remediation cost is asymmetric. A clean intercept at the proof gate costs the latency of a packet write. A failed post-hoc audit costs an investigation, a notification, often a human re-doing the work. The expected-value math is not close.

Defence-grade autonomy requires the gate to be in-band.

The classification inheritance rule

One particular guarantee deserves its own section because it is what makes the platform usable in a clearance-stratified environment.

The proof packet's classification floor is the maximum classification of any input that fed the action. The action's outputs — entities updated, signals emitted, evidence added to the ledger — inherit this floor. Downstream consumers of those outputs see them only at or above their own clearance.

This is not RBAC. RBAC is a permission to read; classification inheritance is an obligation to propagate. The two interlock: an agent at clearance level N can only read inputs ≤ N, and any outputs derived from a mixed-clearance read inherit the higher floor.

The mechanism is brittle enough that operators initially push back: legitimately useful queries fail because one input is over-classified relative to the answer the operator wanted. Our experience over twelve weeks of staged rollout is that this brittleness is the platform's most valuable property. Every push-back exposes a place where the operator's mental model of "what I should see" diverged from the policy as written. Resolving the divergence is exactly the work an inspector-general would have demanded six months later.

Severity and the operator queue

Three severity classes:

AUTO. Action class is approved for automation, classification floor is at or below the agent's authority, policy clauses are unambiguously satisfied. The runtime applies the action and the proof packet lands on the chain. No operator surface change.

REVIEW. Default for any new action class, any ambiguous policy match, any classification-tightening or classification-relaxing change. The proposal lands in the operator queue with its full packet. Operator approves or rejects with rationale; both decisions append to the chain.

CRITICAL. Required for terminal (non-reversible) actions, for cross-tenant disclosure events, for any action whose inverse exceeds an explicit time-to-rollback ceiling. CRITICAL requires both the operator approval and a second human-in-the-loop check from a role distinct from the proposing agent's authoriser, by separation-of-duties.

Severity is not declared in the action; it is derived from the policy bundle. An operator who wants to suppress REVIEW friction for an action class must propose a Living Ontology change to promote that class to AUTO — which, in turn, is a REVIEW proposal that lands in the same queue and produces its own proof packet.

The recursion is intentional. The platform's autonomy gate is itself subject to the same gate.

What this costs at operational tempo

The most common pushback is latency. Surely a proof gate slows the agent down? Surely defence operations cannot afford the extra milliseconds?

In practice the gate adds a few hundred microseconds at p50 and a few milliseconds at p99 in the local hot path. The durable mirror to a persisted store is async and never blocks the action; the FNV-1a chain is computed synchronously and fits in a single cache line; the signature can be deferred from emit time to export time without weakening the guarantee.

The real cost is not latency. It is design discipline. Every new action class must be modeled with explicit reversibility, explicit inputs, explicit policy clauses. There is no shortcut that gets to "ship it and we'll check later." Engineering teams used to operating in that shortcut find the discipline constraining at first. The teams we have onboarded report, consistently, that the constraint surfaces design problems earlier in the cycle than any code review would have caught them.

Why this is the second moat

The first moat — described in our companion paper The Living Ontology — is that the schema improves with usage. The second moat, described here, is that the platform refuses to take actions for which it cannot produce a proof. Together they form a cycle: the ontology evolves under the same proof gate that governs every other action, and the proof gate is justified by an ontology that operators trust because it grew from their behaviour.

Neither is original as an idea. Both are unusual as a shipped, governed pipeline. Defence and government buyers in our pipeline are not looking for novelty; they are looking for the rare vendor whose architecture matches the accountability environment they actually work in. Policy-by-Proof is the architecture that matches.

What ships next

Phase 1 ships HMAC-SHA256 signatures over canonicalised packets and a chain verifier UI at /audit. Phase 2 swaps in Ed25519 with key rotation and integrates an RFC 3161 TSA for export bundles. Phase 3 adds the cross-tenant disclosure protocol — every packet shared with a peer tenant carries its own derivation proof, separately signed by the sharing tenant, so a coalition reader can verify the chain without trusting the channel.

Phase 4 — the most interesting — wires the policy clauses directly into the agent prompts. The agent is given the current policy bundle as part of its system context, and any proposed action that cannot cite the clause that authorises it is rejected at the gate. This closes the last remaining loophole: agents proposing actions whose justification is implicit rather than explicit.

An invitation

The Phase 1 substrate is live at taygeta.maiaintelligence.io. The proof packets are produced on every action; the audit chain is queryable at /audit; the verifier walks the chain and confirms every hash + signature is intact. We are happy to walk through specific defence and government use cases on request.

References

  • U.S. Department of Defense, DoD Responsible AI Strategy & Implementation Pathway (DoD CDAO, 2022, updated 2026).
  • NIST AI Risk Management Framework, AI 100-1 / Generative AI Profile (NIST, 2024).
  • IETF RFC 3161, Time-Stamp Protocol (TSP) (Adams & al., 2001).
  • FedRAMP Authorization Boundary & Data Authorization (FedRAMP, 2025).
  • Canada Treasury Board, Directive on Automated Decision-Making (TBS, 2023).
  • MAIA Research, The Living Ontology, 2026 (companion paper).