WASM Execution Boundaries

sigMAX compiles business handlers to WebAssembly and gives them a controlled import surface. The execution boundary depends on the edition: Core runs WASM inside its containerized runtime; Pro places the COS2000 executor inside a KubeVirt virtual machine.

Both editions are proprietary. The difference described here concerns deployment and execution isolation.

Core And Pro

Boundary	Core	Pro
Deployment	Docker Compose on one machine.	Kubernetes.
Host and Config	On the same host.	Part of the Kubernetes architecture.
WASM executor	Inside the runtime container.	COS2000 inside a VM managed by KubeVirt.
Dedicated VM isolation for execution	No.	VM boundary around the executor.
Business interface	Declared imports, capabilities and typed data.	The same contract-first design, with an executor integration that must support the required ABI.

Compare the editions or read about the COS2000 executor.

Controls In The Rust Implementation

The current container runtime uses Wasmtime with explicit sigmax imports. The compiler validates the binary import table against an allowlist; runtime linking rejects unsupported imports.

Control	What it does
Linear memory	Keeps guest addresses within the WASM memory model; the host validates buffers it reads or writes.
Imports	Exposes known runtime functions instead of ambient operating-system APIs.
Capabilities	Gates host operations against the active route’s permissions.
Bindings	Maps logical names to host-owned services, topics, object stores and cache namespaces.
Memory limits	Constrains instance memory and growth when configured on the route.
Fuel and deadlines	Bounds guest execution and interrupts requests that exceed their budget.
Instance lifecycle	Discards damaged instances after traps, timeouts or panics.

The modes performance and safer control instance reuse. safer discards guest state after an executed request; neither mode creates a separate process or VM. See the Rust runtime lifecycle.

Controlled Host Access

Host operations

Generated business code uses primitives for inputs, responses, storage calls, HTTP, logs, metrics and other declared effects. It does not receive direct filesystem, database, process or raw socket access.

Outbound policy

Outbound HTTP is denied unless the signed component contract declares a policy. An allowlist policy resolves named destinations; an explicit mode: all policy can permit a dynamic HTTP(S) origin. Methods, paths, headers, timeouts and response sizes remain constrained by that policy.

Typed inputs use c_repr layouts. ObjectIR and DocIR keep public output structured so the host can validate and render it. These formats describe the ABI; they do not grant host privileges.

The Pro VM Boundary

The Pro architecture separates WASM execution through COS2000 in a KubeVirt VM. Kubernetes schedules the surrounding deployment, while KubeVirt manages the VM lifecycle.

The inspected Rust runtime sources implement the container path. They do not contain the complete Host-to-COS2000 integration or KubeVirt deployment manifests. VM isolation, ABI compatibility, capability propagation and operational behavior must therefore be validated together for a Pro release; Wasmtime-specific settings must not be assumed to apply inside COS2000.

Responsibilities Beyond WASM

Execution controls do not establish business correctness, application authorization, network policy, TLS, backup policy or complete audit evidence. Those responsibilities remain in contracts, validation, deployment configuration and operational procedures.

An agreement records evidence about artifacts and checks performed. It is not a substitute for the running system’s security controls.