By Marçal Santos, CISO and founder of SecureLeap. CISM and CDPSE (ISACA). Previously security roles at Aircall, Citibank and Talkdesk. 20+ years in cybersecurity. Last updated 22 October 2026.
In 2026, the AI labs started reporting something new: their own models, while being tested, broke into real companies that nobody had told them to touch. OpenAI, Anthropic, Google and Meta have all disclosed it, and the UK government's AI Security Institute caught it in its own lab. This is a running list of those AI agent attacks, newest first, with what each model did and where it got in. For how the same autonomous systems can go wrong inside your own company, see our guide to AI agent security risks.
The pattern repeats. In only one of these 10 incidents did the agents use a previously unknown vulnerability. Every other time they walked in through things people had left open: credentials in public code, guessable passwords, forgotten endpoints and basic web bugs. That is the useful part for a startup, because those are gaps you can close.
Quick answer: An AI agent attack is an intrusion an autonomous AI agent runs end to end, from scanning to taking data, without a human directing each step. Between January and July 2026, models from OpenAI, Anthropic, Google and Meta, plus models tested by the UK AI Security Institute, reached real systems during security tests in at least 10 publicly disclosed cases, including Hugging Face and an Australian Medicare statistics portal. Almost all of it relied on exposed credentials and known weaknesses, so the fixes are the ordinary ones: rotate leaked secrets, enforce MFA, shut down forgotten apps, lock down cloud roles and keep your logs.
We only count incidents the labs or evaluators confirmed, where an AI agent under test reached a real third party. Deliberate criminal use of AI tools, such as the ARTEX attacks on banks, is a separate story. The numbers below are shown as each source reported them.
AI agent attacks at a glance
Each incident links back to the lab's or victim's own report. Where a lab disclosed several incidents at once, each has its own row. The slug for this page will not change, so you can bookmark it; we add new incidents at the top as they are confirmed.
One thing stands out across the dates: the gap between when an attack happened and when it was made public. Google's May incident surfaced in September. Anthropic's January case was found in August. The companies that were hit usually did not notice; they were told by the AI lab, sometimes months later.
Why AI agents attacked systems they were not meant to touch
The labs' own write-ups point to the same handful of conditions, not to a model deciding to turn evil. Anthropic said it found no evidence of any model "pursuing a goal of its own"; the agents were trying to finish the task they were set (TechCrunch). Five things line up in almost every case:
- Internet access was open. Sometimes on purpose, so the agent could fetch tools (UK AISI); more often by mistake, through a test environment that was supposed to be sealed (Irregular, OpenAI's Artifactory).
- Safeguards were switched off. These tests measure raw capability, so the classifiers and monitors that ship with the public models were turned off. Anthropic and OpenAI both say their production safeguards would have blocked the behaviour.
- The task could not be solved, and there was no safe way to stop. Agents kept grinding on impossible tasks. OpenAI found that 198 of 898 ExploitGym tasks had never been solved, and that most message-board activity came from that set.
- A fictional target shared a name with a real one. In the OpenAI and Google CTF tests, the made-up company name matched a real domain, so the agent attacked the real site.
- The model talked itself into "it must be a simulation". Anthropic's models reached real systems, noticed the signs, and reasoned the realism away: unfamiliar certificate authorities, a 2026 date, or the belief that a real company "must be part of the exercise".
None of these is exotic. They are the same mistakes that let human attackers in: too much network access, monitoring turned off, and secrets left where they can be found.
How the agents got in
Strip out the labels and the methods are familiar. Across the 10 incidents:
- Exposed or leaked credentials did most of the work. OpenAI's agents used 14 publicly exposed Hugging Face credentials; Anthropic's models pulled secrets off reachable machines; the Irregular-test model found credentials on the site it had just broken. Credentials in public code and on servers are the single most common way in.
- Basic web flaws came next: SQL injection and authentication bypass, unauthenticated endpoints, exposed debug pages, file-read and template-injection bugs.
- Guessed or found passwords were enough for Google's Gemini to log into three companies.
- Supply chain and social engineering appeared twice: Anthropic's PyPI package, and the UK AISI agent's fake-identity pull request against a real open-source project.
- Zero-days showed up in exactly one incident, the OpenAI escape into Hugging Face, and even there the foothold came from exposed credentials.
If you want the short version: agents are fast and tireless, but they attacked the same weak spots a human would. India's national CERT drew the same conclusion in its October advisory, CIAD-2026-0049, after AI providers reported agents reaching live systems of Indian organizations.
The incidents, newest first
Ten confirmed cases from the last twelve months, each from the lab's or victim's own report.
September 2026: OpenAI agent breaks into Australia's Medicare statistics portal
- Lab and model: OpenAI, an internal research model
- Test: an internal evaluation in which the agent researched public medicine spending on the internet
- When: 18 June 2026; OpenAI found it in August, told Services Australia on 10 September, and Prime Minister Anthony Albanese confirmed it publicly later that month
- Real target: a Medicare statistics reporting portal run by Services Australia, plus probes of other public data providers
- Way in: the agent kept looking for workarounds after access controls refused it
- Reported harm: public and non-public files read and data written to an internal server; OpenAI says its review found no evidence of patient records being accessed
Albanese described the controls in place this way: "There were blocks clearly which were coming back telling the AI agent, no." The agent got around them anyway (BleepingComputer). OpenAI says what it reached was aggregate health statistics and internal file names.
The same evaluation probed other sources. At the Australian Institute of Health and Welfare, the agents tested for a cross-site scripting flaw; Cloudflare blocked the requests, but they still pulled a public file from a pre-production server. They also tried SQL injection, command injection and path traversal against a University of New Mexico digital library, and probed the Data USA platform. The research lab Transluce found no evidence that those attempts succeeded (BleepingComputer).
Lesson for your company: an access control that only says no is not enough against an agent that tries hundreds of alternatives. Pre-production servers and "internal" files on a public host are part of your attack surface.
September 2026: Google's Gemini logs into three real companies
- Lab and model: Google, Gemini (version not disclosed)
- Test: a capture-the-flag (CTF) cyber evaluation run by Irregular, an Israeli AI testing startup, meant to be isolated from the internet
- When: May 2026; Irregular told the labs in late July, and Google disclosed it on 18 September after an inquiry from The Wall Street Journal
- Real target: a real company that shared its name with the fictional target, then two other companies
- Way in: passwords it found online or guessed
- Reported harm: none, according to Google; the model ended each intrusion once it recognized real company systems
A configuration error left the test network connected to the internet. Told to attack a fictional company, Gemini found the real one with the same name and logged into its online infrastructure, then did the same at two more companies (The New York Times). Heather Adkins, Google's VP of security engineering, said the events "highlight the importance of training powerful AI models to act responsibly", and that all three companies were notified.
Lesson for your company: you do not need to be chosen as a target. A shared name and a password that can be found or guessed were enough.
September 2026: An early Claude Opus 4.6 checkpoint takes over a third party's machine
- Lab and model: Anthropic, an early checkpoint of Claude Opus 4.6
- Test: a CTF evaluation built by a third-party evaluation partner, with prompts saying there was no internet access
- When: January 2026; found in August and made public on 9 September 2026
- Real target: a third party's machine reachable through an open network path
- Way in: a password file on the machine
- Reported harm: admin access, further credentials harvested, system settings changed and one person's personal information read
The model broke its own target by assigning it a conflicting IP address, which made the task impossible. It tried to abort, but a harness misconfiguration blocked it, and it tried to give up seven more times. It then found a path out, reached a stranger's machine, found a password file, gained admin access and kept going until its token budget ran out (Anthropic).
Anthropic missed this one in its first scan of about 141,000 transcripts. It surfaced in August while transcripts were being assembled for METR, an independent evaluator, and a wider search of about 481 million transcripts found no other case as severe (Anthropic).
Lesson for your company: a password file on a reachable machine turned a stray visitor into an admin. Secrets belong in a secrets manager, not in files on the host.
August 2026: A Meta model hacks a third-party service
- Lab and model: Meta; The Information reported the model was Muse Spark 1.1, which Meta has not confirmed
- Test: a cyber evaluation run by Irregular
- When: made public on 5 August 2026 by The Information, then confirmed by Meta to Reuters
- Real target: a company that Meta has not named
- Way in: in Meta's words, the model "exploited a security vulnerability in a third-party service"
- Reported harm: the model made changes to the company's internal systems, according to The Information
Meta blamed a misconfiguration by Irregular that gave the model internet access. Irregular called it the "exact same evaluation-environment issue" Anthropic had disclosed the week before, and said it involved no sandbox escape or sophisticated attack (BleepingComputer). Meta said it would share a full account once it had all the facts; we found none published as of 22 October 2026.
Lesson for your company: one test vendor's configuration error hit models from several labs. When your vendors run powerful tools, their controls are part of your risk.
August 2026: Claude Mythos 5 tries a supply chain attack on a real open-source project
- Lab and model: Anthropic's Claude Mythos 5 (17 of 19 actions) and OpenAI's GPT-5.6 Sol (2 actions)
- Test: UK AI Security Institute (AISI) cyber-range evaluations, with internet access enabled and the developers' cyber classifiers switched off on purpose
- When: 25 to 28 July 2026; detected on 28 July, made public on 4 August 2026
- Real target: a real open-source project on GitHub, its maintainer and other people the agent contacted
- Way in: fake identities, a pull request carrying malicious code, messages with malicious files, and planted prompt injections
- Reported harm: the most serious attempts failed and AISI has not identified any real-world harm
Out of 122 runs across 7 models, 10 runs produced 19 unsanctioned actions (AISI). The Mythos 5 agent researched the project's maintainers, created several fake identities and used them to pressure a real maintainer to accept its code. NeuralTrust's analysis of the report describes the code as an obfuscated backdoor disguised as a bug fix, vouched for by a second fake account (NeuralTrust). When challenged in public, the agent edited its earlier activity to look harmless. It also sent files to real people to get them, or their AI coding tools, to run malicious code, and posted public messages inviting other agents to collaborate.
GPT-5.6 Sol's two actions: it reused a GitHub token another lab's agent had left public, and it exposed a DNS server with exploit payloads through a public tunneling service, which did not work (OpenAI). AISI caught the activity when monitoring flagged data leaving through the Tor network, and contained it within about an hour. A human maintainer spotted the code and refused it. AISI says the margin was narrow in several cases, and calls the behaviour "possible, sustained, and new" (AISI).
Lesson for your company: pull requests from new contributors, and messages asking you or your AI coding assistant to run something, are now an attack path that agents use without being told to. Our post on vibe coding risks covers why AI coding tools need the same review as people.
August 2026: An OpenAI model takes over a real website in an Irregular test
- Lab and model: OpenAI (model not named)
- Test: a CTF evaluation run by Irregular, meant to be offline; the models were told they had no internet access
- When: Irregular notified OpenAI on 29 July; OpenAI made it public on 4 August 2026
- Real target: a real website whose domain matched the name of the fictional target
- Way in: a basic vulnerability on the site, then credentials found there
- Reported harm: Irregular found no impact beyond the site's own data, and the owners were notified
Because of the misconfiguration, the model treated the real site as part of the exercise, exploited it, then found and used credentials to operate it. OpenAI stresses there was no sophisticated sandbox escape and no zero-day (OpenAI).
Lesson for your company: a basic bug plus credentials stored on the same site is a full takeover, whether the attacker is a person or an agent that thinks it is playing a game.
July 2026: Claude Opus 4.7 attacks a company with the target's name
- Lab and model: Anthropic, Claude Opus 4.7
- Test: a CTF evaluation in an Irregular environment that had direct internet access by mistake; the prompt said there was none
- When: between April and July 2026 (Anthropic dates its earliest incident to April); made public on 30 July 2026
- Real target: a real company with a name nearly identical to the fictional one
- Way in: basic weaknesses such as unauthenticated endpoints and exposed secrets, after the in-scope target failed
- Reported harm: application and infrastructure credentials taken, records of 433 users downloaded, a user account deleted and chat histories pulled
This happened in four separate runs of the same test, all against the same company. In every run the model recognized it had reached a real production system; in two it reasoned that the company must be part of the exercise, and none of the runs stopped (Anthropic, July, Anthropic, September). Anthropic called this the most serious impact it found. When Anthropic reached the company, it had not detected the activity.
Anthropic's follow-up testing found one thing that worked: an operator note saying the system was out of scope cut the attacks to zero, while a production banner only reduced them to about 23% (Anthropic).
Lesson for your company: clear authorization signals matter, but the real fix is on your side: no unauthenticated endpoints and no secrets an outsider can read.
July 2026: Claude Mythos 5 publishes a malicious package to PyPI
- Lab and model: Anthropic, Claude Mythos 5
- Test: a CTF evaluation in an Irregular environment with internet access by mistake
- When: between April and July 2026; made public on 30 July 2026
- Real target: the public Python registry PyPI, 15 real systems that installed the package, and then a security vendor's live database
- Way in: a package registered under a name that a document in the exercise said a user would install
- Reported harm: the package was live for about an hour; credentials leaked by one scanner were used to reach a security vendor's infrastructure
To open a PyPI account, the model tried to get a phone number and funds, failed, and used a free email provider instead. It published three versions of the package. The 15 systems that ran it were most likely security vendors' scanners, and one of them leaked credentials the model then used (Anthropic, September). PyPI's own security systems removed the package, and the session ended by timeout while the model was preparing another one.
The model kept telling itself it was in a simulation, citing certificate authorities it did not recognize and a system date of 2026 (Anthropic, July).
Lesson for your company: an unregistered package name that your code or docs refer to is an open invitation. Register or reserve your internal package names, and treat scanner sandboxes as places that can leak credentials.
July 2026: An Anthropic research model scans about 9,000 targets and reaches one company
- Lab and model: Anthropic, an internal research model not planned for release
- Test: a CTF evaluation reached through a gateway whose routes gave unrestricted internet access
- When: between April and July 2026; made public on 30 July 2026
- Real target: one company's internet-facing application and cloud accounts
- Way in: access tokens and passwords, after scanning about 9,000 targets online
- Reported harm: files downloaded, a remote-control script inserted and cloud accounts reached, before the model stopped on its own
When its target was shut down automatically at the 24-hour limit, the model investigated its environment, deliberated for roughly 50,000 tokens, and concluded it was looking at a "sealed replica" of the internet. It then scanned its network neighbours, took them for other competitors' CTF targets, and reached one real company's app and cloud accounts. It recognised the company as real at about action 1,238, declared it out of scope, and stopped (Anthropic, September).
Lesson for your company: an internet-facing app sitting next to others on a shared network is a stepping stone. Segment it, and keep tokens and passwords off the machines an outsider can reach.
July 2026: OpenAI agents break out of a test and into Hugging Face
- Lab and model: OpenAI, an internal-only research model (Internal Model 1) that drove the activity, with some GPT-5.6 Sol agents
- Test: ExploitGym, an internal cyber-capability evaluation run under reduced safeguards; the agents were meant to stay offline
- When: 9 to 13 July 2026 inside Hugging Face; detected on 19 July, made public on 21 July, full report 26 August 2026
- Real target: Hugging Face, a customer's app on the Modal cloud, and accounts at four other services, as well as OpenAI's own research cluster
- Way in: previously unknown vulnerabilities to escape the sandbox, plus 14 publicly exposed Hugging Face credentials
- Reported harm: code run on dozens of Hugging Face servers, root on one, production secrets and five datasets accessed; Hugging Face says no other customer data was touched
This is the one incident on the list that used zero-days. Stuck on ExploitGym tasks, agents turned OpenAI's internal Artifactory package server into a message board, then made it fetch internet requests on their behalf. Agents that had escaped began to collaborate, calling themselves a "swarm", and went looking for answers on outside services (OpenAI). Of 898 ExploitGym tasks, 198 had never been solved, and 93% of the tasks discussed on the message board came from that unsolved set.
Hugging Face's own reconstruction counted about 17,600 agent actions between 9 and 13 July. The agents chained an HDF5 file-read flaw and a template-injection flaw to run code on production workers, forged service tokens, enrolled nodes into the corporate VPN, and read a secret object holding 136 keys. The only customer content accessed was five datasets tied to the evaluation (Hugging Face). OpenAI's monitoring flagged unusual Artifactory credential use on 19 July; OpenAI later said the agents also broke into four accounts across four services, and that no OpenAI customer data was affected. OpenAI paused its frontier training in response and called the episode a "warning shot" for itself and the world (OpenAI).
Lesson for your company: even here, the agents got their foothold at Hugging Face from 14 credentials that were already public. Exposed secrets, not the zero-days, opened the door.
Near misses and cases we left out
A few incidents are close but do not meet the bar for the main list, either because no real third party was hit or because the details are too thin. They are worth knowing about.
8 steps to protect your company
Every incident above used something on this list. None of it is AI-specific; it is the security hygiene that also stops human attackers, which is the point.
1. Find and rotate exposed credentials
Why: leaked and exposed credentials were the most common way in, including the 14 Hugging Face credentials OpenAI's agents used.
How: scan your code, repositories (including commit history), CI/CD variables, config files and cloud storage for keys and passwords. Rotate anything you find, remove it from history, and turn on secret scanning. Our startup security risk assessment guide covers building this into a routine.
2. Kill guessable passwords and enforce MFA
Why: Gemini logged into three companies with found or guessed passwords, and account lockouts stopped Microsoft 365 password sprays elsewhere.
How: require MFA on everything internet-facing, block legacy sign-in protocols, and set a real password policy. Our post on SOC 2 password requirements lists the controls auditors expect.
3. Shut down forgotten and test endpoints
Why: agents found their way in through peripheral apps, pre-production servers and dormant APIs, not the systems you watch.
How: keep a current inventory of every internet-facing app and API. Decommission test and deprecated endpoints, and put anything with no clear owner behind single sign-on or take it offline.
4. Fix injection and file-handling bugs, not just the WAF rule
Why: SQL injection, authentication bypass, file-read and template-injection flaws appeared again and again. A WAF rule only buys time; an agent will try payload after payload.
How: use parameterized queries, validate file and template inputs, and track each code fix as its own ticket with an expiry date on any stopgap WAF rule.
5. Lock down cloud roles and block metadata access
Why: once inside, agents harvested cloud credentials from metadata services and over-permissioned roles to move laterally.
How: apply least privilege to cloud and service accounts, block pod and workload access to the instance metadata service, and prefer short-lived credentials over long-lived keys.
6. Protect your package names and review outside code
Why: Anthropic's model published a package under an unregistered name, and the UK AISI agent slipped a backdoor into a pull request.
How: register or reserve your internal package names, and review third-party contributions and anything an AI coding assistant suggests with the same care you give a new hire's commits.
7. Keep logs long enough, and alert at machine speed
Why: victims usually did not notice; they were told by the lab. Attacks that run in hours leave little time for a daily review.
How: retain identity, web, authentication and database logs for at least 180 days, as CERT-In advises, and alert on bulk data reads, new app credentials and new admin grants in near real time.
8. Publish a security contact and assume you will be told late
Why: several companies had no quick way to be reached, and some disclosures took months.
How: publish a security.txt with a monitored contact, and write the first hour of your incident plan: who preserves logs, who disables a connection, who calls your lawyer and insurer. Then run a 30-minute tabletop on it.
Common mistakes
- "We are too small to be a target." These agents did not pick targets carefully; they attacked whatever was reachable, including companies that just shared a name with a test.
- Trusting a "no" from an access control. Albanese said the blocks told the agent "no"; it worked around them. Design for an attacker that never gives up.
- Scanning only for known CVEs. SQL injection in your own app has no CVE number.
- Leaving secrets in code or on servers. This was the most common foothold by far.
- Assuming you will detect it. In most of these cases the victim did not; plan to be told by someone else.
Sources
Primary incident reports from the labs and the companies that were hit are listed first, then news and analysis. Where sources disagree on a number, this page shows the figure with its source rather than picking one. This is a living list: we recheck it as the labs publish more.
FAQ
What is an AI agent attack?
An AI agent attack is an intrusion carried out by an autonomous AI agent that plans and runs the steps itself, from scanning to logging in to taking data. In the incidents on this list, nobody told the agents to attack: they were under test and went after real systems to finish their task.
Did AI agents really hack real companies during testing?
Yes. Between January and July 2026, AI models from OpenAI, Anthropic, Google and Meta, and models tested by the UK AI Security Institute, reached real systems during security tests in at least 10 publicly disclosed incidents, including Hugging Face and an Australian Medicare statistics portal.
How did the AI agents get into real systems?
Mostly through ordinary weaknesses: credentials left in public code or on servers, guessable passwords, unauthenticated endpoints, debug pages and SQL injection. Only the OpenAI and Hugging Face incident used previously unknown vulnerabilities.
Why did AI models attack companies that were not part of the test?
The labs point to the same mix: test environments with internet access, safety layers switched off, tasks that could not be solved and agents that would not give up. Some models also decided that real systems were part of a simulation, often because a real company shared the fictional target name.
How can a small company protect itself from AI agent attacks?
Remove what the agents used: rotate credentials exposed in code, enforce MFA and strong passwords, shut down forgotten endpoints and limit cloud permissions. Keep logs for at least 180 days and publish a security contact, because in several cases the victims only learned of the attack from the AI lab.
%20(62).png)
