AWS releases an AI-agent sandbox that checks actions against what happened before

AWS has released Strands Box, a free, open-source sandbox that can check an AI agent’s next action against its earlier activity. Available in developer preview for Apple silicon Macs, it combines operating-system isolation with rules governing how agents use tools—not just which files or services they can reach.

Marc Brooker introduced the release in an October 7 post, Strands Box: The Big Picture. Box works with any model or agent framework, rather than requiring AWS’s own agent SDK. Linux support is planned. The local tool targets agents that run commands, generate code and call services while working toward a goal.

Four checkpoints, one action history

Box uses macOS Seatbelt, an operating-system mechanism, to enforce the sandbox boundary. Its design channels interactions through a separate policy layer. That layer can inspect commands and requests at a level where their meaning is visible, rather than relying only on broad permissions to access a file path or network destination.

• A shell interpreter checks shell commands.
• A Python interpreter checks Python code generated by the agent.
• A broker checks calls to Model Context Protocol servers, which connect agents to tools.
• A network gateway checks outbound traffic and handles configured credentials.

Each checkpoint asks the Dogwood Local Engine whether to permit an action. Actions it checks are denied unless a rule allows them. All four checkpoints contribute to a shared event history, so a decision can depend on activity through another tool. Permission is not simply a fixed list checked afresh at every step.

A file read can change network permission

A rule can block outbound HTTP requests after an agent reads a file in a customer-data directory. The history can connect that read to the later request whether shell commands or Python performed the reading. This is the distinction Box draws between isolating an agent’s environment and controlling the sequence of actions inside it.

Brooker illustrates rules that allow a code push only after tests pass, or cap payment-API spending at $100 a day. He cautions that his sample code-push policy is incomplete: switching branches could undermine its promise. The policy must account for the relevant sequence, not merely recognize that a successful test happened earlier.

An AWS walkthrough gives an incident-response agent three Slack posts within 10 minutes. A fourth receives an HTTP 403 response naming the rule, telling the agent why it must wait. For configured API keys, the gateway also replaces placeholder tokens with real credentials on outbound requests; dumping the agent’s environment reveals those placeholders instead.

But the reality is that more code means more opportunity for bugs, and in this space, bugs could mean bypassed policy.

Marc Brooker, in his October 7 Strands Box design post

Direct file grants leave a policy blind spot

Files granted directly in box.toml, Box’s configuration file, remain fenced by the operating system. But their reads and writes do not enter the policy engine or its history. To apply a history-aware rule to a file, developers must leave it off the direct-grant list and route access through the interpreters.

The richer controls also increase the trusted computing base—the code that must work correctly for security to hold. Brooker includes interpreters and protocol interceptors in that set. AWS says it built this code in Rust and invested in testing, fuzzing and validation, while acknowledging that bugs could still bypass policy.

Writing the rules remains another hurdle. Brooker acknowledges that Dogwood policies can be difficult to read and write, and says easier authoring is an investment priority. AWS ships a policy-authoring skill; a command-line tool to detect installed agent harnesses and generate starter configuration and baseline policy remains on the roadmap, according to Help Net Security.