Strands Box: isolating and governing AI agents
AWS has released Strands Box in developer preview, an open-source sandbox combining operating-system containment with Dogwood policies that control agent actions. The project illustrates a useful enterprise rule: critical limits must be enforced outside the model’s probabilistic reasoning.
1. Two layers rather than one barrier
Strands Box is released under the Apache 2.0 licence. Containment limits what an agent can reach on the host and network. Within that perimeter, the Dogwood engine allows or denies actions under fine-grained and history-aware rules: files read or changed, commands executed, HTTP paths and methods, and MCP tools called.
This distinction matters. A container or microVM can isolate an environment without deciding that an incident-response agent may read logs but not change infrastructure, or limiting how often it posts to an incident channel. Strands Box aims to express these constraints through policy outside the agent.
2. What this changes for a Belgian or French organisation
For an SME, mid-market company, large enterprise, or public administration, the announcement primarily offers a testable architecture pattern. A development, cybersecurity, or operations agent can receive a bounded workspace, approved network destinations, and an allowlist of tools, while sensitive operations pass through shared enforcement points.
The project is nevertheless a developer preview. It is neither a managed service nor a certification or guarantee of GDPR or AI Act compliance. Before real use, teams must assess supported systems, execution-path coverage, bypass resistance, policy maintenance, evidence quality, and recovery capability.
3. Secrets the agent never receives
The egress gateway can replace a placeholder token with the real credential after a request is authorised. The secret stays outside the agent environment. Announced methods include Bearer tokens, custom headers, HTTP Basic authentication, query parameters, and AWS SigV4 signing.
The principle applies directly to agents connected to RAG, Odoo, or business APIs: an agent should not possess a broad, persistent secret. A gateway or identity broker should issue short-lived, contextual, revocable rights, while the target system retains its own authorisation layer.
4. Underside analysis: govern effects, not just calls
An agent harness often sees an abstract request such as “run this command.” Useful controls must also observe its effects: affected files, network destination, MCP tool, identity, action sequence, and cumulative volume. Dogwood’s temporal policies point in this direction, for example by blocking outbound HTTP after reading a customer-data directory or rate-limiting a repeated action.
This architecture strengthens cybersecurity but does not eliminate dependency risk. Strands Box explicitly widens its trusted computing base by running policy-enforcing interpreters outside the sandbox, and some direct access paths do not yet enter policy history. Sovereign governance must therefore document code, dependencies, telemetry, updates, host system, and exit procedures.
5. A cautious adoption plan
Start with a non-critical agent and deny-by-default policy. Allow one read-only task, with no secret in model context, then test deletion, exfiltration, indirect prompt injection, unexpected MCP calls, and revocation. Export decisions to security tooling and approve every expansion of rights separately.
For Odoo, separate reading, proposing, and writing. An invoice, payment, customer change, or HR action should remain subject to a dedicated identity, business rules, and—depending on risk—human approval. A sandbox protects the execution environment; it does not replace business-process controls.
Priority: keep authorisations, secrets, temporal limits, and logs outside the model, then use adversarial tests to verify that every execution path actually respects those controls.
Secure an agentic architecture