The Package Registry Became the Browser

OpenAI says its agents used the RubyGems software package registry as an improvised route to the web. The destination, according to researchers, included committee calendars and agenda pages from three South London councils. Public records. Available through ordinary websites. The agents took the scenic route.

The Wall Street Journal broke the OpenAI connection on September 11. Reuters followed with the researchers' account and OpenAI's acknowledgement, and security and technology outlets followed. OpenAI confirmed publicly that its agents used RubyGems.

This is a widely reported story. Its unresolved question is how an ordinary information task produced such an extraordinary execution path.

The Journal reported that OpenAI described the agents as generally assigned work such as filling in spreadsheets and creating reports. OpenAI said the RubyGems activity occurred during training and evaluation, and that the agents were retrieving public information. There is no evidence the assigned job was to steal private council records. The target data was already public.

I separately asked OpenAI for its account of the activity and the chronology around it. OpenAI provided a statement, attributable to a company spokesperson, which said: “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.”

That is the strongest version of OpenAI's account: an ordinary assignment, public information, and a training run whose broader review is still open.

The improvised route

Now consider the machinery.

RubyGems hosts reusable software packages for the Ruby programming language. A separate service, RubyDoc.info, builds and displays documentation for those packages. Some gems can provide instructions that cause code to run during the documentation process.

Socket's threat researchers documented the campaign in May under the name GemStuffer. The scripts targeted public ModernGov portals operated by Lambeth, Wandsworth and Southwark councils. They collected calendar pages, agenda listings, committee links and related meeting material. Those portals can also expose linked PDFs and officer contact information. Much of it was publicly accessible from the councils' own websites.

The scripts did not simply download those pages. They packaged the results into new gems and published them back to RubyGems. According to the September analysis, more than one hundred packages used RubyDoc.info's documentation builder to execute code, retrieve web data and return the results through the package registry.

One package left a comment describing itself as a “malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker.” It was substantial technical machinery for obtaining borough council paperwork that a person with a browser could already read.

A secret hunt would at least explain the detour. Public committee schedules do not. The behavior looks less like a coherent plan to acquire secrets and more like an agent system improvising around a missing route to the internet. The objective may have been harmless. The workaround still used infrastructure that did not belong to OpenAI.

What the attribution establishes

The attribution is strong, but it has boundaries.

The September report was written by Spencer Kitts, Thomas Larsen and Sydney Von Arx, publishing at rubyhack.ai. RubyGems says its team reviewed the activity and discussed the findings with researchers from Nightingale Collective.

Their evidence includes two hundred thirty-three package names containing “OAI,” fifteen packages listing “oai” as the author, and one contact address beginning “openaixyz.” They also found retrieval methods and forty-nine June target files overlapping with a separate German-wiki incident that OpenAI had already confirmed involved its agents.

OpenAI confirms its agents used RubyGems to reach the internet. It has not confirmed that every package and effect in the researchers' reconstruction belongs to those agents. RubyGems goes further in stating the limit: based on the evidence available to the platform, it cannot determine whether the packages were created or published by AI agents.

So the evidence supports a firm conclusion about the route and a strong attribution for the campaign. It does not provide a complete package-by-package map from OpenAI's internal run records to RubyGems' public artifacts.

The operational incident itself is not disputed. On May 12, RubyGems paused new account registrations while maintainers blocked accounts and removed more than five hundred malicious packages. Existing gem installs and pushes continued, and registrations reopened on May 16. The platform says responding consumed time and resources from maintainers who also had to keep the service running.

A probe is not proof of a stolen key

The most serious allegation concerns credentials. The researchers say at least six packages probed a caching flaw that could, under specific conditions, expose another user's legacy RubyGems API key. They do not know whether any key was obtained. RubyGems says its investigation found no evidence that those attempts succeeded. Its July advisory also says retained recent logs showed no malicious use, while most of the flaw's historical exposure window could not be reconstructed.

That means three questions remain separate: was the vulnerable path probed, did it return a key, and was any returned key used? The public evidence supports the first. It does not establish the second or third.

The missing chronology

A complete incident report across these events would need to establish when OpenAI identified the activity, when RubyGems and RubyDoc.info were notified, what records or identifiers were supplied, what controls changed before the separate July Hugging Face incident, and whether one chronology will be published. OpenAI says its broader review is continuing. That is a legitimate reason some final dates may not exist yet. It is also why the eventual chronology matters.

RubyDoc.info has already changed its machinery. A public September 11 commit separates plugin download from installation and documentation generation. The system can fetch plugins while the build environment is online, then remove network access before code-executing stages. The change passed tests and reached the production deployment workflow.

That commit does not mention OpenAI, GemStuffer or the May activity. Timing is not causation. Without confirmation from RubyDoc.info's maintainer, it should be treated as a visible security improvement, not a proven response to this incident.

RubyGems' public update answers part of the attribution question. Separate requests from this show to Ruby Central and RubyDoc.info maintainer Loren Segal had not produced further comment by this recording.

What an accountable record needs

Here's what I think. OpenAI's explanation deserves to be represented in full: the agents were doing ordinary work, seeking public information, and operating during a training run that remains under review. But “benign” describes what the company wanted, while everyone outside the company is left to reconstruct what the agent did. Providers need to account separately for the assignment, the route, the artifacts created, the external systems touched, the notice given and the evidence still available. That is the minimum record for an agent that can improvise beyond its intended tools.

The package registry became the browser, with OpenAI confirming that its agents used RubyGems to access the internet. The public record now includes the researchers' attribution of more than two thousand packages, a four-day registration pause, code running through a documentation service, and council records taking a needlessly elaborate trip around the internet. OpenAI has internal records, while the researchers have public packages. RubyGems has a limited platform history, and RubyDoc.info has code changes whose motivation remains unconfirmed.

The remaining question is who holds enough evidence to describe the run accurately before that evidence decays.

If your package registry, open-source project, website or public service has found AI agents using it as an unintended tool, tell me what evidence survived and whether the lab contacted you. Suggested subject line: “Agent route receipts.” Anonymous notes and source-protection requests are welcome. Email me at [email protected]. I read every message.

Listen to Episode 62

Episode 62, “The Package Registry Became the Browser”, is live now.

Download the episode or subscribe to the feed.

Sources

Send tips, corrections, and source notes to [email protected].