Strands Box: An Open-Source Agent Sandbox That Combines OS Isolation With "Semantic Policies" and Decides by Earlier Actions

strands-agents/box is an open-source project from the Strands Agents team, described as "an open source sandbox engine for AI agents". The repository is written in Rust under the Apache-2.0 license. It was created on October 2, 2026, last pushed on October 12, and has about 393 stars and 19 forks at the time of writing. The question it answers is practical. When an agent can run commands, read and write files, reach the network and call outside tools, how do you turn "what it may do" from a line in a prompt into a boundary that a program enforces? The project does not tie itself to one agent. You pick the program or binary to run, set its access in box.toml and write its policies in policy.dw.

The design has two layers. The first is OS isolation. Direct access grants in box.toml, such as which directories are readable and which programs can start, are enforced by the host operating system. The second is "semantic policy" in a policy language called Dogwood, which has only two rule types, permit and forbid. Operations that the policy engine checks are denied by default, a matching permit must allow them, and a matching forbid overrides that permission. What is interesting is where the pieces sit. Strands Shell, Monty for Python, the egress gateway and the MCP broker each send the operations they handle to the embedded Dogwood Local Engine. That engine runs in Box's own process, outside the agent's sandbox. The agent can send requests to Box's interpreters, but external programs and local MCP servers cannot, and the network traffic of external programs goes through Box's gateway by default.

This layout gives several concrete abilities. First, the interpreters and gateways share one event history, so rules can use earlier actions and elapsed time. The README's example is that a file read through Shell or Python can cause the gateway to deny a later outbound HTTP request, which is closer to a real data-leak case than a simple list of allowed addresses. Second, the egress gateway checks connections and HTTP requests, including method and path, and the MCP broker checks configured tool calls and their arguments. Third, the gateway can authenticate permitted requests with configured API credentials or AWS SigV4 signing, so the agent does not receive the underlying secrets. Fourth, every policy decision is recorded in OTLP JSON, by default in private/telemetry/records.jsonl under the box directory, which helps later audit.

Before you use it, read the limits the project states. It is a preview and supports only local execution on macOS with Apple silicon. The guide asks for macOS 15 or later, Node.js 22.21 or later from Homebrew and access to Claude Opus 5 on Amazon Bedrock in us-west-2. The download script checks the release checksum and unpacks the binaries into ./box-core without changing PATH or system directories. Next, the README says that direct filesystem grants in box.toml are enforced by the OS and produce no individual Dogwood decisions. To apply a policy to file operations, use the interpreters and keep those files out of the agent's direct grants. Finally, all of this comes from the project's own description. We did not run it, and we saw no independent security audit or penetration test.

How to judge it? For teams that build agents, it offers a clear division of labor: the operating system decides what can be touched, the policy engine decides under what conditions an action is allowed, and both sit outside the agent. That is much more reliable than writing "please do not leak the password" in a prompt, and finer than a sandbox with only a network allow-list. The cost is learning a new policy language and routing files, network and tool calls through Box. It does not run on Linux or Windows yet. If your agent touches sensitive data, try the bundled Strands Python SDK example first, read the decision records, and then decide if changing how you run agents is worth it.