What changed this week that actually affects agent security decisions? → AWS released Strands Box, an open source sandbox for AI agents that combines operating-system isolation with a policy engine that can consider what the agent already did before approving the next action.
What’s the real search question engineers are asking behind this release? → How do we sandbox AI agents so they can run tools (shell, Python, network, APIs) in ‘YOLO mode’ without turning every run into a potential credential leak or destructive command?
Why isn’t container isolation enough for modern coding agents? → Containers and microVMs can limit what an agent can reach, but once a tool is inside the boundary, isolation doesn’t govern how the agent uses it.
What’s the central claim we’re making at Plavno? → Agent failures happen at the egress and orchestration boundary—so the right response is to make policy the only way out, and make policy stateful across tools.
Who should care right now? → CTOs and platform/security leads running coding assistants, incident-response agents, or automation bots that read files, run commands, execute generated code, and call external services.
Quick Answer: How to sandbox AI agents with stateful policy, not just isolation
If you want to run AI agents with real autonomy, you need a sandbox that enforces two things simultaneously: kernel-level isolation so the agent can’t wander the OS, and a deny-by-default policy layer that every outbound action must cross. Strands Box matters because it treats shell commands, Python execution, tool calls via MCP servers, and network traffic as governed exits with a shared event history, enabling rules like blocking outbound HTTP after reading customer data or allowing git push only after tests pass.
If your sandbox cannot correlate actions across shell, code execution, and network egress, it will fail in the exact scenarios that make AI agents dangerous.
AWS just moved the boundary: ‘the policy layer is the only way out’
The dominant signal is not that AWS shipped another sandbox; it’s that Strands Box is designed so the agent’s meaningful capabilities are funneled through policy checkpoints rather than trusting the agent once it’s inside a container. In practice, that reframes the engineering decision: instead of arguing about whether containers or microVMs are sufficient, we should ask whether every exit path—commands, code execution, tool protocols, and network—can be denied unless an explicit rule permits it.
- Engineering boundary shift: Isolation limits reach, but Strands Box focuses on governing behavior at exit points where damage actually happens.
- Stateful controls: A shared event history allows rules to depend on what the agent already did, not just what it wants to do next.
- Tool-agnostic enforcement: Shell, Python, MCP tool calls, and network traffic are all routed through checkpoints.
- Operational feedback loop: Denials can return a clear failure (such as an HTTP 403 naming the rule), which helps agents adapt rather than thrash.
The core claim: autonomy breaks at orchestration boundaries, so policy must own egress
We see a repeatable failure mode with coding assistants: the model isn’t the only risk surface. The orchestration layer is where reading files, running shell commands, executing generated Python, and calling APIs combine into higher-order behavior that neither containers nor ‘approve everything’ workflows can reliably constrain.
Our position at Plavno is that Strands Box gets the direction right: treat outbound actions as a controlled interface, and make rules stateful by logging all checkpoint events into one history. That design is more important than debating whether the isolation primitive is a container or a microVM, and it’s the same kind of thinking we apply when building production autonomy in AI agents development.
The agent runs inside a kernel-enforced sandbox (on macOS this uses Seatbelt) so the base OS boundary is real.
When the agent tries to act—via a shell command, Python execution, an MCP server tool call, or network traffic—the attempt is intercepted at a checkpoint.
Each checkpoint consults the Dogwood Local Engine, where actions are denied unless a rule explicitly permits them.
The checkpoint writes the attempt into shared event history, allowing later rules to condition on earlier behavior across tools.
Shared event history is the difference between ‘safe tools’ and safe workflows
Most teams try to secure agents by shrinking the filesystem view, locking down network, and hoping the agent won’t connect sensitive reads with risky outbound calls. Strands Box’s key operational idea is that all four checkpoints write to one shared event history, so a rule can span tools and time. That allows you to block outbound HTTP after the agent reads from a customer-data directory, even if the read happened in one tool path and the outbound call happens in another.
- Cross-tool data loss prevention: Block a network request after a sensitive file read, regardless of whether the read was triggered by a shell command or Python.
- CI-style gating for autonomy: Allow git push only after tests pass, treating ‘tests passed’ as a precondition recorded in history.
- Rate-limiting as policy: Let an incident-response agent post to Slack only three times in ten minutes and deny the fourth attempt.
- Budget boundaries for external APIs: Cap a payments API to $100 a day so even a ‘helpful’ agent can’t exceed a hard limit.
Stateful policy turns your sandbox into a behavior contract
Once rules can see history, you stop writing policies as static allowlists and start expressing intent: ‘you may do X only after Y’ and ‘after you touched Z, you may not do W.’ That’s closer to how real incidents happen in production, where the problem is rarely a single forbidden call and more often a sequence that becomes unsafe when combined.
- Auditability becomes actionable: A unified history is not just logging; it is the input to authorization decisions.
- Rules become composable: Preconditions like ‘tests passed’ or ‘read from customer-data directory’ can influence multiple later actions.
- Denials can be machine-readable: Returning an HTTP 403 naming the blocking rule allows the agent to adapt its plan.
- You can enforce tempo: Slack throttling illustrates that ‘too frequent’ can be as dangerous as ‘not permitted.’
Direct file grants create a blind spot you must design around
Strands Box has a sharp edge that matters for real systems: files you grant directly in box.toml are fenced by the OS, but reads and writes to those files do not go through the policy engine and do not land in the shared history. If we want a rule to govern access to a file, we have to avoid granting it directly and instead force access through the intercepted interpreters so policy can see it.
OS fencing can protect a directory, but it cannot support cross-tool rules if the policy engine never sees the read.
The four checkpoints are the product: shell, Python, MCP, and the network gateway
From an engineering perspective, Strands Box is less about ‘a sandbox’ and more about four enforcement choke points. The shell interpreter and Python interpreter are where a coding agent’s real power lives, because agents routinely translate natural-language goals into command lines and generated code. The broker for MCP servers matters because tool ecosystems are increasingly standardized around remote tool endpoints. And the network gateway is where data exfiltration, unauthorized API calls, and secret exposure typically occur.
MCP tool calls deserve the same scrutiny as shell commands
If your agent can call tools via MCP servers, you’re effectively letting it operate a growing set of capabilities whose safety properties you may not fully control. Treating MCP traffic as a checkpointed path—rather than ‘just another library call’—is what lets you apply the same deny-by-default policy posture to tool calls that you apply to outbound HTTP.
- Tooling sprawl becomes governable: The MCP broker checkpoint provides a single place to authorize tool calls.
- Policy becomes protocol-aware: Instead of trusting whatever an MCP server exposes, authorization can sit in front of it.
- Event history stays coherent: Tool calls land in the same timeline as shell and Python actions.
- Incident response becomes safer: An agent using Slack can be rate-limited by policy even when Slack posting is ‘just another tool.’
Secret handling through the gateway is more robust than hiding environment variables
The network gateway design in Strands Box addresses a common agent failure mode: once a credential is inside the agent’s environment, it can be printed, logged, copied, or used in the wrong context. Strands Box instead holds placeholder tokens for configured API keys and swaps in the real value only at the gateway when the request leaves. For AWS calls, the gateway signs requests, which implies the agent itself doesn’t need to hold raw AWS credentials in a form it can dump.
The trade-off security teams will debate: a bigger trusted computing base
Strands Box intentionally adds code in the enforcement path: interpreters and protocol interceptors that must be trusted. AWS acknowledges this directly: more code expands the trusted computing base, and bugs in that code could mean bypassed policy. They mitigate by building that code in Rust and investing in testing, fuzzing, and validation.
This is the right debate to have, but we think it’s often misframed. In agent systems, the alternative to an interceptor-heavy design is usually not ‘less code overall,’ it’s ‘less code you can reason about centrally.’ A single gateway and a single policy engine can be easier to audit than many scattered permissions, even if the gateway itself is complex.
- Centralize enforcement intentionally: Accept some complexity in exchange for having one place to reason about outbound actions.
- Assume bypass attempts will happen: Treat interpreters and interceptors as high-value components that need deep testing and review.
- Make failure modes visible: Denials that name rules are operationally safer than silent drops.
- Constrain what ‘direct access’ means: Avoid direct file grants when governance depends on policy history.
Dogwood’s deny-by-default posture makes policy authoring your limiting factor
Strands Box relies on the Dogwood Local Engine, and its core security posture is clear: anything the engine checks is denied unless a rule permits it. That’s the right default for autonomy, but it shifts the workload from ‘set up the sandbox’ to ‘author and maintain policies that reflect your business constraints.’ AWS also notes that Dogwood policies can be hard to read and write, and that advanced coding agents can already author them well; AWS ships a policy-authoring skill to help.
| Control approach | What it optimizes | Where it typically fails |
|---|---|---|
| Deny-by-default policy on exits (Dogwood model) | Explicit intent and least privilege for actions | Policy gaps and authoring overhead when workflows change |
| Isolation-only (containers, microVMs) | Limiting what the agent can reach | Misuse of allowed tools inside the boundary |
| Human approval for every action (‘YOLO mode’ with approval) | Short-term comfort and perceived control | Scale, fatigue, and inconsistent enforcement across runs |
Where Strands Box sits in the agent stack you already operate
Strands Box is in developer preview, runs on Macs with Apple silicon, and has Linux support planned, so the immediate evaluation is easiest for teams already building and testing on macOS. Conceptually, it wraps the same surfaces your agents already use: filesystem access, shell commands, Python execution, tool calls, and network egress. If your current agent setup relies on ‘approve everything’ to move fast, this is a concrete path to keep velocity while shifting control into enforceable policy, which is the foundation of scalable AI automation.
The evaluation question isn’t ‘can it sandbox an agent?’; it’s ‘can it block the next action because of the last action?’
How we pressure-test agent sandboxes at Plavno before production access
At Plavno, we treat agent sandboxes as production security components, not developer conveniences. The critical test is whether we can express real operational constraints—data boundaries, change-control gates, and external API budgets—as policies that the agent cannot bypass by switching tools. That’s why we look for architectures that route shell, code execution, tool calls, and network through enforceable checkpoints with an auditable history, the same lens we use in AI consulting engagements when teams need autonomy without surprises.
- Sequence-based abuse cases: We model ‘read then exfiltrate’ and ‘generate then execute’ flows, not single actions in isolation.
- Denial ergonomics: We validate that denials are explicit enough that an agent can recover (for example, an HTTP 403 that names the blocking rule).
- Secret exposure paths: We test whether the agent can ever hold real API keys versus placeholders that only become real at egress.
- Policy observability: We require a shared event history that supports incident review and policy refinement.
How to decide this quarter: choose your boundary, then write the smallest useful policy
Most teams evaluating sandboxing for AI agents get trapped in a false choice between ‘lock everything down’ and ‘move fast.’ Strands Box suggests a third option: keep agents autonomous inside a constrained environment, but make the policy layer the only way out, and make that policy context-aware using event history. The immediate decision is whether your risk is primarily reach (wandering the OS) or behavior (misusing allowed tools); if you’re running coding assistants, behavior is usually the bigger issue.
The pragmatic path is to start with rules that mirror your existing operational guardrails. If your organization already requires tests before pushing code, encode that. If finance already sets spending limits, encode that as API caps. If incident response already has communication protocols, encode rate limits for Slack posting. You’re not inventing new controls—you’re making existing controls machine-enforceable for agents.
| If your agent can do this | The control you actually need | Why isolation alone won’t save you |
|---|---|---|
| Read files and make outbound HTTP requests | A cross-tool rule that blocks HTTP after sensitive reads | The exfiltration happens through allowed network paths |
| Run shell commands and execute generated Python | Intercepted execution paths with deny-by-default policy | The dangerous command is still ‘inside the container’ |
| Call external services (Slack, payments APIs, AWS APIs) | Quotas, rate limits, and signing at the gateway | Secrets and budgets fail when keys live in the agent process |
Real applications where Strands Box-style controls pay off immediately
The most credible use cases are the ones already described as policies in the design examples: CI-style bots that can only push after tests pass, payments-related agents that must respect a $100 a day cap, and incident-response agents that can post to Slack only a limited number of times in a ten-minute window. These are business constraints engineers already understand; the difference is enforcing them against an autonomous actor that can use shell commands, Python, and tool calls interchangeably, which is the kind of scenario we see in AI security solutions.
The risks that remain even with kernel isolation and a policy engine
Strands Box does not eliminate risk; it moves risk into places you can manage. Directly granted files in box.toml are fenced by the OS but invisible to the policy engine and its history, so you can accidentally build a system where your most important governance logic has blind spots. The other persistent risk is complexity: the interceptors and interpreters expand the trusted computing base, and even with Rust plus testing, fuzzing, and validation, bugs are still possible—and in this category of software, bugs can mean policy bypass.
| Risk you still own | What Strands Box provides | What you must still engineer |
|---|---|---|
| Policy blind spots from direct file grants | OS fencing for granted files | A disciplined approach to which files are granted directly versus accessed through checkpointed paths |
| Bypass via defects in interceptors/interpreters | Rust implementation with testing, fuzzing, validation | Threat modeling, update strategy, and operational monitoring for unexpected behaviors |
| Policy authoring and drift over time | Dogwood deny-by-default and a policy-authoring skill | Governance for policy changes as workflows and tools evolve |
What this changes for CTOs: your agent platform is now a policy product
Strands Box is a strong signal that agent safety is shifting from ‘pick the right model’ to ‘build the right control plane.’ When agents can run shell, execute Python, call tools via MCP servers, and make network requests, autonomy becomes a platform problem: you need policy, history, and enforceable egress, not just isolation. Teams that treat sandboxing as a one-time security step will stall; the teams that win will treat policies as living operational contracts.
Chat GPT 
Perplexity 
Claude 
Gemini 
