# 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 topology 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.