ABS Core v4.5.0
Architecture

WASM Behavioral Kernel

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: Rust Core, Compiled and Running

This page previously described the WASM kernel as future work ("Phase 2, post-funding"). That's out of date: abs-core/core/engine-wasm is a real Rust crate (Cargo.toml, version 4.3.3, 1,600+ lines in src/lib.rs) that is already compiled to pkg/abs_core_engine_bg.wasm and running — it's what the 1.2ms/23ms latency figures elsewhere in these docs measure.

ComponentImplementation
Policy EvaluatorRust, compiled to WASM
SHA-256 Hasherring crate
Ed25519 Verifyed25519-dalek
Shadow modeshadow_mode: bool flag + set_shadow_mode() on ABSEngine

There is a separate TypeScript orchestration layer (Hub, gateway, adapters) around the kernel — MCP/A2A protocol handling, Worker-thread isolation, and IPC stay in TypeScript. The kernel itself — the deterministic policy hot path — is the compiled Rust/WASM binary, not a JS shim.

Distribution

Current build output:

abs-core/core/engine-wasm/pkg/
  ├── abs_core_engine_bg.wasm
  ├── abs_core_engine.js
  └── package.json

Multi-runtime packaging (separate npm / PyPI / crates.io publishing pipelines) is not set up yet — the WASM artifact is consumed in-repo today, not published standalone.

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.3.3 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.

On this page

WASM Behavioral KernelArchitecture OverviewWhy WASMCurrent State: Rust Core, Compiled and RunningDistributionSecurity PropertiesEngine FingerprintRelated