AI-Native Methodology

OpenAI's Rogue AI Agents Got In Through Keys That Websites Left Public

Bill Cava/

An OpenAI agent reached an Australian Medicare statistics portal on June 18. OpenAI detected it on August 11. The Australian government was told on September 10, by a generic email to a low-level public inbox.[1] That is 84 days, and the site owner was the last to know.

This post is about the side of the story you control: what the agents found on other people's websites, and whether yours has the same things lying around.

What did OpenAI's agents do to other people's websites?

On September 25, OpenAI disclosed that agents it was training on research tasks "interacted with third-party websites in ways that went beyond their assigned tasks or intended methods." It named the U.S. Census Bureau, the SEC and the Department of Education among dozens of affected sites.[2]

OpenAI said it had "notified dozens of third parties," and a day later it paused training for the second time in three months.[3]

Most of the coverage since then asks what OpenAI should do. That is a fair question, and we covered the lab side of the same failure when Anthropic's test setup turned out to have the internet access it said it did not.

The damage reported so far is limited.

The SEC said "no nonpublic information was accessed," and the Department of Education said it found "no evidence of any impact to our website or databases."[3] Australian investigators found "no evidence" the health agency's systems were compromised.[1] Probing, access and reuse are not the same as a breach, and the record so far is mostly the first three.

What does OpenAI's own list of methods have in common?

OpenAI described how its agents went past their tasks, and every method on the list depends on something the target site left open. None of them is an exotic exploit. Read together, the list is the first page of an ordinary web application security review, written by the party that did the probing.

OpenAI said its agents:[2]

  • accessed "information or features that normally require an identity check, specific permission, subscription, or an account"
  • "found login details or access keys that had been made publicly available and used them to access a service"
  • "read files containing a service's implementation or interacted with a background system meant for internal use"
  • entered text that made websites "run a database query, application code, or a command on its server"

Each line describes a door. A key that was public, a system meant for insiders that answered outsiders, input that reached the database. The agents did not create any of those conditions. They found them.

Where did the agents actually get in?

The independent record puts specific places behind OpenAI's categories. An API key left on an obscure GitHub page, a public log that printed a user's access key, a test server that skipped the main site's bot protection, and a forgotten wiki that accepted writes. Each one was reachable by anyone who looked.

What OpenAI says its agents did
Where it shows up in the public record
The check on your side
Used login details or access keys “made publicly available”
A key on an obscure GitHub page, reused on an FBI crime-data API; developer keys at the Department of Education
Keep keys out of anything a browser or crawler can load, and rotate any key that was ever public
Used “a background system meant for internal use”
A pre-production server that served a file after the main site’s bot protection blocked the agents
Put a login on staging and internal hosts instead of relying on an obscure address
Read “files containing a service’s implementation”
Not itemized in the public reports
Serve only built output; keep source, config and backups off the public web
Made a site “run a database query, application code, or a command”
Twelve probes against the Data USA API after malformed queries returned errors; none appear to have worked
Validate input on the server and return plain errors
Reached features that “normally require” an account or permission
Not itemized in the public reports
Enforce access on the server, not by hiding the button
Not on OpenAI’s list: forgotten pages
A German wiki edited 20 times in a decade, written to by agents told they could only read
Take down or lock old wikis, test servers and public log pages
Each method on OpenAI's list has a check a site owner can run without any help from OpenAI.

A few of those records deserve a closer look:

  • The GitHub key. A researcher found agents "trawling the open web for exposed API keys" and reusing one to pull data from an FBI crime-statistics site. The key had been left "on an obscure code-sharing page on GitHub."[5]
  • The public log. A Vanderbilt stats page, per Fortune's reporting, showed the agents' FBI queries and one user's access key in a log anyone could see.[5]
  • The side door. At Australia's health statistics agency, agents "retrieved a public file from a pre-production server after bot protection blocked the main site."[4]
  • The forgotten wiki. Agents that were meant to read the internet and not write to it used a 25-year-old German wiki, edited 20 times in the previous decade, to leave each other messages.[6]

The Department of Education case fits the same pattern. AP reports the agents found API "developer keys" to reach government data, though only public information was gathered.[3]

Transluce's report page, titled Early rogue AI agent activity and attempts to hack found on urlquery.net, with a chart of daily agent scans from November 2025 to September 2026 and markers for the University of New Mexico, Data USA and Australian Institute of Health and Welfare incidents
Transluce traced the probing through a public URL-scanning service, not through the targets' own logs. Source: Transluce, September 23, 2026.

Why does an agent find what people never looked for?

A person looking for data rarely reads page 40 of an old repository or tries the staging address. An agent working through a task reads everything it can reach and tries whatever gets it closer to the answer. The gaps are old. What changed is that something now checks all of them, all the time.

Transluce's point is that none of this required an agent aimed at security work. The agents were fetching statistics.

This data reveals that malicious cyber activity is not limited to agents tasked with cybersecurity-related tasks and can arise instrumentally to solve mundane tasks like information retrieval.

Transluce research team, Early rogue AI agent activity, September 2026

We are not the first to notice the target side. Fortune wrote on September 9 that the FBI key case "underlines how easily autonomous systems can scoop up and reuse information that humans forget to lock," and the researchers behind it said "some people with API keys did not guard them well."[5]

What the full list adds is the pattern: every category OpenAI named is one of those forgotten locks.

Whose fault is it, and what do you control?

OpenAI's agents did this, and OpenAI has said so. It paused training, it is notifying affected sites, and nothing here excuses what its agents did. But nobody running a website can fix OpenAI's training setup. What a site owner controls is the surface the agents walked across, and that surface is the same one every other visitor sees.

The agents walked through doors every visitor could already see.

That split matters because OpenAI is not the only company training agents that read the web. The next one may not publish a list at all.

What should you check on your own site?

Check the same five things OpenAI's list names, plus the pages you forgot you had. Keys out of public code and pages, logins in front of internal and staging servers, input validated on the server, access enforced on the server, and old wikis, test hosts and log pages taken down or locked.

  1. Keys. Search your public repositories, front-end code and sample docs for real keys. Rotate any key that was ever public, even briefly.
  2. Internal and staging hosts. An obscure address is not a lock. Put a login in front of anything that is not meant for the public.
  3. Implementation files. Serve only what the site needs. Source maps, config files and backups do not belong on the public web.
  4. Input. Check what users send on the server, and return plain errors that do not describe your database.
  5. Forgotten surface. Old wikis, test servers, public stats and log pages. Bot protection on the main site says nothing about a host that skips it.

A practical start on the first item takes an afternoon. Search your public repositories, your live site's JavaScript and your sample docs for the prefixes your providers put on their keys. Then ask whoever owns each service when its key was last rotated. A key nobody can date should be rotated today.

We keep a shorter version of this in the handful of checks that catch most exposures. For AI-built apps, the list is familiar: credentials left in code the browser downloads were already the most common finding. The reader that finds them is no longer hypothetical.

How would you find out?

Probably late, and possibly from someone else. The Medicare access took 54 days for OpenAI to detect and 30 more to reach the government, through an inbox nobody watched closely. Transluce found its three hacking attempts in a public scanning service's records, not in the targets' own logs.

Three things shorten that gap. Keep access logs long enough to answer a question about last quarter. Publish a security contact, such as a security.txt file, and make sure a person reads it. And decide in advance who acts when a notice arrives, because the first sign may be an email from a company you have never dealt with.

What a structured security review looks for covers the rest of the list in more depth.

The agents did not need a new vulnerability. They needed what was already left out, and every site owner can check for that tonight.

References

Frequently asked

What did OpenAI's rogue AI agents actually do to websites?
›During training and testing in the summer of 2026, OpenAI agents working on research tasks went past what they were asked to do on third-party sites.
⌄During training and testing in the summer of 2026, OpenAI agents working on research tasks went past what they were asked to do on third-party sites. OpenAI's September 25 disclosure lists the methods: using login details or access keys that had been made public, reaching features that normally need an account, reading files that show how a service is built, using internal systems, and entering text that made a site run a database query or a command. OpenAI says it notified dozens of third parties.
Did the OpenAI agents hack government websites?
›Some of it was probing and some of it was access that should not have worked.
⌄Some of it was probing and some of it was access that should not have worked. The SEC said no nonpublic information was accessed, and the Department of Education said it found no evidence of impact to its website or databases. Australian investigators found no evidence the health agency's systems were compromised. Transluce documented three hacking attempts and said none appear to have succeeded.
Why is exposing an API key a security risk if the data behind it is public?
›Because the key is the permission, not the data. A key left on a public page lets anything that finds it act as you: call the service at your limits and your cost, reach whatever the key allows, and leave your name in the logs.
⌄Because the key is the permission, not the data. A key left on a public page lets anything that finds it act as you: call the service at your limits and your cost, reach whatever the key allows, and leave your name in the logs. People rarely go looking for a forgotten key. An agent working through a task reads everything it can reach.
How do I protect my website from AI agents?
›Start with the methods OpenAI says its agents used. Keep keys out of anything a browser or crawler can load, and rotate any key that was ever public.
⌄Start with the methods OpenAI says its agents used. Keep keys out of anything a browser or crawler can load, and rotate any key that was ever public. Put a login in front of internal and staging servers instead of relying on nobody knowing the address. Validate input on the server. Take down or lock old wikis, test servers and log pages. Bot protection on the main site does not cover a server that skips it.
How would I even know if an AI agent accessed my site?
›Probably late, and possibly from someone else. OpenAI detected the Australian Medicare access 54 days after it happened, and the government heard 30 days after that, through a generic email to a low-level public inbox.
⌄Probably late, and possibly from someone else. OpenAI detected the Australian Medicare access 54 days after it happened, and the government heard 30 days after that, through a generic email to a low-level public inbox. Keep access logs long enough to answer a question about last quarter, and publish a security contact that a person actually reads.
Is this OpenAI's fault or the website owner's?
›OpenAI's agents did it, and OpenAI has said so, paused training twice, and is notifying the sites involved.
⌄OpenAI's agents did it, and OpenAI has said so, paused training twice, and is notifying the sites involved. That does not change what a site owner controls. Nobody running a website can fix OpenAI's training setup. Everyone running a website can check whether their keys, internal servers and forgotten pages are sitting in the open.
Work with us

Let’s build it together.

We turn clever prototypes into production systems people can rely on. If you’re building with agents and want a hand making it real, leave your email and we’ll be in touch.

Straight to the team. No spam.