Beta Environment Notice

TDM is currently in Beta. Exercise caution when handling assets. Use at your own risk.

Fast Export

Switch the current page to Markdown for fast agent reading, or download it as a .md file.

Execution Sandbox

# Execution Sandbox

Summary: DaOS uses WebAssembly plus the TDM IPC ABI to run untrusted code. Every plugin installed from the TDM Hub runs in its own isolated sandbox, preventing it from accessing your host machine, files, or network without explicit permission.

Status: Technical architecture

Topics:
- Sandboxing mechanics
- WASM capability model
- Plugin isolation
- Memory safety

Packages:
- tdm-sdk

Commands:
- tdm workspace status

Execution Sandbox

In a world of agentic plugins, Security is non-negotiable. Contour Runtime enforces a strict Zero-Trust execution model using WASM.

Why WASM IPC?

Unlike Docker or VMs, WASM provides Granular isolation with near-zero overhead. TDM adds a narrow JSON-RPC IPC boundary, WASI Preview1 reactor startup, and host-side capability checks.

Memory Safety

WASM's linear memory model prevents buffer overflows and pointer manipulation outside the sandbox.

Capabilities

FileSystem and Network access are provided via "Capabilities" (descriptors) rather than global paths.

Determinism

Code behaves exactly the same across different OSs and architectures (Windows, Linux, macOS).

Sandbox Constraints

By default, a new plugin has the following constraints:

default-constraints.txt

- Network: Blocked
- FileSystem: Read-only access to its own /dist/ folder
- Memory: Limited to 64MB
- Execution Time: Max 5 seconds per intent
- Environment: No access to host env vars

Sandbox Mechanics

The Contour Runtime uses a dedicated WASM worker sandbox to execute plugins. This architecture provides several layers of defense:

1. Absolute Isolation

WASM modules run in a dedicated memory space. They cannot access pointers outside their own heap, making them immune to traditional buffer overflow exploits.

2. Deny-by-Default Capabilities

Marketplace WASM modules are loaded with empty WASI args, empty env, no preopened directories, and a strict WASI import allowlist. Network, tool, vault, and context access must flow through explicit host-approved intents and permissions.

3. JSON-RPC over IPC

Communication between the SDK and the WASM plugin happens through exported linear memory. The SDK writes a JSON-RPC request, calls tdm_plugin_execute_intent, and reads a length-prefixed JSON result.

Plugin Interface

Every DaOS plugin must implement the TDM IPC protocol. The runtime validates these exports before launch:

plugin-example.rs

#[no_mangle]
pub extern "C" fn tdm_alloc(size: usize) -> *mut u8;

#[no_mangle]
pub extern "C" fn tdm_free(ptr: *mut u8, size: usize);

#[no_mangle]
pub extern "C" fn tdm_plugin_execute_intent(ptr: *const u8, len: usize) -> *const u8;

// Return pointer layout:
// [u32 little-endian json_length][json response bytes]

failed-response.json

{
  "status": "failed",
  "message": "Request rejected by plugin policy.",
  "blockedReason": "plugin_policy_rejected",
  "recoveryHint": "Review the plugin policy and retry manually.",
  "output": {
    "retryable": false
  }
}

Threat Model

A plugin cannot read host env vars because the WASI runtime receives an empty environment.
A plugin cannot access host files because no directories are preopened and filesystem imports are rejected.
A plugin cannot call arbitrary host functions because non-allowlisted imports are rejected before instantiation.
A plugin cannot read host memory; the host only accesses exported linear memory after bounds checks.
A plugin cannot auto-launch after install or payment; operator confirmation remains a separate runtime step.
A plugin cannot obtain raw vault secrets through vault:read; only non-secret metadata and policy state are exposed.