An agent's next permission can depend on its last action. AWS Strands Box makes authorization temporal

An agent reads a customer export to answer a question. A few minutes later it tries to post to an external webhook. Each action, on its own, is something the agent is allowed to do. Together they are an exfiltration path.

A static permission list cannot tell the difference. It judges every request as if nothing had happened before it. That is the gap AWS is aiming at with Strands Box, introduced on October 7 in developer preview: an open source agent sandbox, licensed Apache 2.0, whose policies can look at what the agent has already done before deciding what it may do next.

Four doors and a memory

Strands Box combines two layers. The first is operating system containment, which on macOS, the only supported platform today, uses Apple’s Seatbelt. The second is policy enforcement at four interception points: a gateway for network egress, a Python interpreter, a shell interpreter, and a broker for MCP tools.

The policies are written in Dogwood, a new open source policy language that borrows Cedar’s syntax. The difference from a conventional policy engine is in one sentence of the announcement: “Permissions can depend on earlier actions, their order and limits accumulated over time.” Every action that passes through those four doors is recorded, and later decisions can read that record.

AWS’s own example is deliberately simple. A rule allows the agent to post, but no more than three times every ten minutes. The fourth attempt inside the window is denied, while unrelated operations keep going.

A rule that counts what already happened

Window opensTen minutes later

1. Post 1Allowed
2. Post 2Allowed
3. Post 3Allowed
4. Post 4, at 10:06Denied, rule named in the 403
5. Other actionsStill allowed

When a policy denies an action, the gateway returns an HTTP 403 that names the rule by its identifier and carries its description. A denial that says which rule fired is something a developer can debug and a security reviewer can audit, which is more than most agent guardrails offer.

Credentials the agent never holds

The second idea is quieter and may matter more. Strands Box can inject credentials outside the agent’s environment. The agent works with placeholder tokens; the gateway swaps in the real secret on the way out, for bearer tokens, custom headers, basic authentication, query parameters and AWS SigV4 signing. In the announcement’s words, “The real secret never enters the agent’s environment.”

A prompt injection can persuade an agent to print everything it knows. It cannot leak a key the agent never had.

What history-aware rules are for

Rate limits are the easy case. The more interesting rules, illustrated here rather than taken from AWS’s examples, are the ones static permissions cannot express at all:

• Volume over a session. Allow deletions, but not more than a set number per task, so a misread instruction cannot empty a folder.
• Order. Allow a deployment only after a test run has succeeded in the same session.
• Flow. Restrict outbound requests once the agent has touched a sensitive source, which is the scenario this article opened with.

AWS also lists liveness rules on its roadmap: obligations an agent must eventually fulfill, such as closing what it opened, with detection when it does not. That would move policy from “what must not happen” to “what must happen”. It is a plan, not a feature.

The limits of a developer preview

The announcement is candid about the constraints, and so should any adoption plan be.

• macOS only for now. Other operating systems are a stated priority, as is running Box alongside agents on Bedrock AgentCore, ECS and Kubernetes. None of that is available yet.
• The interpreters run outside the sandbox, which widens the trusted computing base.
• Configuration is manual: a box.toml file and a policy.dw file, with automatic baselines on the roadmap.
• Directly granted paths are invisible to history. Paths granted in box.toml, such as a project directory read by the agent harness’s own file tool, are bounded by containment but do not appear in the policy history. A flow rule that depends on “has the agent read this?” only sees reads that pass through the policy layer.

That last point is the one to design around. Temporal policy is only as good as the record it reads.

This week Microsoft made Execution Containers generally available on Windows, moving the agent’s boundary into the operating system. Strands Box adds a different question to the same idea. Containment asks whether this agent may ever do something. Temporal policy asks whether it may do it now, given what it just did. Both answers have to come from outside the agent, and production agents will need both.