News reporting
AWS Strands Box makes agent permissions depend on earlier actions
The sandbox preview can apply history-aware rules to agent tools. Direct file access sits outside that policy history, a boundary builders need to understand.
By Agent Report Editorial
Editorial review · · 3 min read
Source-based reportingWritten and source-checked with Codex. AWS announced the preview October 7; documentation checked October 11, 2026. No hands-on sandbox or enforcement tests were performed. Grok supplied the separately attributed AI commentary on October 11.Updated
An agent allowed to read a file and contact a service may still need to be stopped from doing those things in that order. AWS is putting that distinction into the permission system with Strands Box, a developer-preview sandbox announced October 7.
The preview combines operating-system isolation with Dogwood, a policy engine that can consult earlier actions before allowing the next one. For builders, the useful question is whether the policy sees every operation on which that decision depends.
What a history-aware rule can do
AWS illustrates the idea with a Slack limit: count three HTTP 200 responses from the posting endpoint in ten minutes, then refuse another request. That counts recorded responses rather than attempts. An HTTP 200 is the example’s technical condition; it does not establish that the post was useful.
That distinction matters for agents that retry. Imagine a customer-service assistant repeating a send after an ambiguous timeout. A task instruction to “try again” does not resolve whether the previous action happened. Our assessment: a permission history can help express a limit, but the application still needs a reliable definition of success and a way to reconcile uncertain outcomes.
AWS also describes a gateway that supplies real credentials outside the agent process. This separates an agent's ability to request an operation from possession of the secret used to authenticate it.
The file-access boundary is consequential
The project README distinguishes mediated shell, Python, network and MCP operations from direct filesystem grants. Mediated operations use Dogwood. Direct file access allowed by the sandbox configuration is enforced by the operating system, without an individual Dogwood decision for each read or write.
Our reading of that boundary: a policy cannot rely on a file-read event that never enters its history. Review the harness's built-in file tools as well as the tools deliberately routed through Box. A rule that looks complete in isolation may cover only one of several ways the agent can obtain the same information.
The README currently lists macOS on Apple silicon, with Linux planned. That makes this a local preview to investigate, rather than an available Linux production control to assume into an architecture.
A useful first evaluation
Start with disposable data and one concrete rule: after access to a restricted document through a mediated tool, deny a specified external operation. Repeat the task using every file-access route the harness exposes. Preserve the configuration and the resulting allow/deny events together.
Then test a legitimate retry, a failed request and an interrupted session. Those cases reveal whether the history matches the meaning of the business rule. They are proposed tests; Agent Report has not run them or verified resistance to sandbox escape.
A small team should require an explanation for both a permitted action and a refusal before giving this control responsibility for customer data. The promising change here is that permission can depend on what already happened. The deployment work is making sure “what happened” is actually recorded.
For the ongoing operational work, see our guide to maintaining a small-business AI agent.