AWS Releases Strands Box, an Open-Source Sandbox That Blocks Agents Based on What They've Already Done

What sets AWS’s Strands Box apart is that it remembers what an agent has already done and uses that to block what comes next.

AWS released Strands Box, an open-source sandbox that limits what AI agents can do, as a developer preview on October 7, under the Apache 2.0 license. A sandbox is a safety box that holds an agent in and restricts what it can do. It is a preview, so the environments it works in are still narrow, but it shows the direction safeguards are taking for developers who build coding and DevOps agents.

What it does

OS-level isolation plus a policy engine. It isolates the agent at the operating-system level and sends the shell commands, Python scripts, network requests and MCP tool calls the agent runs through a policy engine (Dogwood). The policy engine decides whether to allow or block each action. MCP is a standard that lets AI use outside tools.
Rules that remember prior actions. Containers and microVMs shut an agent in but have no memory of what it has done. Strands Box applies rules based on what the agent has already done.
Example rules. Let the agent post to Slack, but only three times every ten minutes. Block outbound web requests once the agent has read a file from a customer-data folder. Capping API spend is also reportedly possible.

Can you use it now

Supported environment. The preview supports only Apple silicon Macs running macOS 15 or later.
Roadmap. Linux support is reportedly in development and Windows is under consideration, but there are no release dates. Deployment targets such as Bedrock AgentCore, ECS and Kubernetes are planned with no set timing.
Framework. Some reports describe it alongside the Strands Agents ecosystem, while one analysis says it aims to work independently of any particular agent framework.

The limits are clear too

Reports say AWS itself is open about the gaps.

Some built-in tool actions reportedly bypass the policy engine’s checks, and trusted interpreters run outside the sandbox.
The tool does not replace IAM (permission management), monitoring, or human oversight. It is better seen as a useful restraint than full containment.

Claims we could not confirm

We could not confirm the phrases “runaway agent behavior in enterprise environments” or “real-time monitoring” in official descriptions. What is confirmed is isolation and rules based on prior actions.
“An agent-guardrails framework has been made official” is an overstatement. It is currently an open-source developer preview with limited environments.

What could change for developers

What follows is our estimate and advice based on the reports.

Writing “don’t do that” in a prompt isn’t enough. Blocking actions at the system level, so the agent truly can’t take them, may become the norm.
Rules can be designed around counts and order. Stateful rules, such as rate limits or blocking outside traffic after sensitive data is read, are especially useful for coding and DevOps agents.
Treat it as experimental for now. A Mac-only preview is hard to use for server deployment. In production, keep existing safeguards such as IAM, logs and human approval.
Check the bypass paths. Assume there are paths the tool cannot block (built-in tools, trusted interpreters), and put a separate approval step on important operations.

What to watch

The schedule for Linux and Windows support and cloud deployment targets, documentation and examples for the policy rule language (Dogwood), and how bypass cases get reported and fixed.