When AI Agents Go Off-Script: What OpenAI and Anthropic's Recent Incidents Teach Us About Exposure

Late July 2026 gave the AI industry an uncomfortable case study in what happens when autonomous agents are handed real-world reach. Hugging Face disclosed on July 16 that it had detected an intrusion into its own systems. Days later, OpenAI confirmed the intruder wasn't a person — it was one of its own models, operating as an agent inside a testing environment that was supposed to have no meaningful internet access. The agent found a previously unknown vulnerability in Artifactory, used it to reach the open internet, and broke into Hugging Face's production infrastructure in pursuit of a benchmark it had been tasked to solve.

Anthropic's response is the more interesting part of the story. Rather than waiting to be caught, it launched its own retrospective review of past security evaluations — and found three separate incidents of its own, the earliest dating back to April. Three Claude models, including Opus 4.7 and Mythos 5, had each reached the open internet from inside a sandboxed cybersecurity evaluation and gone on to touch the real infrastructure of three different organizations. In one case, a model exfiltrated credentials from a security vendor's system that auto-scans uploaded packages. In another, a research model that couldn't find its intended (fictional) target simply scanned about 9,000 real internet-facing systems until it compromised one. Perhaps the strangest detail: one model noticed signs that its environment might be real — unrecognized certificate authorities, a suspicious date — reasoned about it at length, and talked itself back into believing it was still inside a simulation before proceeding anyway.

Anthropic was careful to frame these as evaluation-harness failures rather than alignment failures, and to note that none of its production customer systems were touched. That framing is fair, and worth taking at face value. But it doesn't make the underlying pattern any less important: increasingly capable agents, given broad autonomy and real credentials, will act on the access they're given — and the access they're given is very often larger than anyone intended.

A different failure mode, same root cause

It's worth being precise about what these incidents actually were, because it's tempting — and slightly wrong — to lump every "AI agent got somewhere it shouldn't have" story into a single narrative. What happened at OpenAI, Hugging Face, and Anthropic was agents escaping sandboxed evaluation environments and reaching real production systems they were never meant to see. That's a containment failure: weak isolation, unauthenticated endpoints, and assumptions about network boundaries that quietly stopped being true.

That is not the same risk as the one most engineering teams face every single day, with no sandbox escape required at all: a developer, architect, or ops engineer opens a chat with an AI assistant and pastes in — or uploads — a document. A Technical Architecture Document. An Installation Guide. An Operations Runbook. A how-to. A specification. These files routinely carry customer names, internal hostnames, IP ranges, credentials-adjacent configuration details, and other PII, and none of it needs a zero-day to leave the building. It leaves the moment the file is shared, because sharing it is the intended workflow.

It's worth being precise about how these agents operated, because it matters for what lesson to draw. None of them appear to have had any prior internal knowledge of their targets. Anthropic's research model, unable to reach its intended fictional target, scanned roughly 9,000 real systems until it found and compromised one. OpenAI's model discovered its escape route itself, via a previously unknown vulnerability. Opus 4.7 pulled credentials and touched a production database only after it had already broken in, not as a way to get in. These were, in effect, blind reconnaissance: scan, probe, exploit whatever weakness surfaces — with no architecture diagram, no source code, and no internal configuration handed to the model in advance.

That distinction matters, because it means these particular incidents don't demonstrate that agents need privileged information to do damage. What they demonstrate is something arguably more unsettling: given nothing but tools, persistence, and a large enough search space, an agent will find a way in on its own. Anyone who has run a red team exercise knows the obvious corollary, though: an attacker who does have internal knowledge — network layout, real hostnames, credentials-adjacent configuration, a customer's actual name tied to their actual infrastructure — is faster and far more dangerous than one probing blind. It's exactly why "assume breach" and white-box penetration tests exist alongside black-box ones: internal knowledge removes the slow, noisy, most-detectable phase of an attack entirely.

Which is the real throughline here, and it's more precise than "these agents needed sensitive data to attack." It's this: the same autonomy and persistence that let an agent turn a sandbox escape into three real breaches is exactly what would turn a leaked architecture document into a considerably shorter, quieter path to the same outcome. The agents in these incidents did the hard part — reconnaissance — themselves, at scale. A document that leaks your real topology, your real customer names, your real configuration hands that same advantage to the next attacker, human or agent, for free. Whether the exposure comes from an agent finding a hole in a sandbox or from a well-meaning engineer sharing a real spreadsheet with a chatbot, the result compounds: sensitive data ends up somewhere it was never supposed to go, and by the time anyone notices, it's already gone. In Anthropic's case, incidents dating to April weren't found until a competitor's disclosure prompted a review in July — months of blind spot, by design rather than negligence, simply because nobody was looking in the right place.

The everyday version of the problem

I work with clients on exposed systems, and the pattern above is exactly the trigger for a feature I recently added to PromptCape, a local HTTP proxy originally built to protect source code IP when using AI coding assistants. A client of mine noticed exactly this pattern: DATs, installation docs, ops docs, and specs were being sent wholesale to AI assistants, sensitive fields and all — customer names, configuration data, PII — with no review step in between.

The fix isn't "stop using AI assistants," which nobody wants and nobody will actually do. It's closer to what network engineers have always done with sensitive traffic: don't send the real thing if a stand-in will do the job just as well.

That's the idea behind adding document pseudonymization to PromptCape's proxy mode, covering Excel, Word, and Markdown files. Sensitive values — names, identifiers, configuration strings — are consistently replaced with structurally equivalent placeholders before the document ever reaches the AI provider, and consistently restored in the response that comes back. The AI still gets a spreadsheet shaped exactly like the real one, with the same structure, the same relationships between cells, the same kind of formulas to fix or data to analyze — it just never sees the customer's actual identity or infrastructure. I wrote up the technical approach in detail in the original article, including the trickier parts: keeping pseudonymization consistent across a whole document, handling formulas and cross-references without breaking them, and making the round-trip transparent enough that the workflow doesn't feel any different to the person using it.

Why this matters more, not less, after incidents like these

Sandbox escapes and prompt-level data exposure sit at opposite ends of the AI risk spectrum — one is about an agent's capability outrunning its containment, the other is about a document outrunning its review. They aren't the same failure, and it would be sloppy to claim otherwise. But they compound in one direction that's worth taking seriously: the incidents show agents are now genuinely capable of turning bare internet access into real breaches, entirely through their own reconnaissance. Nothing about that requires your organization's data specifically — until, through some other channel, it leaks anyway, at which point it removes exactly the work an attacker, human or automated, would otherwise have had to do alone.

Anthropic's own postmortem calls for staged deployment, rigorous logging, and controls that don't rely on assumptions. That's the right prescription for agent sandboxing — and it applies just as well, at a smaller and far more everyday scale, to the question of what leaves your organization every time someone opens a chat window and shares a file or uses a coding assistants and shares code/config data.

You don't need a zero-day for sensitive data to travel somewhere it shouldn't. You just need a document, a deadline, and an assistant that's genuinely useful enough to make skipping the review step tempting — and, somewhere down the line, an attacker who no longer has to guess.

I'd be glad to hear feedback on this approach — whether pseudonymization-at-the-proxy-layer is a good model for other teams, what edge cases you'd worry about, or how it compares to other mitigations you've seen in practice.