AWS's Strands Box routes agent actions through a policy engine that remembers them

Strands Box makes that history usable with a single event format. According to the dev.to post, a file read through a shell command reports as the same kind of event as a file read from a Python script ^[10]. An HTTP request from curl and one from generated Python also report the same way ^[10]. Without that, a rule would need one clause per interpreter.

The post's cross-tool example depends on this. "Block outbound HTTP after the agent has read from the customer-data directory" spans two tools ^[7]. The read goes through the filesystem and the request goes through the network, so a sandbox sees two unrelated operations ^[7]. With one event shape, the policy engine can match the earlier read in its history against the later request.

For that rule to hold, every route to the directory has to emit the read event. The post says the four interception points cover "what a coding agent actually does all day" ^[15]. We would test that first with a program launched from the shell that opens the file on its own.

The push rule has a different shape. The post describes "only if the tests are passing" as a rule about "the state of the world at the moment of the action" ^[4]. In principle a shared history makes it expressible, as long as a passing test run is one of the recorded events. The post does not show how a test result gets into that history.

We think the split is right for coding agents. The kernel boundary holds whether or not the agent behaves. Rules like three incident-channel posts per ten minutes ^[3] run in user space, where the protocol and language context they need is available ^[8]. The post keeps the sandbox in the design; it says sandboxes are good and that teams should have one ^[16].

This account of Strands Box comes from that single dev.to post, which argues the gap is not vendor-specific ^[13]. The post sums it up in one line: isolation answers what an agent can reach, and policy answers what it may do ^[11].