AWS put a sandbox around AI agents this week, and a lot of teams will treat that as the missing box in the rack. Operating-system isolation sounds like threat-protection you can finally buy for a workload that keeps growing new permissions. That’s the popular reaction, and it’s the wrong one. Cybersecurity for agents is a sequencing problem. The agent lists a directory, then reads a file, then calls an API. Each step looks allowed. Together they move data you never meant to expose.

A Sandbox Without Memory Is Just a Nicer Login

You already know how this movie goes. A vendor ships a containment feature. You drop it next to the firewall. The slide says defense in depth. Then someone on your team grants the agent a cloud token because the process is “in a jail.”

AWS released Strands Box as an open-source sandbox for AI agents, still in developer preview. The control that matters is the pause after each action. Box pairs operating-system isolation with rules that can weigh what an agent has already done before letting it act again. The process boundary keeps the agent from wandering the host at kernel level. The scoreboard decides whether a chain of allowed tools is still a helpdesk query or a quiet export.

Box runs on Macs with Apple silicon today. Linux support is planned. Read that again if your agents live on Linux CI runners, jump boxes, or a GPU host under someone’s desk. You have a preview on a specific laptop chip, and a press cycle that will outrun your architecture review. Procurement will file this under AI security and move on. Your job is to extract the sequence-scoring idea and enforce it with logs and policy you already control, on the OS you actually run.

Here’s the assumption worth killing: isolation equals a verdict. Isolation is a boundary. It does not tell you the agent combined three boring tools into a privileged workflow. People on your network do that already, just slower, and you already miss a chunk of it. Agents will finish the loop in a session that never opened a ticket.

Copy only the jail and you’ll get a cleaner crash with the same data loss. Steal the memory instead. Something in the loop has to remember the last move and refuse the next one.

The Second Command Is Where Cybersecurity Actually Breaks

Most threat detection still hunts a payload. A hash. A domain. A brute-force spray against SSH that your edge already rates. That model dies when the runtime is a language model with plugins and a package installer.

This week also put more than 1,500 npm packages on the exposure list. The agent, or the human who bootstraps it, can install from a registry that already hosted junk. The first command is install. The second command is whatever that code does with the environment variables in the working directory. Inspecting the model prompt leaves the runner unwatched.

Teams keep asking vendors for safer models. Ask them. Then look at the tool host. The break happens after the model is marked safe, while the runner still holds a token that can read mail, open a ticket, or push to object storage. Sequence-aware cyber security looks like a deny on tool X followed by tool Y against path Z, even when X and Y sit on the allowlist alone.

You’ve seen the boring version of this in cron and CI. The agent is a script that writes the next line itself. If your incident response runbook starts at malware on disk, you’ll image a laptop and miss the API receipts.

Sit with that pairing. An agent sandbox in developer preview and a pile of exposed packages in the same week. Trusted inputs and trusted runtimes share a control plane. Buy them as separate layers and you’ll keep funding the wrong one.

Your inbound firewall still watches strangers. The agent already has a seat. Brute-force lockouts do not apply to a valid token used in a tight loop from inside the VLAN. Edge threat-protection never saw the second move because the first move used a credential you issued on purpose.

Starve the Agent, Then Score Every Tool Call

Stop treating the model vendor as the owner of this risk. You own the runner, the secrets, and the path to production APIs. Do the work on hosts you already run, without waiting for Linux support in a preview sandbox.

Start with the runner, not the model

Immediate work is boring on purpose. Ongoing work is a review habit, not another purchase order.

1. Immediate: Inventory every agent identity, service principal, and personal access token a tool runner can touch. If you cannot name the owner and the expiry, revoke it this week.
2. Immediate: Replace standing secrets with short-lived, scoped credentials. Mail read plus repo write plus cloud admin on one identity is a single session away from a full incident.
3. Immediate: Pin packages and force a private registry. Disable arbitrary npm or PyPI installs on any host that holds production tokens. “Latest” is not a control, and 1,500 exposed packages is the proof.
4. Immediate: Log tool calls as an ordered sequence, not as isolated syslog lines. Alert on combinations: list then read then HTTP POST, or search then export then share.
5. Immediate: Run the agent as an unprivileged OS user on a dedicated host. No lateral file shares, no prod SSO cookies, no SSH keys to the rest of the fleet.
6. Ongoing: Review those sequences every week the way you review firewall diffs. Tabletop a runaway agent that did three allowed things in the wrong order. If nobody can show you the ordered log, you cannot do threat detection on this workload.
7. Ongoing: Keep a kill switch you can hit without paging a model vendor. Preserve the tool-call log, rotate every secret the session could have seen, and treat the identity as burned until you prove otherwise.

Security hardening on the runner beats another prompt filter: disk encryption, no shared admin, outbound allowlists, and a separate management plane. Defense in depth here means isolation plus scoring plus starved credentials, enforced by you, on hardware you already own.

Frequently Asked Questions

Is an OS sandbox enough for production agents?

No. A sandbox is a process boundary, and most production agents are not even running inside the preview you saw this week. You still need sequenced tool-call policy, pinned packages, and credentials that die when the session dies.

How do we detect a bad agent session if every tool is allowed?

Detect the order and the object, not the binary. List-then-read-then-POST against secrets paths is the signal. Isolated allowlist hits will look like productivity until you keep them in sequence.

What should incident response look like when the agent used valid tokens?

Kill the runtime, revoke and rotate every token it could reach, and export the ordered tool log before someone rotates the host. Valid credentials make this a service-account compromise. Disk malware hunts will miss it.

Sources

• Week in review: Hidden implant in Ledger wallets linked to $93M theft, 1,500+ npm packages exposed