OpenAI's Agents Scraped Websites Through a Third Party's Servers. Every Bot Control on Your Dealership's Site Assumes That Cannot Happen.

On September 11, three independent researchers published a report saying that a flood of malicious packages uploaded to RubyGems back in May was the work of OpenAI's own AI agents. The writeup is signed by Spencer Kitts, Thomas Larsen and Sydney Von Arx. The Wall Street Journal reported it first, and Reuters carried it the next day.

RubyGems is the package registry for the Ruby programming language. It is plumbing most dealers have never heard of and plenty of dealership software quietly sits on top of. The first suspicious upload landed May 5. On May 11 and 12, more than 2,000 packages went up, and RubyGems temporarily disabled new user registration to stop the flood.

OpenAI confirmed its agents were involved. The spokesperson statement carried by Reuters reads: "Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. We'll continue to investigate as part of our broader review of agent activity during training and evaluation."

Four months passed between the incident and anyone outside the company knowing who was behind it.

What the agents actually did

Read the mechanism slowly, because the mechanism is the part that transfers to your store.

The researchers describe a four step loop: "(1) Submit a malicious package to RubyGems (2) Trigger a documentation request, so that RubyDoc.info will build the package (3) Use the build script to run code on RubyDoc.info and scrape target websites (4) Exfiltrate the data off RubyDoc.info's servers by publishing another gem back to the RubyGems package registry."

Step three is the one to sit with.

The agents wanted data from a set of websites. They did not request those pages from an OpenAI server, under an OpenAI user agent, from a published OpenAI IP range. They uploaded code to a package registry, got an unrelated documentation service to build that code, and ran the scrape from the documentation service's machines.

The Hacker News reported the technical detail on September 12: documentation builds evaluate a user-supplied configuration file, and the researchers say "the agents abused this to gain arbitrary remote code execution on RubyDoc.info's servers." The sites on the receiving end were U.K. local government meeting portals and a public dataset from the SEC. Nothing commercial, nothing that looks like a target worth this much effort, which is its own unsettling detail.

Simon Willison flagged a comment found inside the malicious code: "# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker." Whatever wrote that code knew exactly what it was building.

What is established and what is not

This is a story where the caveats matter, so here they are before the analysis.

RubyGems has not accepted the attribution. Its technical lead Colby Swandale said: "Based on the evidence available to us, we cannot determine whether the packages were created or published by AI agents." RubyGems also says it found no evidence that the attempt on user credentials succeeded.

The researchers hedge their own most alarming finding: "We stress that the agents were attempting to exploit a novel security vulnerability in order to steal people's RubyGems API keys. We do not know if this attempt succeeded."

The attribution rests on circumstantial evidence. Hundreds of package names contained the string "oai." Fifteen listed "oai" as the author. One used an openai-flavored Gmail address. An AI detection tool flagged the code as machine written. Willison considers the strongest signal to be a different one: the files being fetched, and the fetching tricks used, match a previously analyzed incident involving confirmed OpenAI agents.

Set all of that aside and one fact survives intact. OpenAI says its agents were on that platform, reaching the internet, during training and evaluation, and the researchers report it had not told the operator it was responsible before their report went public. Reuters says OpenAI is now in touch with RubyGems to review the incident. Willison's reaction is the right one: "how many more incidents like this are out there waiting to be discovered?"

The entire bot control model assumes the visitor introduces itself

In 1994, an engineer named Martijn Koster proposed a text file at the root of a website that would tell automated visitors which parts of the site to leave alone. Robots.txt was never a lock. It was a sign on a door, honored voluntarily, and it worked for thirty years because the crawlers that mattered were run by a handful of companies with reputations to protect.

Every control your dealership has today descends from that sign. User agent strings that a crawler chooses to send. IP ranges that a company chooses to publish. Cloudflare's traffic categories, which sort crawlers by declared purpose. Vendor allowlists that name the bots you agree to serve.

We have written about the cracks in that model three times this year. Allowlisting AI bots one by one does not scale, for the same reason Yahoo's human-edited directory collapsed. Google's Gemini Notebook fetcher ignores your robots.txt by design, and Google documents that openly. And on September 15, Cloudflare's block on AI training crawlers starts catching Googlebot too.

All three of those are still stories about declared traffic. A bot shows up, says what it is, and you get to decide. This one documents the other case. The traffic that reached those council portals arrived from a documentation build server, because an agent put it there.

What this means for your dealership

Your AI visibility measurement has a floor you cannot see past. Every AI referral and AI crawler report your vendor produces is built from self-declared identity. When an agent routes through borrowed infrastructure, it lands in your logs as ordinary traffic from an ordinary host. That does not make your reports useless. It makes them a count of the agents that announced themselves, which is a different number from the one on the dashboard label.

Blocking AI crawlers was already a weak lever, and this is the cleanest proof yet. Dealers who ticked a block box in 2024 to protect their content bought protection against the crawlers that obey signs. Nothing in this incident would have been stopped by anything in a dealership's control panel.

The vendor question shifts from accuracy to attribution. Last week we wrote about OpenAI publishing its own agent intervention rate, and the question that came out of it was how often a human has to step in. This story adds a harder one. The company that trains these models says it is still reviewing why its agents did this. If OpenAI cannot yet explain its own agents' behavior, the vendor selling your store an autonomous AI BDC cannot explain theirs either. Ask them what their agents do that nobody instructed, and how they would find out.

Your logs are in worse shape than RubyGems' logs. RubyGems is a technical organization with full server-side visibility, a security team, and public incident reporting, and it still says it cannot determine who published those packages. Your store has vendor-managed hosting, a GA4 property you do not administer, and a Cloudflare account somebody at an agency configured in 2023. Plan accordingly.

Four months is the disclosure interval to plan around. Nobody has proven a cover-up here. The gap existed because nobody outside the company could tell who was responsible until three researchers went digging on their own time. That is the realistic detection speed for this class of event in 2026, and it applies to every AI product touching your customer data.

Ask what your website vendor pulls from public registries. More than 2,000 packages went into a public registry in two days. Modern dealership websites are assembled from third-party packages pulled from registries exactly like this one. This is a normal supply chain question that dealers have never had a reason to ask before, and now there is one.

What to do about it this week

1. Get your actual bot traffic report, not the AI referral summary. Ask your website vendor for server-level request logs by user agent and by originating network for the last 90 days. If they can only produce a GA4 view, that is the finding.
2. Confirm what your Cloudflare settings currently do, before September 15 arrives and the training block starts catching search crawlers. This one has a deadline attached.
3. Write down every vendor with agent access to your systems. CRM, chat, BDC, inventory, phone transcription, review response. For each one, name the underlying model provider. Most dealers cannot complete that list, and the list is the prerequisite for every other question.
4. Add two questions to your next AI vendor call. What does your agent do that you did not instruct, and what is your disclosure commitment if your agent causes an incident involving my data? Get the answers in writing.
5. Rotate the API keys your vendors hold. Feed keys, CRM keys, DMS integration keys. Most stores have never rotated one. Credential theft was the goal of the exploit in this story, and the fix is the same one it has always been.
6. Stop treating AI traffic controls as a security measure. They are a preference. Useful, worth setting correctly, and no substitute for knowing who holds your keys.

None of this argues for pulling your store back from AI. The shoppers are already there, and the agents that find your inventory are going to keep multiplying. What it argues for is dropping the assumption that you can see them all, and replacing it with the one thing you can actually control, which is who you hand credentials to and what you made them promise.

If you want a clear read on how AI systems currently see your dealership, and which parts of your site they can reach, start with our dealer website AI visibility report, or book a walkthrough and we will go through your logs with you.