Every agent runs in a sandbox it cannot escape
Autonomous agents execute code and call the outside world on your behalf. The runtime isolating that execution is the difference between a demo and something your security team will actually sign off on — here's exactly how RunAIAgents contains it.
JS sandbox limits
64MB memory / 5s timeout
Python isolation
Fresh interpreter, every run
Outbound egress
Pinned to a validated IP
Agent turns
8 default, 32 hard max
JavaScript never leaves a WASM isolate
The code_execution tool's JS runtime runs inside QuickJS compiled to WebAssembly — not a spawned process, and not a container sharing the host kernel. The isolate has no access to the host filesystem, network, process, or environment; only the input and secrets you explicitly inject cross the boundary, and only as data, never as code. A wall-clock interrupt hard-stops execution at 5 seconds, and a 64MB memory ceiling caps runaway allocation. There's no container to break out of, because there is no container.
Python gets a disposable interpreter, every run
Python code_execution runs on real CPython — compiled to WebAssembly via Pyodide — inside a fresh worker that is spawned for that one call and terminated immediately after, success, failure, or timeout. Pyodide's js/pyodide_js bridge is stripped before any user code runs, so a script that tries import js fails outright instead of reaching into the host process. Nothing about the interpreter — loaded modules, trace hooks, its in-WASM filesystem — survives from one run to the next, by construction, not by convention.
Outbound calls are pinned to a validated IP
Every outbound connection an agent makes — an api_call tool, an MCP server, a webhook delivery — resolves and validates the destination once, then connects to that exact IP through a pinned dispatcher. The DNS record is never re-resolved at connect time, which closes the classic DNS-rebinding race: a hostname can't pass validation as a public address and then swap to an internal one, like a cloud metadata endpoint, a moment later.
Destructive actions stop and wait for a human
Any tool call that mutates the outside world — a non-GET API call, a connector action, an MCP tool, a browser action — can be required to pause for approval. Turn on Safe Mode and every side-effecting tool is gated automatically: the run halts at an approval_required step instead of firing the call, and a dry run previews the same set of actions without a single request touching the wire.
Bounded steps, and a hard refuse-over-guess contract
Every run is capped at a fixed number of agent turns — 8 by default, never more than 32 — so a stuck loop can't run away and burn credits. Every system prompt also carries a standing instruction: never fabricate a tool result, never claim an action succeeded unless a tool confirmed it, and say so plainly instead of guessing when a task can't be completed with the tools available.
Why this is more than a compliance checkbox
Most agent platforms run generated code in a shared process or a bare container — one kernel away from every other tenant. RunAIAgents isolates code execution at the WASM boundary, pins every outbound connection to a validated IP, and gates anything destructive behind a human. That’s a sandbox model your security team can review line by line — not a promise you have to take on faith.