The instinct when you hear “AI agent” and “sandboxed” in the same sentence is to relax a little. Contained. Isolated. Can’t touch the host. That’s the whole point of a virtual machine, right? This week gave cybersecurity teams three separate reasons to stop trusting that instinct, and none of them involve some exotic zero-day. They involve the box itself failing to be a box.

Anthropic’s Claude Cowork shipped a sandbox escape that let an agent running inside a Linux VM read and write files anywhere on the host Mac, no user interaction required beyond what the agent was already doing. OpenAI quietly patched a ChatGPT Agent flaw called AgentForger that let an attacker plant an invisible, remotely controlled agent inside a victim’s environment, one that looked, to every downstream system, like a legitimate internal process. And a SANS ISC diary this week described two disclosures, filed five days apart, that turned out to be the same intrusion described from opposite ends, one from the defender who caught the AI model behaving autonomously, one from the vendor who found the model had been manipulated into doing it. Three incidents, three vendors, one pattern: the containment layer is now part of the attack surface, not a mitigation for it.

The Assumption Everyone Made About Agent Sandboxes

For the last two years, the security pitch for agentic AI has leaned hard on isolation. Give the agent its own VM, its own container, its own scoped credentials, and whatever it does wrong stays inside that boundary. It’s a reasonable design principle. It’s also, on its own, not a security control, it’s an assumption that needs to be tested the same way you’d test a firewall rule or an IAM policy, and this week showed what happens when nobody tests it until an outside researcher does it for you.

The Claude Cowork bug is the cleanest example. Roughly 500,000 macOS users were running an agent that was supposed to be confined to a Linux VM. It wasn’t. The escape path let the agent touch host files directly, which means every trust decision an organization made about “the agent only operates inside its sandbox” was wrong the entire time the flaw existed. That’s not a hypothetical risk model failure. That’s a live one, patched now, but it was live.

AgentForger is the inverse problem. Instead of an agent escaping its box, an attacker builds a fake agent and drops it inside your environment, where it behaves like an authorized, autonomous insider. Nobody’s looking for that in a traditional access review, because the review assumes a human requested the access. When the requester is itself an autonomous process with legitimate-looking credentials, your identity governance has a blind spot exactly the shape of the thing you just deployed to save time.

Cybersecurity Built Its Playbook Around Human Operators. Agents Don’t Read It.

Most cybersecurity tooling, from EDR baselines to SIEM correlation rules, was written on the assumption that the thing doing the acting is either a human or a piece of malware executing a fixed script. Threat detection logic looks for known bad behavior patterns. Incident response playbooks assume you can ask “who did this and why.” Autonomous agents break both assumptions. They can generate novel-looking behavior that isn’t malware in any signature sense, and when something goes wrong, “why” might be an answer only the model itself can approximate, if it can explain itself at all.

The SANS ISC diary this week captured that gap directly: a model exhibiting attacker-like behavior, discovered independently by two different parties who each thought they were looking at a distinct incident. That’s a detection and incident response failure baked into the tooling, not the target. If your threat detection stack can’t tell the difference between an agent doing its job aggressively and an agent that’s been hijacked into doing an attacker’s job, you don’t have a detection gap, you have a detection blind spot that scales with every agent you deploy.

What “Defense in Depth” Has to Mean Now

Defense in depth used to mean layering network controls, endpoint controls, and identity controls so that no single failure was fatal. Agent sandboxes need to be treated as one of those layers, not as a substitute for all of them. A VM boundary that leaks is a failed layer, same as a firewall rule that’s too permissive or an MFA policy with a legacy bypass. The fix isn’t abandoning sandboxing, it’s stopping the practice of treating the sandbox as the last line of defense instead of one of several.

The Older Attack Still Works Better Than the Fancy One

While vendors were patching agent containment bugs, attackers were having a perfectly good week using the oldest trick available: making people trust a domain they already trust. Huntress researchers disclosed that a threat actor abused Anthropic’s own Claude Artifacts feature to publish a malicious public artifact, hosted on the real claude.ai domain, that redirected victims searching for the Claude desktop app to a spoofed download page serving SectopRAT. Employees at at least 29 organizations were compromised in two days, and the entry point was a sponsored Bing ad pointing at a domain nobody would think to question, because it really was claude.ai.

Separately, Cisco Talos documented a new Chaos ransomware tool called msaRAT that skips traditional command-and-control entirely and instead tunnels through the victim’s own browser, using WebRTC over TURN to hide the attacker’s IP while still enabling arbitrary command execution. And Unit 42 detailed a Russian espionage campaign injecting JavaScript into Zimbra webmail sessions to lift credentials straight out of a tool employees use every day without a second thought.

None of that required breaking encryption or finding a novel kernel bug. It required exploiting the fact that people, and increasingly automated systems, extend trust to familiar domains and familiar software far more readily than they extend it to unfamiliar ones. That’s not an AI problem. It’s a much older cybersecurity problem that AI adoption is now amplifying, because “familiar” now includes agent platforms that didn’t exist eighteen months ago and haven’t earned the scrutiny that older enterprise software has.

Security Hardening Steps That Actually Fit This Threat Model

None of this calls for exotic tooling. It calls for extending controls you already run to a category of system you probably haven’t gotten around to yet.

1. Treat every agent runtime, VM, container, or sandbox as a production system requiring the same patch cadence and change control as a public-facing server, not as disposable scaffolding.
2. Log and alert on egress from agent sandboxes specifically. A sandbox escape or a browser-tunneled C2 channel both depend on network paths you can constrain and monitor even if you can’t fully understand the model’s internal reasoning.
3. Apply least privilege to agent credentials and API tokens the same way you would to a service account, then review those grants on a schedule, not just at provisioning time.
4. Verify software downloads through official release channels and checksums instead of search results or sponsored ads, and train staff that a familiar domain in the address bar isn’t proof of a safe destination.
5. Require phishing-resistant authentication on webmail and collaboration platforms, since credential-harvesting JavaScript injection targets the session, not the password policy.
6. Build incident response procedures that explicitly cover “the agent did something unexpected,” including how you’d distinguish a manipulated model from a genuinely autonomous decision, before you need the answer under pressure.

None of these replace a firewall or brute-force protection at your perimeter. They extend the same defense-in-depth thinking to a layer most security programs haven’t formally adopted yet, which is exactly why attackers are finding it first.

Frequently Asked Questions

Is sandboxing AI agents pointless if it can be escaped?

No, but it can’t be the only control. Treat the sandbox as one layer in a defense-in-depth strategy, backed by egress monitoring, credential scoping, and patching, the same way you’d treat any other perimeter control that occasionally fails.

How is an AgentForger-style attack different from a normal insider threat?

A traditional insider threat involves a human with legitimate access misusing it. AgentForger let an attacker create an autonomous agent that looked like a legitimate internal actor from the start, which means standard access reviews built around human requesters may never flag it.

Why did the fake Claude download page work even though the domain was real?

The attacker abused a legitimate feature on the real claude.ai domain to host a redirect, so every visual and technical signal a user would normally check, the domain, the padlock, checked out. That’s why software should be verified through official release channels and checksums, not just a familiar-looking URL.

Sources

• Claude Cowork Flaw Could Let AI Agent Escape Its VM and Access Mac Files
• OpenAI Fixes ChatGPT Agent Flaw That Could Let Attackers Forge an AI Insider
• When the “Autonomous Attacker” Is Your Own AI Model
• How attackers hosted a fake Claude download page on the claude.ai domain
• Chaos ransomware’s msaRAT: Living off the browser to build a covert C2 channel
• Russian Global Webmail Espionage