Zero-Trust Sandboxing for AI Code: Hardening Path Traversal and CPU Watchdogs 🔒
Executing AI-generated bytecode on a host machine requires strict zero-trust sandboxing. An untrusted or buggy AST program could attempt directory traversal, infinite loops, or host memory exhaustion. In audit release v2.11.2-audit (commit 1572173) and v2.12.0, we introduced comprehensive path traversal protection and resource quota shielding.
1. The Threat Model: Untrusted AST Execution
When an AI agent executes code via knc_execute, the runtime must assume the AST could contain malicious path manipulation sequences (such as ../ relative traversals or null-byte \0 injections) or tight infinite execution loops designed to consume 100% CPU.
2. validate_fs_path(): The Path Traversal Shield
In io.rs and bridge.rs, file operations like IO.WriteFile, IO.ReadFile, and native file writes now route strictly through validate_fs_path() and validate_fs_path_write().
Any path attempting to escape the designated workspace boundary or containing suspicious characters is immediately rejected with a sandbox permission error. Furthermore, storage.rs validates key parameters in store_value() and load_value(), blocking keys with /, \, .., or null bytes.
3. CPU Watchdog Hardening (500ms Threshold)
To prevent runaway loops from hanging the execution thread, KnotenCore includes an active CPU watchdog timer. In v2.12.0, the default watchdog timeout was adjusted from 50ms to 500ms in machine.rs and evaluator loops.
This provides sufficient headroom for complex JIT computations while guaranteeing that non-terminating loops are forcibly aborted before starving system resources.
4. Multi-Tenant Isolate Quotas
Beyond CPU timeouts, each session isolate is bound by IsolateQuota limits (maximum memory bytes and instruction caps). Sessions exceeding their quota receive a -32000 Quota Exceeded JSON-RPC fault, preserving host stability across multi-tenant workloads.