Skip to content

Dynamic Capabilities & WASM Sandboxing

The coreason-runtime evaluates and executes all exogenous capabilities, external Model Context Protocol (MCP) servers, and dynamic agent functions within a strict, zero-trust isolation boundary powered by Extism WebAssembly (WASM).

This document outlines the capability lifecycle, from network-based acquisition to secure physical substrate execution.

1. Stateless Capability Acquisition

The runtime operates as a completely stateless execution substrate. It does not load .wasm plugin files from local disk paths. All capabilities are acquired dynamically at execution time.

  • URN Resolution: When the orchestration engine routes an intent to a specific capability, the runtime resolves the capability's Universal Resource Name (URN).
  • Ecosystem Registry Client: The EcosystemRegistryClient fetches the compiled WASM binary dynamically from the coreason-ecosystem registry via standard HTTP streams.
  • Network Volumetric Traps: During capability acquisition, the client enforces a strict MAX_ALLOCATION_BYTES (10MB) limit on the incoming network stream. If a binary exceeds this limit, the connection is instantly aborted to prevent network-level memory exhaustion attacks.
  • In-Memory Initialization: The Extism plugin is initialized purely from the downloaded byte stream (initialize_from_bytes), maintaining the daemon's stateless integrity.

2. Capability Execution & Security Boundaries

Once a capability is mounted in the enclave, it is subjected to the runtime's workload identity architecture and physical memory limits.

Workload Identity & Access Control (SPIFFE/SPIRE + Envoy)

Cross-boundary data flow security is delegated to the CNCF-standard SPIFFE/SPIRE + Envoy service mesh: * Workload Identity (SPIFFE): Each execution thread receives a cryptographic SVID (SPIFFE Verifiable Identity Document) via the local SPIRE agent, replacing the previously custom classification hierarchy. * mTLS Enforcement (Envoy): Before any executed payload can leave the sandbox and be routed to a destination sink, the Envoy sidecar enforces mutual TLS verification. If the workload identity's clearance does not match the destination's required trust level, the connection is refused and a SecurityViolationError is raised.

Memory & Panic Guillotines

  • \(O(N)\) Bounds Verification: A malicious or infinitely-looping WASM guest could attempt to return a massive byte array to crash the host. The enclave enforces a MAX_ALLOCATION_BYTES = 10485760 trap that evaluates the raw output array length before utf-8 decoding or JSON deserialization occurs.
  • Panic Mitigation: All execution blocks are wrapped in strict exception handlers. Raw traps or memory panics from the Rust/C++ WASM guest are caught and normalized into predictable ManifestConformanceError exceptions, ensuring the primary asynchronous orchestration loop never crashes.

Native Dictionary Routing

To maximize throughput and prevent deep architectural coupling, the internal enclave execution methods (execute_intent) operate strictly on native Python dictionaries. This decouples the sandbox from the heavy Pydantic serialization overhead of the coreason-manifest models, which are relegated to the API gateway layer.

3. Master MCP Publication (Epistemic Crystallization)

When the runtime synthesizes a new composite swarm or dynamic capability during an active workflow (e.g., capability_forge_execution_workflow), that new capability is immediately exported back to the governance plane.

  • Epistemic Promotion: The newly mapped topological DAG is mathematically hashed (SHA-256) and wrapped in an EpistemicPromotionEvent.
  • Network Registration: The runtime uses the EcosystemRegistryClient to transmit this event to the coreason-ecosystem. The ecosystem validates the composite capability and returns a globally resolvable URN.
  • Idempotent Fallback: In the event of a network partition or ecosystem registry failure, the runtime degrades gracefully, logging the promotion event to the local LanceDB sovereign store to ensure zero data loss.