WASM Sandbox
WASM Sandbox
Section titled “WASM Sandbox”WebAssembly is used in sigMAX as a portable and isolated execution target for generated business logic.
The sandbox limits the execution boundary. Runtime imports expose only the primitives that are allowed by the binary contract and effective agreement.
Why WebAssembly
Section titled “Why WebAssembly”WebAssembly is a low-level, portable binary format designed for compact representation and efficient execution.
For sigMAX, the useful properties are:
- portable executable artifacts;
- sandboxed execution;
- explicit imports and exports;
- deterministic compilation targets such as
wasm32; - a narrow host boundary controlled by the runtime;
- compatibility with generated code from a deterministic C subset;
- a clear separation between executable logic and host infrastructure.
Core Model
Section titled “Core Model”What Is Isolated
Section titled “What Is Isolated”A WASM module works with its own linear memory.
Host memory is not directly addressable by the module. When data crosses the boundary, the runtime reads or writes bytes through explicit pointers, lengths and validation rules.
A module can only call host functions that the runtime provides as imports.
In sigMAX, these imports are runtime primitives. Examples include reading inputs, writing responses, emitting logs, extracting JSON values, using approved secrets, or invoking allowed services.
A module exposes callable functions through exports.
The runtime chooses which exported entrypoint to call for a route or component, then interprets the result through the contract and agreement model.
Sensitive operations require capabilities.
If a route is not allowed to use a primitive such as HTTP invocation, random bytes, secret HMAC, or time access, the runtime denies the call instead of forwarding it to the host.
What The Sandbox Does Not Do
Section titled “What The Sandbox Does Not Do”The WASM sandbox is an execution boundary, not a complete application security model.
It does not automatically provide:
- correct business rules;
- authorization logic;
- network policy;
- secret governance;
- TLS termination;
- reverse proxy configuration;
- Kubernetes isolation;
- storage policy;
- audit completeness.
Those responsibilities belong to contracts, agreements, runtime policy, infrastructure configuration, and Enterprise governance when applicable.
sigMAX Runtime Rules
Section titled “sigMAX Runtime Rules”sigMAX treats WASM as one part of a larger controlled runtime model.
The runtime should:
- load WASM modules from generated or validated artifacts;
- expose only the imports required by the binary contract;
- map route inputs into controlled memory or typed values;
- validate pointer ranges, lengths and output buffers;
- return stable error codes for invalid, denied, missing or unsupported operations;
- emit evidence through logs, metrics, traces or agreements;
- keep host services behind policy-controlled primitives.
Relationship With c_repr
Section titled “Relationship With c_repr”Some typed values cross the WASM boundary through a C-compatible binary representation named c_repr.
This does not mean the host primitives are implemented in C. In sigMAX, host primitives belong to the Rust runtime. The c_repr layout is only a stable memory format used when generated WASM logic and the runtime need to agree on field offsets, numeric types, booleans and fixed-size strings.