Sandboxed Execution: Why Every AI Agent Tool Needs Isolation
When an AI agent calls a tool, what actually happens? In most frameworks, the tool function executes in the same process as the agent, with the same permissions, the same network access, and the same credentials. The agent has access to a database connector? That connector has the full database password in memory. The agent can make HTTP requests? It can reach any endpoint the host machine can reach. The agent generates code to execute? That code runs with the full permissions of the agent process.
This is the default architecture for the majority of agentic AI frameworks. Tools are Python functions or JavaScript modules that run inline with the agent. There is no process boundary between the agent's reasoning and the tool's execution. There is no privilege separation between "the model decided to call a tool" and "the tool accessed production infrastructure." The agent and the tool are the same security principal.
In a development environment, this is convenient. In production, it is a vulnerability.
The Shared-Process Problem
The shared-process model creates three categories of risk that compound in production deployments:
Credential exposure. When tools run in the agent process, credentials are accessible to all code in that process. A database tool's connection string, an API tool's authentication token, a file system tool's path permissions — they are all available to every other tool and to the agent itself. If the model is instructed (intentionally or through prompt injection) to inspect its own environment, it can potentially access every credential loaded by every tool.
Lateral movement. If one tool is compromised — through a supply chain attack on a dependency, a vulnerability in the tool's implementation, or a malicious prompt that exploits the tool's capabilities — the attacker has access to everything the agent process has access to. There is no blast radius containment. A vulnerability in a low-risk logging tool can become an attack vector for a high-risk database tool because they share a process.
Resource exhaustion. A runaway tool — one caught in an infinite loop, consuming excessive memory, or making unbounded network requests — affects the entire agent process. There is no resource isolation. A tool that leaks memory eventually crashes the agent. A tool that hangs blocks other tool invocations. A tool that floods an API endpoint triggers rate limiting that affects unrelated operations.
How the Platform Implements Tool Isolation
In the platform, every tool execution happens in a Kubernetes-isolated sandbox with explicit, enforced boundaries. This is not optional sandboxing you enable for production. It is the execution model. There is no non-sandboxed mode. The same isolation model powers Code Mode — the platform's browser-based VS Code environment with AI pair programming — where each developer session runs in its own K8s pod with resource limits, network policies, and scoped credentials.
Process Isolation
Each tool invocation spawns a separate subprocess. The tool code executes in its own process space with its own memory, its own file descriptors, and its own resource limits. The agent process communicates with the tool subprocess through a structured message interface — it sends the tool input, receives the tool output, and never shares memory or state with the tool.
This means a failure in one tool cannot corrupt the agent process or other tools. A tool that crashes produces an error result that the agent handles like any other error. A tool that attempts to access memory outside its allocation is terminated by the operating system. The blast radius of any tool failure is contained to that single tool invocation.
Credential Injection
Tools in the platform never contain credentials in their code. The OBO Authentication system ensures agents act with user identity, and credentials are injected into the tool subprocess as environment variables at launch time. The tool reads the credential from its environment, uses it for the specific operation, and the environment is destroyed when the subprocess exits.
Critically, credentials are scoped per tool per task. A database tool does not receive a master database password. It receives a scoped credential that grants access to the specific tables and operations its current task requires. A Slack tool does not receive a workspace admin token. It receives a token scoped to the specific channels and actions the current task specifies. The principle of least privilege is enforced at the credential level, not just the permission level.
Code Validation
When the OATS engine synthesizes a tool — generating code to accomplish a specific task — the generated code passes through a validation layer before execution. The DLP Scanner additionally inspects tool inputs and outputs for PII and sensitive data patterns in real time. This validation rejects known dangerous patterns:
- eval() and exec(): Arbitrary code execution functions are rejected. Tools must use structured operations, not dynamic code evaluation.
- os.system() and subprocess calls: Shell command execution from within a tool is blocked. Tools operate through defined APIs, not shell commands.
- __import__() and importlib: Dynamic module loading is rejected. All dependencies must be declared in the tool specification and loaded through the controlled sandbox environment.
- File system access outside allowed paths: Tools can only read and write within explicitly permitted directories. Path traversal attempts are detected and blocked.
This validation is not a substitute for process isolation — it is an additional layer. Defense in depth means that even if a code validation bypass were discovered, the process isolation boundary would still contain the impact. And even if process isolation were somehow breached, the scoped credentials would limit what an attacker could access.
Timeout Enforcement
Every tool execution in the platform has a timeout. The default is 30 seconds. If a tool has not completed within its timeout window, the subprocess is terminated and an error result is returned to the agent. The agent can then decide how to proceed — retry, use an alternative approach, or escalate to human review.
Timeouts are configurable per tool type. A database query tool might have a 10-second timeout. A data processing tool working on a large dataset might have a 120-second timeout. An API call tool might have a 5-second timeout. The point is that every tool has a bounded execution window. Runaway processes are impossible because the sandbox enforces the time boundary.
Network Access Control
Network access within the platform's tool sandboxes is policy-controlled using Kubernetes NetworkPolicy resources. By default, tools have no network access. To reach an external endpoint, the tool must be explicitly granted access to that specific endpoint in its configuration. A Slack tool can reach the Slack API. It cannot reach GitHub, internal databases, or arbitrary internet endpoints. A database tool can reach the database server. It cannot reach anything else.
This default-deny network policy prevents an entire class of attacks. Even if an attacker gains code execution within a tool sandbox, they cannot exfiltrate data to an external server, cannot pivot to other internal services, and cannot use the tool as a proxy for network scanning. The network boundary is enforced at the sandbox level, not the application level.
Comparison: Shared-Process vs. Sandboxed Execution
The practical difference between shared-process and sandboxed execution becomes clear in failure scenarios:
In a shared-process framework, a compromised tool can read credentials for every other tool, make network requests to any reachable endpoint, consume unlimited resources, and corrupt the agent's state. The blast radius is the entire agent and everything it has access to.
In the platform, a compromised tool can access only its own scoped credentials (issued through OBO Authentication for that specific user and task), reach only its whitelisted endpoints (enforced by K8s NetworkPolicy), consume only its allocated resources, and has no access to the agent process or other tools. The Audit System records the full execution trace with cryptographic hashing, making any tampering detectable. The blast radius is one tool invocation. That is not a marginal improvement — it is a categorical difference in security posture.
The Cost of Isolation
Process isolation is not free. Spawning subprocesses has overhead — typically tens of milliseconds per invocation, plus memory for each subprocess. In high-throughput systems, this adds up.
We made a deliberate architectural decision that this cost is acceptable. The alternative — running tools with shared permissions in a single process — saves milliseconds per invocation but creates security exposure that, when exploited, costs orders of magnitude more to remediate than the compute savings ever accumulated. The economics of isolation are heavily in favor of paying the performance cost, especially in enterprise environments where a single security incident involving customer data or production systems can cost millions in direct impact and regulatory penalties.
Sandboxed execution is not a feature. It is the minimum viable security model for production AI agents. Every framework that runs tools with shared permissions in a single process is making an implicit decision that development convenience is more important than production security. We disagree.