Tool Sandboxing

Pain Signals — You Need This Pattern When:

• Tools can execute arbitrary code (Bash, python, node -e) and a hallucinated command could damage the host
• Tools fetch URLs, and a prompt-injected URL could exfiltrate secrets or pivot internally
• Tools have ambient credentials (cloud SDK, kubeconfig) that grant far more than the task requires
• Untrusted input (user uploads, web pages, third-party APIs) reaches the LLM and shapes tool calls — prompt injection is realistic
• The harness runs as a service for multiple users; one user's session must not affect another's

Two distinct goals. Safety sandboxing prevents accidents (rm -rf typos). Security sandboxing prevents adversaries (prompt injection driving exfiltration). Same mechanisms, different threat models — and security sandboxing is strictly harder. If your threat model includes an attacker, accept that defense-in-depth is required.

Core Principle

Treat the tool layer as untrusted by default. The trust boundary is between the harness core (your code, your decisions) and tool execution (model-driven, prompt-injectable). Everything the model can cause to happen must be bounded explicitly.