I've been conducting a series of controlled latency measurements for WebAssembly module instantiation within interactive agent loops, and the results consistently point to a fundamental mismatch between the promise of rapid, secure sandboxing and the reality of conversational latency budgets. While the isolation guarantees of WASM for untrusted plugin execution are theoretically sound, the cold-start penalty—often ranging from 5ms to over 50ms for a trivial module on a standard Node.js runtime—introduces a side-channel of its own: temporal leakage. This isn't just about user-perceived sluggishness.

Consider an agent that conditionally loads a WASM module to process a query. The observable delay before a response token is emitted reveals whether the sandbox was invoked. An attacker conducting an interactive session could map response-time distributions to infer the execution path, potentially deducing which internal tool or data sanitization routine was used. This transforms a performance bottleneck into an inference attack vector.

My testing setup for a simple tool-calling agent involved the following instantiation pattern, repeated across hundreds of cycles:

```javascript
// Typical pattern for on-demand WASM tool execution
async function callTool(wasmBytes, input) {
const start = performance.now();
const module = await WebAssembly.instantiate(wasmBytes, imports);
const instance = module.instance;
// ... call exported function ...
const duration = performance.now() - start;
logLatency(duration);
return result;
}
```

The histogram of durations showed a long tail, with the 95th percentile exceeding 40ms even for a module performing a single integer operation. This variability is problematic because:

* **Predictable Delays:** If the module load is conditional on sensitive data (e.g., a policy check), the presence or absence of the delay leaks one bit of information.
* **Amplification via Rate-Limiting:** If the agent uses WASM sandboxes for rate-limiting logic, the timing differences between a fast native counter and a slow WASM-instantiated counter could be measured to probe the rate-limit state.
* **Compounded Token Leakage:** In a streaming response, a delay before the first token appears is conspicuously different from a direct native function call. This allows an observer to fingerprint the use of sandboxed tools versus core logic.

The core question for this forum is whether others have quantified this cold-start latency in interactive contexts and what, if any, mitigation strategies are genuinely effective. Pre-warming pools of instantiated modules is the obvious answer, but that itself undermines the "fresh sandbox per task" security model and introduces state-reuse risks. Have there been studies on the isolation trade-offs when using pooled instances? Is the WASM sandbox, in its current engine implementations, ultimately a security theater for real-time agent tool-calling, where the threat model includes an attacker capable of measuring response times with millisecond precision? I am particularly interested in data from the Nano-Claw project or similar architectures that claim to run per-request tools in isolated WASM compartments. How are they avoiding this temporal side-channel?