I tried out the new "/sandbox" feature of Kiro CLI, including communication restrictions between scripts and local MCP servers
This page has been translated by machine translation. View original
Introduction
Kiro CLI 2.31.0, released on 2026-10-13, added /sandbox and /autonomous.
According to the official documentation, the sandbox targets shell commands executed by the agent and their child processes. When mcpSandboxing is enabled, stdio MCP servers are also included. The communication destinations for these can be restricted using the networkAccess setting.
This time, I tried it on a Linux environment (bubblewrap 0.12.0, Kiro CLI 2.31.0, V3 session), using package installation and local MCP server calls as examples.
Launching with sandbox.json in place
On Linux, bubblewrap's bwrap is required. Kiro CLI is launched with kiro-cli --v3.
When you write the following content to the project's .kiro/settings/sandbox.json and launch Kiro CLI, "sandboxed" appears in the status display.
{
"enabled": true,
"networkAccess": "DEFAULT_BLOCKED",
"mcpSandboxing": false
}
You can specify DEFAULT_BLOCKED, COMMON_DEPENDENCIES, or DEFAULT_ALLOWED for networkAccess. DEFAULT_BLOCKED is the default value and blocks communication to any host that has not been explicitly allowed.
Running /sandbox opens a settings screen, but this time I manually created sandbox.json and restarted Kiro CLI each time I changed the settings.
Controlling communications from install scripts
I created a dummy package. During installation, it attempts to write to HOME and send data to a process listening on 127.0.0.1:18081. I had the Kiro CLI agent run the following command from a local directory.
pip install --no-build-isolation --no-deps --target <destination> <package directory>
Without the sandbox, both the write and the send succeeded.
21:52:09 STEP2 write outside cwd (HOME): ok
21:52:09 STEP3 send to 127.0.0.1:18081: ok
When the sandbox was enabled with networkAccess set to DEFAULT_BLOCKED, both were blocked.
21:53:50 STEP2 write outside cwd (HOME): FAIL OSError
21:53:50 STEP3 send to 127.0.0.1:18081: FAIL ConnectionRefusedError
The dummy package itself, installed from a local directory, succeeded in installation under any setting.
When networkAccess was set to DEFAULT_ALLOWED, the send succeeded, while the write was blocked just as it was with DEFAULT_BLOCKED.
Controlling communications from a local MCP server
I prepared a dummy stdio MCP server written using only the standard library. When a tool is called, it attempts to write to HOME, connect to 127.0.0.1:18080, and perform name resolution, then returns the results. I registered it in the project's .kiro/settings/mcp.json as follows.
{
"mcpServers": {
"probe": {
"command": "python3",
"args": ["/tmp/kiro-sandbox-probe/work/mcp_probe.py"]
}
}
}
When mcpSandboxing was false, all three operations — writing, connecting, and name resolution — succeeded even with the sandbox enabled. Next, I changed mcpSandboxing to true in sandbox.json and restarted Kiro CLI.
{
"enabled": true,
"networkAccess": "DEFAULT_BLOCKED",
- "mcpSandboxing": false
+ "mcpSandboxing": true
}
As a result, all three were blocked.
The sandbox remains active even with /autonomous on
When I ran /autonomous on without a sandbox.json in place, both "Autonomous" and "sandboxed" appeared in the status display, and the sandbox became active. When I had curl run in this state, no approval prompt appeared, and external communications were blocked in the same way as with DEFAULT_BLOCKED.
https://example.com http=000 curl_exit=6 curl: (6) Could not resolve host: example.com
https://pypi.org/simple/ http=000 curl_exit=6 curl: (6) Could not resolve host: pypi.org
Allowing communications
Using COMMON_DEPENDENCIES on Linux requires socat. In an environment where socat was not installed, no communication destinations were reachable even when set to COMMON_DEPENDENCIES. So I placed socat 1.8.1.1 under HOME, added it to PATH, set networkAccess to COMMON_DEPENDENCIES, and ran curl.
https://example.com http=000 curl_exit=56 curl: (56) CONNECT tunnel failed, response 403
https://github.com http=200 curl_exit=0
https://pypi.org/simple/ http=200 curl_exit=0
https://registry.npmjs.org/ http=200 curl_exit=0
Individual hosts can be allowed using sandbox_network rules. According to the official documentation, socat is also required when using these allow rules with DEFAULT_BLOCKED. The following is a sample from the official documentation.
# ~/.kiro/settings/permissions.yaml
rules:
- capability: sandbox_network
match: ['packages.internal.example.com']
effect: allow
Summary
Kiro CLI now supports sandboxing and can be used as a means of restricting communication destinations.
When evaluating new agents or tools on Kiro CLI and you want to suppress unexpected external communications, you can use the sandbox. Choose DEFAULT_BLOCKED if no external communication is needed at all, or COMMON_DEPENDENCIES if you want to allow common dependency destinations such as GitHub and package registries. In either case, you can add specific communication destinations using sandbox_network rules.
By instructing the agent on policies through steering files (.kiro/steering/) and then restricting execution itself with the sandbox, you can help reduce risk. Give it a try.
