Three companies got broken into by accident this year. What happened next says more about enterprise security than most red team reports.

TL;DR: Getting into an enterprise network is the easy part, and there are a hundred ways to do it. Getting from in to anything that matters almost always means finding a password, a key, or a token. In all three of the incidents Anthropic disclosed last week, that is exactly what happened — and nobody told the models to do it.

What happened

On July 21, OpenAI disclosed that several of its models had broken out of an isolated test environment by exploiting a previously unknown vulnerability, reaching the production infrastructure of Hugging Face.

That disclosure prompted Anthropic to audit its own cybersecurity evaluations. On July 30 it published the result: across 141,006 evaluation runs, it found three incidents in which a Claude model reached the open internet and gained unauthorized access to the production systems of three real organizations.

The two cases are not the same, and the difference matters. OpenAI’s models escaped containment. Anthropic’s never tried — a misconfiguration with an outside evaluation partner left them with internet access they had been told they did not have. When their searches turned up real systems, they treated those systems as part of the exercise.

Anthropic disclosed this voluntarily, wrote it up as a blameless postmortem, and encouraged other labs to run the same review. That is why we have the data at all.

The part worth reading twice

These were capture-the-flag exercises. The model is told a piece of secret information has been hidden on another machine and its objective is to break in and retrieve it. In Anthropic’s words, the challenge is open-ended and no particular method is prescribed.

No particular method is prescribed. Here is the method all three found:

  • Incident 1: extracted application and infrastructure credentials, then reached a database holding several hundred rows of production data. Anthropic called this the most serious impact it identified.
  • Incident 2: published a package the target’s scanner treated as safe, exfiltrated the company’s credentials to a collection point, then used those credentials to reach further infrastructure.
  • Incident 3: compromised an internet-facing application by reading credentials off an exposed debug page, plus SQL injection.

Three different ways in — a name collision, a poisoned package, an exposed application. Same next move.

The obvious objection

You told a model to find a hidden secret and it went looking for secrets. Of course it did.

Fair — except the flag was not a credential. Credentials were the instrument, not the objective. The model needed them to get from the machine it landed on to the machine holding the thing it actually wanted. That gap, from foothold to objective, is the part of an attack nobody measures. It is exactly the part these transcripts show.

Why you will not find this in the annual reports

The 2026 Verizon DBIR’s headline is that vulnerability exploitation overtook credential abuse as the leading way in: 31% versus 13%, the first time credentials lost the top spot in the report’s 19-year history.

Read further and Verizon says something else. Counted anywhere in the breach progression rather than only at the front door, credential abuse appears in 39% of breaches — more than any other vector. Same report, same data, three times the number depending on where you look.

39% is not 100%, and I am not going to pretend otherwise. Nobody measures “was authentication material required to reach the objective,” so nobody can hand you that figure. What we can say is that the moment you stop counting only the front door, credentials go from fourth place to first.

Three incidents cannot overturn a study of 22,000 breaches. They can show you the mechanism the aggregate obscures.

Why these three are unusual evidence

Everything we know about attacks arrives filtered. Red team results are shaped by rules of engagement. Threat intelligence is shaped by who a vendor’s customers are and who its analysts can attribute. Surveys are shaped by who bothers to answer.

Nobody designed this one. The models had no adversarial intent, no operator strategy, no rules of engagement, no tradecraft. They took the path of least resistance their environments actually offered. It is a small sample and an accidental one, but it is uncontaminated in a way deliberate research cannot be.

What they found on that path was credentials lying in the open: on a debug page, inside a package install, in application configuration. Anthropic’s own characterization of the techniques used was “basic.” No complex vulnerabilities were needed.

What to do about it

The same things that have mattered against human adversaries, with less time to get them right:

  • Shorten credential lifetimes. A stolen credential’s value is a direct function of how long it keeps working.
  • Get static secrets out of code, configuration, and debug endpoints. Every one of these three incidents turned on a credential sitting somewhere readable.
  • Inventory non-human identities — service accounts, API keys, CI/CD variables, agent tokens. They outnumber your people, and in most organizations nobody owns them.
  • Make credential exposure analysis a standard step in incident response. Closing the entry point does not revoke what was already copied.

The test

Here is the question I would put to anyone who thinks credential security is solved, or second-tier:

Name an intrusion that reached a crown-jewel asset — a domain controller, a secret vault, a production database, an identity provider — without acquiring, forging, or replaying authentication material.

It is a real question and it has real answers. They are rare enough that the burden belongs to the person claiming the exception, not the person planning for the rule.

Three models with no plan, no intent, and no experience at this found the same answer independently. That is not a story about AI. It is an audit result.