AWS Open-Sources Strands Box: An Agent Sandbox Whose Policies Remember What the Agent Did

The agent running in "YOLO mode" late at night might be yours

Picture a solo dev's late night: you tell your coding agent to "clean up the repo" and go make coffee. You come back to find it wiped the build directory along with the release artifacts next to it. Or worse — the agent, "helpfully" debugging, pasted your database password from .env into a commit message and pushed it to GitHub. The AWS Open Source Blog said it bluntly in the opening paragraph of its Strands Box announcement: coding assistants and agent harnesses are increasingly running in "YOLO mode," with every action auto-approved and no human review. Agents wander out of their working directory, run dangerous commands, or reach credentials they were never meant to see.

The traditional answer is a sandbox: draw a boundary around the agent. But AWS makes a point worth savoring — a boundary only answers "can it touch this," not "under what conditions, and to what extent." An on-call agent investigating a production incident may need to read logs and inspect infrastructure, but must never change them. Containers and microVMs offer strong isolation, but once an agent has a tool, the isolation layer can't govern what it does with it. That's the gap Strands Box, launched on October 7, is meant to fill: an open-source agent sandbox (Apache 2.0, written in Rust) that pairs OS-level isolation with a "temporal policy engine" called Dogwood.

Two layers: isolation is the floor, policy is the brain

Strands Box's design fits in one sentence: containment draws the hard boundary, policy enforces rules at interception points inside it. Containment uses OS-native mechanisms — currently macOS Seatbelt, which is why Box only supports Apple-silicon Macs for now, with Linux support on the roadmap. Within that hard boundary, the real action happens at four enforcement points: a network egress gateway (a proxy that all outbound traffic passes through), a Shell interpreter (Strands Shell), a Python interpreter (Monty, built on pydantic), and an MCP broker. The key detail: all four run in Box's own process, outside the sandbox, and the agent reaches them over a local socket as if they were ordinary bash, python3, and MCP commands.

The four enforcement points share one event vocabulary and one shared history. Whether the agent reads a file with a shell command or a Python script, it's reported as the same fs:read event; whether it makes an HTTP request with curl or Python, it's an http:request event. So you can write a rule like: "after the agent reads a file from the customer-data directory, block all further outbound HTTP requests" — without caring which tool did the reading. That's the essential difference between semantic enforcement and traditional syscall-watching sandboxes: rules are written in terms of the files and operations you actually care about, not opaque syscalls.

Configuring a Box takes just two files: box.toml describes the environment (what command the agent runs, its working directory, direct filesystem grants, available tools, MCP servers, credential bindings), and policy.dw holds the Dogwood rules. The rule syntax borrows from Cedar: permit or forbid, with when conditions. Two design choices are especially friendly to independent developers: default-deny — anything without a matching permit rule is blocked, and forbid overrides permit; and harness-agnosticism — agents built with Strands, LangChain, or the Claude Agent SDK can all run in the same box, and the same box.toml and policy.dw work across agent applications. AWS also shipped a Policy Authoring agent skill — your agent learns to write Dogwood policies and install them in your Box. Fighting magic with magic.

Temporal policies: rules that finally "remember" what the agent did

This is the genuinely new part. Traditional policy engines judge one request at a time; Dogwood's temporal operators let authorization decisions depend on what the agent has already done, the order of actions, and counts accumulated over time. The official blog walks through three escalating examples, each worth unpacking.

The first example has the most vibe-coding flavor: "after the agent reads a file from the customer-data directory, deny its subsequent outbound network requests." Translated into a solo dev's daily life: "after the agent reads .env, id_rsa, or the customer-data directory, immediately block all outbound HTTP." Implementing "read A, then never do B" used to require hand-rolled glue code maintaining state; now it's a declarative rule, and the engine keeps the state for you.

The second example is rate limiting: an on-call agent may post progress updates to the incident Slack channel, but no more than three times every 10 minutes. The blog even prints the timeline: posts at 10:00, 10:03, and 10:05 are all allowed, the fourth at 10:06 is denied, the agent keeps pulling logs at 10:07 unaffected, and posting works again at 10:11 once the window resets. Denials aren't silent — the gateway returns HTTP 403 with the rule's @id and @description in the body (e.g., "Slack posts capped at three per 10 minutes, wait before posting again"), so the agent can decide to wait instead of retrying furiously. A subtle design choice: only successful posts returning 200 count toward the cap; refused attempts don't. The rule binds on the ::response event, not the ::request event — otherwise one false positive would eat your quota.

The third example is deletion protection: when the agent runs rm -rf build/, the Shell interpreter raises an fs:delete decision for every file it would remove, so a forbid rule stops it before anything is deleted, while normal edits inside the workspace sail through. The rule author sees "file + operation," not "it ran a shell command" — and that's exactly what a harness's built-in permission prompt can only see, which is why AWS argues you can't rely on harness permissions: the harness sees which tool was called, not which files the command will touch or which hosts it will reach.

My take: temporal policies move agent security from "static allowlists" to "behavioral contracts." A static allowlist answers "can it reach this domain"; a behavioral contract answers "having already read sensitive files, can it still reach it." For a developer maintaining several side projects alone, that means rules that finally match intuition: no networking after reading secrets, list-before-delete, no more than N paid-API calls per hour. Rules like these were previously either inexpressible or relied on the agent "behaving itself" — and a security rule that depends on the agent's good manners is no rule at all.

Credential injection: the agent never sees a real secret, ever

The other feature that made me think "finally, someone built this" is credential injection at the egress gateway. The agent only ever holds a placeholder token; the gateway swaps in the real secret before forwarding a permitted request — supporting Bearer tokens, custom headers, HTTP Basic, query parameters, and AWS SigV4 (the gateway signs with host credentials outside the agent's environment). Real secrets never enter the agent's environment.

The practical meaning for solo devs is direct: no more mounting .env into the agent's workspace. Even if the agent "helpfully" prints secrets to a log, all it can print is the placeholder; even if a prompt injection hijacks one of its tool calls and tries to exfiltrate the key, there's nothing real to steal at the gateway layer. That's far more reliable than "telling the agent not to leak secrets" — once a security rule depends on the agent's cooperation, it stops being a rule.

Putting it on the map: Copilot's sandbox, Arcjet, and containers

VibeFix covered GitHub Copilot's local sandboxing back in September: a built-in, ready-to-use isolated environment that's friendly to Copilot users. But it's part of a closed platform — rules aren't programmable or portable, and switching harnesses means starting over. Strands Box reads as the "open-source + programmable-policy" evolution of the same idea: harness-agnostic, Rust, Apache 2.0 — you can self-host and modify it today.

The other reference point is commercial runtime-security products like Arcjet: delivered as an API/service with bot protection and rate limiting, billed by usage, and worry-free for people who don't want to operate anything. Strands Box is the self-hostable open alternative on that spectrum — data never leaves your machine, you write your own rules, no usage bill, but you do the setup and maintenance yourself. My view: it's not either/or. Arcjet fits "protecting a live service from external attackers"; Strands Box fits "protecting your machine from your own agent." The scenarios barely overlap.

As for "why not just Docker the agent," the official blog answers head-on: a separate guest OS means another environment to provision and maintain, plus the problem of how to expose local files and tools into it. More fundamentally, the isolation mechanism only answers "where the boundary is," not "how to govern inside it." AWS's bet on the sweet spot: OS-level containment for the hard boundary, plus policy enforcement at the interception points where the agent's actions try to cross it. I largely buy this — for an individual developer, maintaining a whole second environment just to babysit an agent is a real deterrent.

Cold water: can you actually use it today?

Limitations first, so you don't clone it in excitement and come back angry. One: platform. Currently Apple-silicon Macs only (macOS 15+); Linux support is "in progress"; Windows isn't mentioned. The repo was created on October 2 and has 308 stars — early developer preview. Two: the getting-started bar isn't trivial. Beyond the Mac, you need Node.js 22.21+ from Homebrew and access to Claude Opus 5 on Bedrock in us-west-2 — that last one is a non-starter for many developers outside AWS's orbit, though it's just the model the official example uses; the harness-agnostic design means you can theoretically swap in another model. Three: Dogwood is a new language to learn; the Policy Authoring skill at least covers your back by letting the agent teach you.

The roadmap, at least, is concrete: expand OS support, a one-shot CLI that auto-detects your installed harnesses and generates box.toml plus a baseline policy, bringing Box to deployed agents (policies ship with the agent to Bedrock AgentCore, ECS, or Kubernetes as part of the deployment artifact), and liveness for Dogwood — today it can only express "must not happen" (safety); tomorrow it should express "must eventually happen" (liveness) and detect when agents fall short. If that last one lands, even an agent slacking off could get caught by policy. Now that would be interesting.

Getting-started advice for independent developers: Mac users can curl the official download.sh to grab the binaries today, then start your local coding agent with three rules — no networking after reading .env or key files, no deleting anything outside the home directory, outbound traffic limited to the model API plus a few named domains. Run those three rules for a week; watching one live 403 interception builds more intuition than reading ten docs. Keep policy.dw in version control and reuse it on every new machine.

The one-line verdict

Strands Box's real novelty isn't "yet another sandbox" — it's the first time "time" has been written into agent security policy: rules can decide based on what the agent already did. Open source, Rust, Apache 2.0, harness-agnostic — individual developers can self-host and hack on it today. It's early (macOS-only, developer preview), but the direction is right: as agents grow more autonomous, the rules governing them must evolve from static allowlists to behavioral contracts. Box your agent first, then talk about trust — in that order.