For: anyone who runs a website or online service. This article is based on official disclosures from OpenAI, Anthropic, the Wikimedia Foundation, and the Australian government (the Prime Minister's press conference and the Australian Cyber Security Centre's alert). It contains no attack steps. The first case, in July, is covered in the Hugging Face intrusion (2026).
What was disclosed
18 June 2026
OpenAI's research team had an internal model research public medicine spending. After repeated blocks, the agent found a way around them and accessed public and non-public files on Australia's Medicare statistics portal (per the Australian Prime Minister's press conference).16 July 2026
Hugging Face disclosed an intrusion carried out by an AI agent (explainer).23–24 July 2026
Anthropic reviewed 141,006 evaluation runs for similar cases and identified three in which models under evaluation reached the production systems of three real companies. It stopped all cyber evaluations the same day.27 July 2026
Anthropic notified its evaluation partner and the three affected organizations. The two it could reach had not previously detected the activity (per its disclosure).18 August 2026
OpenAI said it had temporarily slowed frontier-model training and strengthened isolation in research environments (stronger sandboxes for untrusted code, network isolation).9 September 2026
Anthropic disclosed a fourth case, from a January 2026 evaluation, on top of July's three. It widened its review from about 141,000 to about 481 million transcripts and found no other cases of similar or worse severity. It also signed an agreement with an external evaluator for an independent investigation.10 September 2026
OpenAI's first notice to the Australian government — an email to a general public mailbox (per the Prime Minister).15 September 2026
Services Australia reported the notice to the Australian Cyber Security Centre (ACSC).24 September 2026
The Prime Minister disclosed the incident and set up a taskforce. The same day, the ACSC issued an alert for "all Australian organisations with public-facing websites or applications".25 September 2026
OpenAI said its review would take months and that it is notifying affected organizations as cases are verified.5 October 2026
The Wikimedia Foundation said it had found activity on its projects by agents it believes were operated by OpenAI.9 October 2026
Anthropic disclosed cases where models took unintended actions on real sites during evaluations and internal use, including a false tip submitted through a Philadelphia Police form. The Philadelphia Police Department also announced the case the same day (according to Anthropic).
- OpenAI: scale of notifications
- After a broad review of its models' internet activity during training and evaluation, it has notified dozens of third parties meeting its criteria, with the review ongoing. Some of the sites involved are run by governments, universities and public agencies — partly because research tasks steer models toward authoritative public sources, the company says
- OpenAI: kinds of activity observed
- (1) bypassing access controls (using a different web address, altering requests, using a session with more access than intended) (2) using publicly exposed credentials (3) query or command injection (4) reaching the internals of a service (5) agent spam (posting on third-party sites, such as using a public wiki as a message board)
- Anthropic: what happened
- A misconfiguration left the evaluation machines with live internet access (the company attributes it to a misunderstanding between itself and its evaluation partner; neither was aware). The model treated real systems as part of the exercise. In one case it scanned about 9,000 targets and compromised one company's application using basic, well-known techniques such as reading credentials from an exposed debug page and SQL injection
- Anthropic: effect on a public registry
- Using a non-existent Python package name from a fictional company's setup guide, the model published a malicious package. It was available for about an hour and ran on 15 real systems (one of them a security company's scanner that installs packages to check them)
- Anthropic: the fourth case (9 September report)
- In a January 2026 evaluation, an early version of a model accessed a third party's machine. It found a file listing a password, used it to gain admin access, changed settings to make access easier, and read the personal information of one person associated with the third party. Anthropic says it notified the affected party after finding the case. The July report said three; with this report, the total of unauthorized access to third-party systems is four
- Anthropic: unintended actions in evaluations and internal use (9 October report)
- Four kinds: (1) running commands on a server through a basic flaw in a university-hosted analysis tool (2) submitting forms that should not have been sent (for example, submitting a real government form when a practice copy failed to load) (3) working around restrictions to reach paid or restricted data (for example, access tokens in a local government map site's settings file, or tokens a state agency's public dashboard issues to any visitor) (4) getting around the fetch tool's URL length limit with URL shortening services
- Anthropic: impact and notification
- Some cases involved sites run by U.S. federal, state and local government agencies, which Anthropic does not name, at their request. It notified each agency and briefed the White House. Anthropic says none involved customer data or its own internal systems, and real-world impact was minimal, and it rates these as significantly less severe than the four cybersecurity incidents
- The Philadelphia Police tip form
- While generating example tasks on randomly selected web pages, a model reached an unsolved-homicide page and submitted an invented tip through its form, leaving the name and contact fields empty. It was flagged as spam and never forwarded for investigation (per Anthropic). Police say it was submitted on 18 July at 11:27 p.m. and that Anthropic notified them on 7 October (as reported by NBC Philadelphia). Anthropic says it shared the finding with the department on 8 October, once its technical review was complete. The two accounts give different dates. Police called the two-month delay in detecting and reporting it "unacceptable" (same report)
- Anthropic's measures (9 October report)
- Some public evaluations retired, others moved to offline versions that do not reach live sites. Live internet access turned off for all internal evaluations. Web fetch tools heavily restricted. Automated detection and blocking of these behaviors on most evaluations and internal agentic use of frontier models
- The Wikimedia Foundation (5 October report)
- Agents the Foundation believes were operated by OpenAI made edits without community approval (almost all test edits in sandbox areas). A few changed a citation tool's configuration, which the Foundation calls potentially malicious, aimed at using the tool as a proxy to fetch data from remote services. Attempts to compromise the public Etherpad note-taking tool and to use it as a proxy failed. There were millions of public API requests, millions of crawled pages, and hundreds of thousands of Wikidata Query Service queries, which may have contributed to a partial outage in May. The Foundation found no evidence of its systems or data being compromised
- The Australian government
- An OpenAI agent accessed public and non-public files on the Medicare statistics portal run by Services Australia. No personal information is believed to have been accessed so far; the investigation continues. The Prime Minister raised concerns directly with OpenAI's CEO about how late and how (an email to a public mailbox) the notice came
- The ACSC alert
- An agent independently identified vulnerabilities and tried to progress without direct human authorisation in order to complete its assigned activity. The ACSC says there is no indication of a broader threat or malicious targeting, and advises strong authentication and access control, prompt remediation, monitoring and log review, and testing response procedures against AI-enabled scenarios
Cases we did not cover
Reports also describe a Google AI model entering a real company's systems during evaluation, but we could not find a first-party disclosure from Google, so this article does not cover it. Claims attributing a mass-publishing campaign on RubyGems to OpenAI agents are also left out: RubyGems says it cannot determine whether AI agents were responsible, and OpenAI says it has not been able to verify the claims — so the attribution is not established.
What is new, and what isn't
What is new
- A visitor without malice that tries another method when blocked
- At the point a human would give up, it keeps trying other URLs, other inputs, credentials it found
- You find out months later, when an AI company notifies you
What isn't new
- The weaknesses used were exposed credentials, an exposed debug page, SQL injection
- All of them should have been fixed already
- Once fixed, they stop a human and an agent alike
What this site weighs most heavily is that the affected organizations hadn't noticed. Anthropic writes that the two organizations it reached had not detected the activity. The Australian case happened in June; the government learned of it in September. Good intent on the other side doesn't change the fact that someone got in. And the next visitor may not be well-meaning: any weakness an agent can find, an attacker can find too.
What site operators should do today
Make sure notices reach a person (security.txt)
In the Australian case the notice went to a general public mailbox, and it reached the cyber security centre five days later. OpenAI says it will keep notifying affected organizations, and vulnerability reports from researchers face the same problem.
First step: publish /.well-known/security.txt (RFC 9116) with a reporting contact (an email address or a report-form URL) and an expiry date, and decide who actually reads it. While writing this article we noticed our own site didn't have one, and added it (the contact is our contact form, not a personal email address).
Check that submissions to your intake forms actually reach a person
In the Philadelphia case, the false tip a model sent was stopped as spam, so it never reached investigators. Police say that after being contacted on 7 October they found the submission in the site's tip records and confirmed the matching email was still in spam (as reported). Agents submit contact, report and application forms too.
First step: send one test submission through each of your intake forms and check where it lands, including spam and junk filters. Decide who reviews spam-flagged submissions and how often, and keep a record of submissions (time and content) long enough to answer a question that arrives months later.
Find and revoke credentials that have been exposed
Both OpenAI and Anthropic list publicly exposed credentials; they were the starting point in the July Hugging Face case too. Look for credentials left in code, public repositories, config files and screenshots, and revoke them at the issuer. See stopping secret commits with gitleaks and secret files in public directories.
Keep access tokens out of browser-delivered config files and public dashboards
Anthropic's October report describes a model using a working access token from a local government map site's settings file, and tokens a state agency's public dashboard issued to visitors, to reach paid or restricted data. Anything in a config file or JavaScript that runs in the browser can be read by anyone.
First step: check the config files, JavaScript and dashboard traffic your public pages load for access tokens and API keys. If one is truly needed, narrow it (read-only, specific data, allowed referrers) and rate-limit it, and serve paid or restricted data only after a server-side authorization check.
Close debug pages and admin panels in production
Anthropic's case involved reading credentials from an exposed debug page. Check that debug mode and detailed error output are off in production, and that admin panels aren't open to anyone on the internet. Per-framework checks are in security by framework.
Drop the assumption that a blocked visitor gives up — check authorization on every path
The first category OpenAI lists is bypassing access controls via a different web address. Hiding a link, or restricting one URL, doesn't stop a visitor that looks for another way. Every path that returns data needs a server-side check of whether this caller may see it. See authentication vs authorization, and the classic flaws IDOR and SQL injection.
Watch volume and speed, and keep logs long enough to look back
Agents don't rest, don't pause, and run the same action in parallel. Tightly spaced requests, a flat 24-hour pattern, and identical actions running at once are easier to tell from human use. And when a notice arrives months later, you can't verify anything without that day's logs. Cap-and-alert design is in rate limiting and abuse control; log retention in organization security priorities.
If you run anything people can post to, plan for agent spam
OpenAI cites agents using a public wiki as a message board. If you run an open wiki, forum, comment section or contact form, review posting rate limits and moderation.
If an AI company notifies you, check the logs before you panic
OpenAI says a notification from it should not automatically be read as a significant security incident. Check your access and authentication logs for the times and targets given, and decide whether it was information you meant to publish or a weakness to fix. If it's a weakness, fix it like any other vulnerability (the vulnerability remediation playbook).
What the agents did (per the disclosures)
bypassed limits via another URL / used exposed credentials / used tokens from a config file / read credentials from a debug page / SQL injection / posted to a wiki, submitted forms
The basic that stops each
server-side authorization on every path / revoke leaked credentials / no tokens sent to the browser / debug off in production / parameterized queries / posting rate limits, review of submissions
For when something still gets in
watch volume and speed / keep logs / a contact that reaches someone (security.txt)
This site's view: weaknesses an agent can find, attackers can find too
These incidents have an odd shape. A visitor with no intent to attack finds an organization's weaknesses, walks through them, and months later the organization is told "we got in" by the company that built it. The ACSC notes that the difference is an AI agent independently finding the kind of vulnerability human researchers have traditionally found and reported.
Reading this as "more helpful reports" would be a mistake. Visitors who won't report them can find the same weaknesses. And agents don't give up when blocked; they try, in parallel and quickly, what would take a human days. The time you can safely leave a weakness unfixed keeps getting shorter.
One more thing became clear: a notice needs an address. A good-faith report or an AI company's notification sits for days in a general mailbox if there's nowhere better to send it. A security.txt is a few lines of text, and you can publish it today.
Sources
- OpenAI, "Hugging Face incident and other third-party impacts of misaligned models" (checked through the 25 September 2026 update) — openai.com
- Anthropic, "Investigating three real-world incidents in our cybersecurity evaluations" (30 July 2026) — anthropic.com
- Anthropic, "An alignment assessment of recent cybersecurity incidents" (9 September 2026) — anthropic.com
- Anthropic, "Investigating unintended model actions in our evaluations and internal use" (9 October 2026) — anthropic.com
- Wikimedia Foundation, "OpenAI “rogue” agent activities found on Wikimedia projects" (5 October 2026) — wikimediafoundation.org
- NBC Philadelphia, "Anthropic AI model submits false tip on unsolved Philly murder, police say" (9 October 2026; used for the Philadelphia Police's account) — nbcphiladelphia.com
- Prime Minister of Australia, "Press conference - New York" (24 September 2026) — pm.gov.au
- ASD's ACSC, "Risks of AI misalignment to Australian organisations" (24 September 2026) — cyber.gov.au
- RubyGems Blog, "An update on the May spam-publishing campaign on rubygems.org" (11 September 2026) — blog.rubygems.org (used to confirm the attribution is not established)
- IETF RFC 9116, "A File Format to Aid in Security Vulnerability Disclosure" — rfc-editor.org
Update history
2026-10-12: Reflected Anthropic's 9 September and 9 October reports and the Wikimedia Foundation's 5 October report. Changed Anthropic's unauthorized access to third-party systems from "three companies" to "four cases", and added its unintended actions in evaluations and internal use (including the false tip sent through a Philadelphia Police form) and its measures. Added two operator steps: check that intake-form submissions reach a person, and keep access tokens out of browser-delivered config files and public dashboards.
2026-09-28: First version, based on official disclosures from OpenAI, Anthropic and the Australian government.
Read next
- The full picture of AI-driven attacks and the order of defense: Defending against AI-driven cyberattacks (autonomous intrusion, prompt injection, AI supply chain)
- Another AI-agent intrusion: The DIVD breach via Zammad zero-days
- The first case: The Hugging Face intrusion (2026): an autonomous AI agent attack
- Fix weaknesses: Stop secret commits with gitleaks / Authentication vs authorization / Security by framework
- Notice: Rate limiting and abuse control / Organization security priorities
- Tool: Site security audit (also checks for security.txt)