Deep dive into the ABS Core governance engine -- deterministic execution, memory isolation, and the Rust-to-WASM compilation strategy.

WASM Behavioral Kernel

The ABS Core governance engine is designed for one purpose: evaluate tool calls with cryptographic determinism, at microsecond latency, in a sandboxed environment that no agent can escape.

Architecture Overview

                   Tool Call Request
                         |
                         v
              +---------------------+
              |   Protocol Adapter  |   (MCP / A2A / AG-UI)
              +---------------------+
                         |
                         v
              +---------------------+
              |  GOVERNANCE ENGINE  |   <-- This is the WASM kernel
              |                     |
              |  Policy Evaluator   |
              |  SHA-256 Hasher     |
              |  Ed25519 Verifier   |
              |  NIST Mapper        |
              |  Drift Detector     |
              |  SAR Generator      |
              +---------------------+
                         |
                    ALLOW / DENY

Why WASM

The governance engine handles the most security-critical path in the system: deciding whether an AI agent action is permitted. This demands:

Determinism -- The same input must always produce the same output. No garbage collection pauses. No JIT recompilation surprises. WASM executes compiled bytecode with predictable performance.

Memory isolation -- The engine runs in a sandboxed linear memory space. A malicious payload in a tool call cannot escape the sandbox to access the host system. This is enforced by the WASM runtime, not by application code.

Portability -- The same binary runs in Node.js, Python (via wasmtime), browsers, Cloudflare Workers, Deno, and embedded systems. One engine for every deployment target.

Performance -- Near-native execution speed. The current JS shim achieves 235K req/s. The Rust-compiled WASM engine is projected to exceed 500K req/s.

Current State: JS Shim with WASM Parity Contract

The v4.1.0 engine runs as TypeScript with a strict WASM parity contract:

Component	Current (JS)	Target (WASM)	Parity Verified
Policy Evaluator	TypeScript	Rust	6 test vectors
SHA-256 Hasher	`node:crypto`	`ring` crate	Hash compatibility contract
Ed25519 Verify	`node:crypto`	`ed25519-dalek`	6 test vectors
NIST Mapper	TypeScript	Rust	Schema-level parity
SAR Generator	TypeScript	Rust	Field-level parity

The Hash Compatibility Contract ensures that the JS shim and the future WASM engine produce identical hashes for identical inputs. This is validated by 6 test vectors that run on every build.

The Compilation Strategy

Phase 1 (Current): TypeScript engine with WASM behavioral contract. All governance logic is in TypeScript. Test vectors guarantee future WASM parity.

Phase 2 (Post-funding): Rust core compiled to WASM. The governance kernel is rewritten in Rust and compiled to a .wasm binary (~2MB). Protocol adapters (MCP, A2A) remain in TypeScript.

Phase 3 (Multi-runtime): Universal distribution.

@abscore/governance-engine      -> npm (JS/TS via WASM)
abscore-governance-engine       -> PyPI (Python via wasmtime)
abscore-governance-engine       -> crates.io (Rust native)
abscore-governance-engine.wasm  -> Direct download (any runtime)

Security Properties

Capability-based security -- The WASM runtime grants the engine access only to the data it needs: the tool call payload and the policy file. It cannot access the filesystem, network, or host memory.

No ambient authority -- The engine cannot make outbound network calls. It cannot read environment variables. It cannot spawn processes. All I/O is mediated by the host adapter.

Tamper detection -- Each SAR includes an engine_fingerprint field: the SHA-256 hash of the running engine binary. If the engine is replaced with a modified version, every subsequent record will carry a different fingerprint, making the tampering auditable.

Engine Fingerprint

Every SovereignAuditRecord v4.1.0 includes:

{
  "engine_fingerprint": "a3b4c5d6e7f8..."
}

This is the SHA-256 hash of the governance engine binary that produced the decision. It enables:

Provenance verification -- Auditors can verify which exact engine version was running at any point in time.
Dual-signature updates -- Engine updates are signed with both a development key and an offline production key (cold wallet). The host only accepts updates with both signatures valid.
Rollback detection -- If an older engine version is deployed, the fingerprint change is visible in the audit trail.

Quickstart -- Get running in 60 seconds
KeyProvider API -- Key management deep dive
NIST AI RMF Mapping -- How engine decisions map to compliance controls

WASM Behavioral Kernel

On this page