🤖 AI

Certified Purity for Cognitive Workflow Executors: From Static Analysis to Cryptographic Attestation

This paper introduces a certified purity architecture that strengthens cognitive workflow governance by replacing runtime conventions with structural boundaries through restricted WebAssembly compilation, cryptographic purity certificates, and remote attestation, thereby mathematically proving the elimination of adversarial bypasses while maintaining negligible runtime overhead.

Original authors: Alan L. McCann

Published 2026-05-06

📖 5 min read🧠 Deep dive

CC0 1.0

Original authors: Alan L. McCann

Original paper dedicated to the public domain under CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are running a high-stakes kitchen where a team of chefs (AI agents) prepares complex meals (cognitive workflows) for VIP guests. The rules are strict: the chefs can plan the meal and write down what ingredients they need, but they are strictly forbidden from actually touching the stove, opening the fridge, or calling the delivery driver. Only the Head Chef (the "Governance Pipeline") is allowed to perform those actions.

For a long time, the kitchen relied on a simple rule: "Trust the chefs to follow the rules." The kitchen managers would look at the chefs' recipe books (static analysis) to see if they had written down any forbidden instructions. If the recipe looked clean, the chef was allowed to work.

The Problem: The "Magic Trick" Loophole
The paper explains that this "trust the recipe" system has a fatal flaw. A determined, sneaky chef could use magic tricks to bypass the rules without writing them down in the recipe book. On the specific kitchen platform they use (called BEAM/Erlang), a chef could:

Pretend to be someone else: Call a function by its name at the last second, hiding the fact that they are calling a dangerous tool.
Write new rules on the fly: Type in a new command while cooking, effectively rewriting their own recipe mid-meal.
Hire a bodyguard: Load a secret, pre-written tool (a "NIF") that can do anything, including opening the fridge.
Send a runner: Spawn a separate person outside the kitchen to go get ingredients.
Swap the recipe book: Load a completely different, dangerous recipe book while cooking.

Because these tricks happen while the chef is working, looking at the recipe book beforehand (static analysis) can't catch them. It's like trying to stop a magician by checking their pockets before the show; they might have a hidden card they pull out later.

The Solution: The "Certified Purity" Kitchen
This paper proposes a radical new kitchen design that makes these magic tricks physically impossible, not just against the rules.

1. The New Kitchen (WebAssembly Sandbox)
Instead of letting chefs work in the open kitchen, they now work inside a transparent, sealed glass box.

No Magic Tricks: Inside this box, the tools for "hiding," "rewriting," or "hiring bodyguards" simply do not exist. The box is built so that the only way to get out is through a single, locked door.
The Whitelist: The box only has a specific list of tools it can use (like a calculator, a notepad, and a "request form"). It cannot touch the stove or the fridge. If a tool isn't on the list, the box literally doesn't have the handle for it.

2. The ID Badge (Purity Certificate)
Before a chef enters the kitchen, they must get a special ID badge.

The Proof: A trusted authority looks at the chef's code (the "binary") and checks that it only uses the allowed tools.
The Seal: They sign the badge with a cryptographic seal (like a wax stamp). This seal proves that this specific version of the chef's code is clean.
The Anti-Tamper: If the chef tries to change their code even slightly (to add a secret tool), the seal breaks. The badge becomes invalid. You can't take a clean badge from Chef A and give it to a modified Chef B.

3. The Security Guard (Runtime Gate)
When a chef arrives at the kitchen door, a security guard checks the badge.

The Check: The guard verifies the seal, checks that the code matches the badge, and confirms the tools listed are still on the "allowed" list.
The Result: If the badge is valid, the chef enters. If not, they are turned away immediately. This happens every single time before the chef starts cooking.

4. The Cross-Kitchen Passport (Remote Attestation)
What if Chef A works in Kitchen A, but needs to hire Chef B from Kitchen B?

Chef B brings a "Passport" (an attestation record) that proves they were checked by their own kitchen's security guard and that their kitchen follows the same strict rules.
Kitchen A can read this passport and trust Chef B without needing to see Chef B's source code or sign a contract. It's a machine-readable proof of trust.

Why This Matters (The Results)
The paper proves that this system works mathematically:

No Loopholes: Because the "magic tricks" (bypass classes) are structurally absent from the new kitchen, a sneaky chef literally cannot perform them. It's not that they are caught; it's that they can't happen.
Fast: Checking the badge takes less than a blink of an eye (about 40 microseconds). The extra time it adds to cooking a meal is less than 0.4% of the time it takes to wait for a delivery truck.
Trustless: You don't have to trust the chef, the kitchen manager, or the other kitchen. You only have to trust the math behind the seal and the design of the glass box.

In Summary
The paper moves governance from a "Please don't steal" sign (which relies on people following rules) to a "You physically cannot steal" wall (which relies on the structure of the building). It turns a promise into a mathematical guarantee, ensuring that AI agents can plan and think, but they can never secretly act outside the rules.

Technical Summary: Certified Purity for Cognitive Workflow Executors

1. The Problem: The Purity Gap in Cognitive Workflows

Cognitive workflow systems (orchestrating AI inference, tool use, and reasoning) increasingly operate in high-stakes domains. Previous work (McCann [2026e]) established a three-layer governance architecture that guarantees Governance Completeness, Provenance Completeness, and the Impossibility of Ungoverned Effects. However, these safety theorems relied on a critical premise: the Pure Module Constraint, which requires that executor modules cannot perform I/O effects and can only return declarative directives.

In the prior implementation, this constraint was enforced via static module import graph analysis on the BEAM virtual machine (Erlang/OTP). While stronger than convention-based governance, this mechanism is insufficient against adversarial bypass. The BEAM's dynamic features allow five distinct classes of bypass that static analysis cannot reliably prevent:

Dynamic Dispatch: Using :erlang.apply/3 to invoke arbitrary functions without static imports.
Code Evaluation: Using Code.eval_string/1 to execute arbitrary code at runtime.
Native Implemented Functions (NIFs): Loading shared libraries with unrestricted system access.
Ports: Spawning external processes via :erlang.open_port/2.
Dynamic Module Loading: Loading arbitrary bytecode at runtime via :code.load_binary/3.

Due to Rice's Theorem, no static analysis can decide the non-trivial semantic property of "no I/O effects" for all possible programs. A sound overapproximation would reject most legitimate idiomatic Elixir code. This creates a purity gap: the formal model assumes purity, but the enforcement mechanism (static analysis) cannot structurally guarantee it against a determined adversary.

2. Methodology: From Detection to Structural Prevention

This paper proposes a Certified Purity Architecture that converts the pure module constraint from a convention enforced by analysis into a structural capability boundary enforced by the execution environment. The methodology relies on four core mechanisms:

A. Restricted Compilation Target (WebAssembly)

Executors are compiled to a restricted WebAssembly (WASM) target. The WASM capability model is leveraged to structurally eliminate all five BEAM bypass classes:

No Dynamic Dispatch: WASM lacks instructions to resolve function calls by runtime string/atom names; calls are restricted to static indices in a function table.
No Code Evaluation: WASM executes pre-compiled bytecode; there is no mechanism to generate or load new code at runtime.
No NIFs/Ports: WASM modules run in a sandboxed VM with no access to host file systems, shared libraries, or process spawning.
No Dynamic Loading: Module instantiation is controlled entirely by the host; modules cannot load other modules.

B. The Host Function Whitelist ( $W$ )

The WASM module can only invoke functions explicitly declared in its import section. These imports are restricted to a finite, enumerated Whitelist ( $W$ ):

$W_{data}$ : Pure data operations (memory management, string manipulation, arithmetic, JSON serialization, context reads).
$W_{dir}$ : Directive constructors (functions that build data structures representing intended effects, e.g., directive_http_request, but do not execute them).
Exclusion: WASI (WebAssembly System Interface) imports, which grant effect capabilities, are explicitly excluded.

C. Purity Certificates

A Purity Certificate is a cryptographic proof artifact binding an executor binary to its purity classification.

Structure: Contains the SHA-256 hash of the executor binary, the hash of the purity proof (import list + classification), and an Ed25519 signature over these hashes.
Integrity: Due to the collision resistance of SHA-256 and the unforgeability of Ed25519, a certificate cannot be transferred to a modified artifact.

D. Runtime Verification Gate

Before an executor enters the governance pipeline, a Verification Gate performs:

Signature Verification: Validates the Ed25519 signature.
Artifact Binding: Confirms the binary hash matches the certificate.
Independent Proof Derivation: Parses the WASM binary's import section de novo and verifies it matches the claimed purity proof against the current whitelist.
Classification Validation: Ensures all imports are classified as pure.

Only executors passing this gate are instantiated. This gate acts as a structural precondition, ensuring that no executor without a valid purity certificate can execute.

3. Key Contributions

Formal Threat Model: A rigorous characterization of the five BEAM bypass classes and the theoretical limits of static analysis (Rice's Theorem) in this context.
Structural Purity by Construction: A proof (Theorem 4.5) that compiling to the restricted WASM target satisfies the pure module constraint by construction, independent of the executor's code content.
Bypass Elimination: Formal proofs (Theorem 5.5) that each of the five BEAM bypass classes is structurally impossible in the restricted WASM environment.
Cryptographic Attestation: A scheme for Purity Certificates and Remote Attestation Records that enables portable, cross-organizational verification of executor purity without source code access.
Trusted Computing Base (TCB) Definition: An explicit definition of the five components required for the guarantee (WASM runtime, host functions, whitelist, verification gate, directive interpreter), reducing the trust surface from unbounded executor code to a bounded, auditable set.
Graduated Trust Tiers: An implementation architecture supporting three tiers (Verified Purity, Static Analysis, Experimental) to allow incremental adoption.

4. Results and Evaluation

The architecture was evaluated on four implemented executors (Rust-based, compiled to WASM) running on an Apple M-series processor with the Wasmtime JIT backend.

Verification Latency: The verification gate takes 39–42 µs (median) for production executors. With hash-based caching, amortized cost approaches zero for repeated invocations.
Runtime Overhead: The full plan cycle (instantiation, execution, deserialization) completes in 256–398 µs. This represents <0.4% overhead on a 100 ms HTTP request and <0.05% on a typical 800 ms LLM call.
Determinism: Zero divergences were observed across 40 repeated invocations with identical inputs, confirming the deterministic nature of the WASM execution environment.
Certificate Size: Certificates are compact (~1.3 KB), well within bandwidth budgets.
Correctness: All executors produced the expected directive shapes, and the system maintained byte-identical outputs across runs.

5. Significance and Claims

The paper claims a fundamental shift in the epistemological status of governance guarantees:

From Detection to Prevention: Previous approaches relied on detecting known bypass patterns via static analysis. This architecture prevents bypass by making effect-producing capabilities structurally absent.
Strengthening Existing Theorems: The safety theorems from McCann [2026e] (Governance Completeness, Provenance Completeness, No Ungoverned Effects) remain formally identical. However, their foundational premise is discharged mechanically rather than assumed. The guarantee now rests on the mathematical properties of the WASM capability model and cryptographic primitives (SHA-256, Ed25519) rather than the limitations of a static analyzer.
Portable Trust: By converting local purity proofs into portable attestation records, the architecture enables cross-organizational governance composition, allowing Organization A to cryptographically verify the purity of Organization B's executors without source code review.

The paper explicitly notes that this is not a mechanized proof in the sense of Rocq or Lean (which is reserved for the underlying governance logic in companion papers), but a structural guarantee verified at runtime. The contribution is the reduction of the trust surface from "all executor code" to a small, explicitly defined Trusted Computing Base.