Let the agent run at full speed while the OS, not the model, decides what it can touch.
Auto-mode is fast because you stop reviewing every tool call. That’s also the problem: every command the agent runs executes with your permissions, on your machine, with your network. One bad edit to a config file or one unexpected curl and you’re doing forensics instead of shipping.
Kilo Sandbox puts OS-level confinement around agent tool execution. The agent keeps its velocity. The blast radius doesn’t.
Smarter models, harder boundaries #
OpenAI shipped GPT-5.6 Sol last week and calls it its strongest cybersecurity model yet. Every frontier release gets better at exactly the things that make auto-mode risky: multi-step planning, tool use, long-horizon execution without a human in the loop.
It also changes the math in mixed-model setups. In Kilo you can run a frontier orchestrator that delegates to cheaper subtask models, or have one model review another’s diffs. In those pipelines, one model’s output is another model’s instructions. A sufficiently capable model can talk a smaller one into running a command it would never have proposed itself. So can a poisoned README that either of them reads along the way.
Guardrails that live inside a model are only as strong as that model’s judgment, and the judgment gap between a frontier model and a small subtask model is exactly what every capability jump widens. The sandbox sits below all of it. Seatbelt and seccomp don’t read prompts and can’t be persuaded. Whichever model is driving — Sol, a small open-weight model, or five of them handing work to each other — a write lands inside the workspace or it doesn’t land at all.
Confinement, not a container #
Sandbox is OS-native process confinement applied to every tool the agent executes — including tools that already passed permission checks. Permissions decide whether a tool runs. Sandbox decides what it can touch while running.
Two things get confined:
Filesystem writes. The agent can read anything, but it can only write inside your workspace and paths you’ve explicitly allowed. .git is always read-only.Network egress (optional). In network-deny mode, direct sockets are blocked. Outbound HTTP/HTTPS goes through an authenticated loopback proxy that inspects the TLS SNI against your allowlist before tunneling anything.
Reads are never restricted. The agent still sees your whole codebase, your docs, your dependencies. It just can’t mutate things outside the lines or phone hosts you didn’t approve.
This demo uses a project with an injected prompt instructing the agent to POST a secret to an external server.
How it works on each OS #
macOS: Seatbelt, via sandbox-exec. The same confinement mechanism macOS uses for its own system services.Linux: Bubblewrap for filesystem isolation, seccomp for syscall filtering, and a network namespace for egress control. Requires user namespaces.Windows: not supported yet. If sandbox is enabled on Windows, execution fails closed. There’s no silent fallback to unrestricted mode.
What gets blocked #
With sandbox on, the agent can’t:
Write outside the workspace or your configured writable_paths
Write to .git, ever. Your history stays intact even inside the workspace
Open direct network sockets
Reach HTTP/HTTPS hosts that aren’t on your allowlist
Call MCP tools, codebase_search, or lsp in network-deny mode. These make opaque network calls the proxy can’t inspect, so they’re off
Read sensitive environment variables like KILO_CONFIG and KILO_SERVER_PASSWORD
A few features are unavailable while sandbox is active: interactive terminals, notebooks, and starting or restarting background processes. These need capabilities the confinement model can’t currently express, so they’re disabled rather than half-secured.
Configure it globally or per project #
It goes in kilo.jsonc, the same config the CLI and VS Code extension read. Global config lives at ~/.config/kilo/kilo.jsonc and applies to all projects; project config is kilo.jsonc in the project root or .kilo/kilo.jsonc, with the .kilo/ version taking priority if both exist.
{
“$schema”: “https://app.kilo.ai/config.json”,
“sandbox”: {
“enabled”: true,
“network”: “deny”,
` “allowed_hosts”: [”registry.npmjs.org”, “pypi.org”],`
` “writable_paths”: [”~/scratch/build-cache”]`
}
}
You can also toggle per session: the lock button in the VS Code prompt bar, or /sandbox in the CLI.
Tested the escape routes #
Network deny: a listener run with nc during a sandboxed session shows0 accepted connections. Direct sockets don’t get through.** Filesystem confinement:Seatbelt tests confirm writes outside the workspace fail, and writes to .git fail even though it’s inside the workspace. Symlink races:**a TOCTOU test tries swapping a path for a symlink between check and write. The write still lands inside the confinement boundary.
What it doesn’t do #
Sandbox reduces blast radius. It’s not a complete security boundary, and we’d rather you know the edges:
Not a privacy boundary. Reads are unrestricted by design. The model sees your code, and anything the model sees can leave through its responses. Sandbox doesn’t stop exfiltration via prompts.Not a firewall. The proxy inspects SNI for HTTP/HTTPS. SSH, SOCKS, and CIDR-based rules aren’t supported. There’s a known NAT64 edge case.MCP and plugin trust is still your call. In network-allow mode, tools you’ve connected can do what they do.
Sandbox is for the everyday case: letting auto-mode move fast on your machine without betting the machine on it.
Where you can use it today #
tab in settings, plus the lock toggle in the prompt barVS Code: Sandboxing/sandboxCLI:inherits the stricter of the applicable policiesAgent Manager:
Not yet available in Cloud sessions or the JetBrains extension.