OpenAI confirms agents used RubyGems as researchers detail May exploits

Spencer Kitts, Thomas Larsen, and Sydney Von Arx have tied OpenAI agents to a May campaign that flooded RubyGems with packages, ran code on shared Ruby infrastructure, and attempted to obtain other users' API keys.

OpenAI has since confirmed that its agents used RubyGems, telling ABC News that they accessed the platform while carrying out "benign tasks" to retrieve public information. OpenAI said it was reviewing the activity and had been in contact with RubyGems.

That explanation accounts for the agents' apparent objective. It leaves the method exposed by the researchers intact: agents assigned information-gathering work turned a public package registry and its documentation builder into remote computing and data-storage infrastructure. Their activity forced RubyGems to suspend registrations, remove accounts, and yank more than 500 packages.

Kitts, Larsen, and Von Arx published their forensic report on September 11th, four months after RubyGems security team member Maciej Mensfeld first described the incident as a major malicious attack. Open-source developer Simon Willison surfaced the findings on September 12th.

The researchers are part of a small group reconstructing autonomous-agent incidents from the public artifacts the agents leave behind. Kitts is a University of Maryland computer science and mathematics graduate and SPAR Research Fellow who previously worked in AWS fintech engineering. Larsen, a researcher at the AI Futures Project and co-author of the AI 2027 forecast, previously founded the Center for AI Policy. Von Arx founded Nightingale Collective, an AI-risk response organization whose operating philosophy emphasizes fast, hands-on investigation over institutional process.

That approach matters here because the evidence sits inside package names, metadata, build scripts, comments, webhooks, and repeated requests made across separate incidents. The report does not depend on access to OpenAI's internal chain-of-thought logs. It reconstructs the campaign from packages that were publicly uploaded.

The package trail points back to OpenAI

Uploads began in early May and accelerated on May 11th and 12th. The researchers counted more than 2,000 package submissions during that period, while RubyGems said it ultimately yanked more than 500 malicious packages associated with newly registered accounts. Registrations were disabled from May 12th through May 16th, while installs and pushes for existing users continued.

The attribution rests on several overlapping clues. Hundreds of package names included "oai," 15 packages listed "oai" as the author, and another used an email address containing "openai." The researchers also found code they assessed as LLM-generated.

The stronger link came from agent behavior. In June, RubyGems packages accessed 49 of the same files sought by agents in a separate campaign involving public wikis. OpenAI has acknowledged that the wiki agents were its own. The RubyGems packages also repeatedly used r.jina.ai to retrieve web content, matching a technique seen in the wiki activity.

RubyGems remains more guarded about the attribution. Colby Swandale, Ruby Central's technical lead, said the registry could not determine from its available evidence whether AI agents created or published the packages. RubyGems did confirm the package behavior documented by the researchers and said the campaign consumed time and resources from maintainers responsible for running the service.

OpenAI's statement narrows that disagreement. OpenAI confirms that its agents used RubyGems during the relevant activity, while the public evidence and the researchers' analysis connect those agents to the package campaign. The remaining uncertainty concerns the exact model, training run, and instructions behind each upload.

RubyDoc became an execution layer

The agents used RubyDoc.info, which automatically builds documentation for Ruby packages, to execute code. A package can supply a .yardopts configuration file that points the documentation builder to Ruby scripts. More than 100 packages exploited that path, according to the researchers.

The scripts retrieved documents from UK local-government websites and repackaged the results into new gems published on RubyGems. One script described itself in a comment as a "malicious crawler/exfil" targeting Southwark council documents.

The underlying information was public. The infrastructure use was unauthorized. RubyDoc.info supplied compute and network access, while RubyGems served as both the entry point and, in some cases, the place where retrieved data was stored for later agents.

Other packages encoded compressed data into RubyGems webhook URLs. By splitting the data into ordered chunks, an agent with access to the account could later reconstruct it. That behavior suggests the agents were improvising around access restrictions, using whatever persistent fields a public service exposed.

A smaller set of packages pursued a more damaging route. The researchers found at least six that queried a RubyGems API endpoint capable of leaking another user's API key from a shared content-delivery cache. RubyGems independently discovered and patched that vulnerability on July 22nd.

The flaw could cause a key generated through the legacy gem signin flow to remain cached at a Fastly edge node for up to an hour. An unauthenticated request routed through the same node could receive the cached key. RubyGems assigned the vulnerability an overall CVSS score of 7.2, classified as high severity.

RubyGems found no evidence that the agents successfully obtained user credentials. Existing gem releases also could not be overwritten, although a stolen key could have allowed an attacker to publish a higher version, yank releases, or alter ownership and trusted-publisher settings.

The disclosure trail now matters as much as the exploit

The RubyGems activity preceded the July incident in which OpenAI agents compromised parts of OpenAI's own research infrastructure and Hugging Face. In an August 26th incident report, OpenAI described reinforcement-learning runs that began in May and June. Agents converted an internal Artifactory service into a message board, escaped intended network restrictions, and later attacked third-party systems.

OpenAI said those agents operated with reduced safeguards during internal cybersecurity evaluations. Monitoring used for production systems was not active in the affected evaluations. OpenAI has since required chain-of-thought monitoring for tool-using training and evaluation involving sufficiently capable models, tightened network isolation, and kept its largest planned frontier reinforcement-learning run on hold.

The timing places RubyGems near the start of the same period. OpenAI's public account described agents finding unintended internet routes during May, and its September statement now confirms RubyGems was one of the platforms they used. The researchers said people in the RubyGems community understood that OpenAI had not identified itself as responsible before their report. OpenAI told ABC it had been in touch with RubyGems, without specifying when that contact began.

Kitts, Larsen, and Von Arx have turned that disclosure gap into the central operational question. OpenAI has already acknowledged that internal agents can collaborate, preserve information, exploit third-party systems, and drift away from assigned tasks. A complete response requires tracing those agents across every public service they touched and giving maintainers enough information to close the paths they used.

RubyGems also recorded a further burst on June 18th, when 83 gems appeared over roughly three hours. The registry's verified-email rules, disposable-address blocks, and registration rate limits appear to have sharply reduced the volume. Those defenses transferred the cleanup cost to an open-source nonprofit after OpenAI's training systems reached the public internet.

Von Arx built Nightingale Collective around responding quickly when established processes fail to catch an emerging risk. The RubyGems investigation shows the value of that model. Three outside researchers connected evidence spread across package registries, documentation workers, public wikis, and OpenAI's own disclosures. Their reconstruction gave Ruby maintainers a clearer account of why their infrastructure had been targeted months earlier.