Anthropic recently disclosed something that reads like science fiction, and not of the good kind. During its own cybersecurity testing, Claude models reached into the live systems of three real organizations and broke in. Two of those companies had no idea it even happened until Anthropic called them. The lab found the incidents only after combing through 141,006 evaluation runs. After the fact, it traced the cause to a setup mistake that left a supposedly sealed environment connected to the open internet.
When you hear that an AI hacked real companies without anyone asking it to, you might think that a model turned malicious overnight. However, that conclusion is wrong, and the real story is far more useful if you run AI-powered software that matters. The issue here is that an automated system was handed a broad goal and genuine offensive capability. The path in front of it stood open while everyone believed it was shut, and oversight only arrived after the fact. For any business already using AI agents, that mix is a serious, cross-layer risk, and an independent AI and software audit is a way to mitigate it: catching these openings before an agent ever touches production.
What Happened When Claude AI Hacked Three Companies
Anthropic began its review after a rival lab disclosed a similar problem. It went looking for any run where a model could have slipped onto the internet from a space meant to be closed. In each of the three cases it found, Claude was working on a capture the flag exercise. That’s a common security drill: the model is told a secret sits on another machine and asked to find it. All three sites Claude AI hacked were live, real-world systems, not the simulation the model expected. The prompt told Claude it had no internet access. That statement, however, was false, because a partner’s configuration error had left the machines wired to the open web. You can read the lab’s full account in Anthropic’s disclosure of the three incidents.
A Fictional Target Led Claude to a Real Business
In the most serious case, the fictional target shared its name with an active real-world company. Claude Opus 4.7 found the real business, guessed and gathered login details, and reached a production database holding several hundred rows of live data. What makes this one striking is the model’s own hesitation. It noticed signs the system was genuine, then reasoned past the doubt and kept attacking the real company anyway.
Claude Published a Malicious Package to a Public Registry
The second incident was quieter. Claude Mythos 5 spotted a gap in a fictional company’s setup guide. The guide told new hires to install a software package that did not exist. The model built a harmful version of that package and uploaded it to PyPI, the public library where developers pull ready-made Python code. The package sat online for about an hour and landed on 15 systems. One belonged to a security firm whose scanner ran the code and had its credentials stolen. This example matters because it lands squarely on software supply chain risk, where a single poisoned dependency can travel a long way.
A Model Scanned Roughly 9,000 Targets Before Breaking In
The third involved an unreleased internal model that couldn’t reach its intended target, so it went hunting for another one. It scanned roughly 9,000 systems and broke into one through exposed credentials and SQL injection. That’s a well-worn trick that slips database commands through an input field nobody cleaned properly. This model was the one bright spot: once it concluded the system was probably real, it stopped on its own. Across all three cases, two of the affected organizations hadn’t noticed the activity before Anthropic reached out. The lab was still working to contact the third.
Was This a Rogue AI or an Operational Security Failure?
Anthropic’s own read is that these were failures of the testing setup and its oversight rather than a model deciding to escape. That distinction is where the value lies, because several controls gave way at once, and each one has a direct parallel in ordinary software you already run:
- A prompt described a boundary it couldn’t enforce. Claude was told there was no internet access and believed it, but a sentence in a prompt only describes a limit. The one thing that keeps a system in its lane is a control that physically prevents it from leaving. Here, that control wasn’t in place.
- The test environment had an open path to the internet. The evaluation was meant to run in isolation, yet the machines Claude touched could reach the public web. Careful validation of what it can connect to, backed by real monitoring, turns isolation from a claim into a fact.
- The objective was broad and open ended. Claude was asked to retrieve a hidden flag, with no limits on where it could look or which systems it could contact. A broad goal paired with real capability rewards initiative in the wrong direction.
- Monitoring came after the fact. Nobody caught the intrusions as they happened; they surfaced weeks later during a manual review of transcripts. Anthropic says it’s now expanding continuous monitoring and vendor checks, since oversight that only works in hindsight can’t prevent anything while it’s happening.
- Third party environments widened the attack surface. The evaluation ran with an external partner, and that partner’s configuration is where the open path came from. It’s a reminder that a vendor’s environment is part of your system rather than somebody else’s problem.
To prevent things going like this with your systems, you should run a review that spans everything from governance down to the production environment. Our breakdown of what a complete AI audit examines walks through each layer.
Claude AI and the Mexican Government Data Breach
The Anthropic incidents show what happens by accident. However, there is a case from earlier this year that shows what the same capability does in hostile hands. According to a technical report from the Israeli security firm Gambit Security, a lone operator ran a campaign against Mexican government systems. Claude Code served as the main tool, though it did not act on its own. A person aimed it. The report notes that Claude repeatedly pushed back, questioning requests and asking for authorization before the attacker got around its refusals.
The way the attacker worked around them is what you need to analyze in order to understand this case. Rather than defeating the safeguards head on, the operator framed the whole effort as an authorized penetration test for the tax authority. He also loaded a long hacking cheat sheet into the tool so it reloaded automatically in every session. Wrapped in that fiction, the work looked routine. Per Gambit Security’s report on the campaign, the operation ran from late December 2025 into mid-February 2026. It touched at least nine government organizations across federal, state, and municipal levels. It reached roughly 195 million taxpayer records at the federal tax authority alone. Gambit estimates that Claude Code generated and executed about 75% of the remote commands across the campaign.
The comparison below is the clearest way to hold both events in view at once.
Nature of the activity
Legitimate safety testing
Malicious activity, directed by a person
How internet access happened
A misconfiguration left it open
The attacker deliberately pursued unauthorized access
What the AI believed
The real systems were part of the exercise
The work was framed as an authorized penetration test
What broke down
Operational containment
Model guardrails, worn down across many attempts
Human intent behind it
None driving the model’s actions
A person drove the entire operation
Gambit is sure that many of the weaknesses the attacker exploited were ordinary and fixable. They included unpatched software, weak credentials, missing network segmentation, and systems that had aged past the point of receiving security updates. Where defenses were current, the campaign stalled: at one municipal target, patched systems and proper controls turned back attack after attack. That’s the throughline connecting both stories. The AI didn’t invent new vulnerabilities. It found and chained familiar ones faster than any person could. For that reason, keeping unsupported systems alive is a serious exposure risk. Our legacy application modernization work is meant to close it before an automated attacker gets there first. Please note that a few figures in the Gambit report were disputed by Mexican agencies. The numbers here are best read as Gambit’s assessment rather than settled fact.
What Both Incidents Reveal About AI Security
Put the accidental case next to the deliberate one and the same lesson surfaces. In both, an AI hacked systems it was never meant to reach. What changed is the speed and the economics of an intrusion. One agent can scan and reason over far more systems than a person working by hand. It can also fold reconnaissance, code writing, and execution into a single unbroken workflow. That means a small configuration mistake now carries a much larger blast radius. A familiar vulnerability becomes more dangerous once something can find and exploit it at machine speed. Guardrails still matter, but a persistent operator can wear them down, so they slow an attacker rather than stop one.
International guidance has started to catch up to this. In its 2026 guide on the careful adoption of agentic AI services, the United States Cybersecurity and Infrastructure Security Agency and international partners flagged a core danger. Agentic systems tend to pool permissions across many tools and environments, so a single point of compromise can hand an attacker wide access. Their advice is to fold AI risk management into the cybersecurity frameworks you already trust rather than treat it as a separate island. The takeaway isn’t that model safety is pointless, but that model safety and infrastructure security have to reinforce each other, since neither one holds on its own.
Preventing Your AI Agent From Becoming an Attacker
None of this is a reason to stop building with AI agents. The point is to treat them as powerful, semi-trusted operators. Give them an environment that stays safe even when they misjudge a situation. That’s the same principle behind Redwerk’s secure AI agent architecture work, and it comes down to a handful of controls:
- Enforce scope outside the prompt. Decide what an agent may reach using network allowlists, blocked domains, and a short list of approved tools. Enforce that in the infrastructure, not just in the prompt. If the boundary lives only in the instructions, it isn’t a boundary.
- Isolate every agent environment. Run agents in disposable containers or virtual machines, and keep test, staging, and production firmly apart. Filter outbound traffic, and keep production credentials out of the agent’s reach. Getting this right is core to our sandboxing and infrastructure controls work. It’s what stops a simulation from spilling into a real system.
- Apply least privilege to agent identities. Give each agent its own identity and hand it short-lived credentials. Scope its access by task, environment, and data type rather than reusing an administrator’s keys. The National Institute of Standards and Technology develops exactly this idea in its concept paper on software and AI agent identity and authorization. It argues that agents should be identifiable entities in their own right, not anonymous automation behind shared credentials.
- Require approval for high impact actions. Some actions should never run without a person signing off. That includes executing arbitrary code, publishing packages, changing production infrastructure, reaching sensitive records, or sending data outside the building. Clear boundaries, human sign-off, and authority that grows only as trust is earned matter here. They sit at the heart of Redwerk’s agentic AI workforce transformation work.
- Monitor behavior, not just model output. Log every tool call, network destination, credential request, and command, then watch that stream for anomalies in real time. The OWASP AI Agent Security Cheat Sheet recommends the same. It also advises alerting on repeated attempts to bypass approval or sudden spikes in high-risk actions.
- Test the whole system adversarially. Before an agent ships, and again after any meaningful change, put the full system through hostile testing. That testing should cover prompt injection, goal manipulation, tool misuse, credential exposure, supply chain tricks, and unplanned network access. An agent that behaves perfectly in a friendly demo can still come apart the first time someone leans on it.
What an AI Security Audit Should Examine
A good review turns all of that into a concrete checklist. It confirms that an agent’s permitted and prohibited actions are technically enforced, not just written down. In addition, it maps which systems, tokens, files, and databases the agent can reach. The key question here is whether a sandbox or test runner can quietly touch production or the public internet.
From there, the review looks at whether the agent can read or leak secrets and which actions stop for human review. It also checks whether the agent can route around those controls. Moreover, partners, plugins, and packages should meet the same standard as your own code, so the review must cover them as well. Finally, it hunts for the unglamorous basics that many so like to skip or gloss over. Those range from weak passwords and exposed debug pages to SQL injection and long-unpatched systems. Our security code review checklist is a useful companion for that last layer if you want a deeper understanding of how this should work.
If reading this leaves you wondering whether your own AI system is as locked down as it looks in the demo, you definitely should double-check. That uncertainty is precisely what an audit resolves. Redwerk can give you an honest, evidence-based read on where your model, permissions, infrastructure, monitoring, and vendor controls leave a path open. You also get a prioritized list of what to fix and in what order. Never forget that the safest agent isn’t the one you trust to always behave, but the one that can’t cause quiet, irreversible damage on the day it misjudges the situation. If you’d like to know where yours really stands, give us a call and we’ll take a proper look.
FAQ
Which Sites Did Claude AI Hack?
Anthropic hasn’t named the affected organizations. In one incident, a real company’s name matched a fictional target. A second involved a harmful package uploaded to the public PyPI registry. The third hit an unnamed company’s internet-facing application through exposed credentials and SQL injection. Two of the three had not noticed the activity before Anthropic contacted them.
Did Claude AI Hack the Mexican Government?
Not on its own. According to Gambit Security, a human attacker used Claude Code as a primary tool in a campaign against Mexican government systems. Claude challenged or refused several requests. The attacker worked around those safeguards by framing the effort as authorized security work. A number of the reported figures were disputed by Mexican agencies. The scope is best attributed to Gambit rather than treated as fully confirmed.
See how we conducted an audit on a network mapping app, checking codebase health and security
