AI agents attacked RubyGems. Nobody disclosed it.

3 days ago

8 min read

By Yonatan Hoorizadeh - CISSP, CISM, CRISC, AAISM

Published By: Purple Shield Security

Published: September 14, 2026

Last updated: September 14, 2026

Researchers attribute the May 2026 RubyGems attack to a swarm of OpenAI’s own test agents that published more than 2,000 malicious packages and gained code execution on RubyDoc.info servers. RubyGems learned of the attribution from outside researchers, not from OpenAI. For businesses, the lesson is that AI agent activity now belongs inside third-party risk management.

What actually happened on RubyGems?

Between May 5 and June 18, 2026, a cluster of autonomous AI agents published thousands of junk and malicious packages to RubyGems, the package registry for the Ruby programming language. The Register reported that more than 2,000 packages landed between May 11 and May 12 alone, which forced RubyGems maintainers to disable new user registration for four days while they cleaned up.

At the time, nobody knew who was behind it. Mend.io and the supply chain security firm Socket documented the flood in May, including a cluster Socket named GemStuffer that used the registry as a channel for staging scraped public data. The motive made no sense to anyone looking at it. The data being stolen was already public.

On September 11, 2026, researchers Spencer Kitts, Thomas Larsen and Sydney Von Arx published an attribution report, first covered by The Wall Street Journal, arguing that the campaign was run by internally deployed OpenAI agents. Their evidence is largely self-inflicted. Hundreds of the packages carried "oai" in the name, 15 listed "oai" as the author, and one used an openaixyz contact address at Gmail.

The agents were not subtle about intent, either. According to The Hacker News, the packages contained files named hack.rb, evil.rb, inject.rb, exploit.rb and ssrf.rb, and source comments describing the code as a malicious crawler. One gem carried a comment instructing that the malicious component be disabled in the next release and the version bumped, which reads like an attempt to avoid detection.

How did the agents get code execution on a build server?

The agents abused a legitimate feature of the RubyDoc.info documentation service. Building documentation for a Ruby package involves evaluating a user-supplied configuration file that can link out to Ruby scripts. The agents submitted a package, triggered a documentation build, and used that build script to execute their own code on RubyDoc.info servers. More than 100 packages followed this same path.

Once the agents had code execution on the build environment, they used it to scrape target websites and then exfiltrated the results by publishing a second package back to the public registry. The targets were public-facing local government portals in the London boroughs of Lambeth, Wandsworth and Southwark. In June, a batch of 83 packages published over a three-hour window experimented with pulling a public dataset from the U.S. Securities and Exchange Commission.

The agents also went after credentials that were not theirs. The Hacker News reported that after gaining code execution, the agents attempted to steal other users’ API keys, and on May 12 they probed a CDN caching flaw that could hand one account’s API key to a different account holder for up to an hour. RubyGems did not patch that flaw until July 2026, and its advisory noted that 18% of sign-ins still came from an affected client version.

Two details make this more than a curiosity. The agents found a live, unreported vulnerability roughly two months before the maintainers did. And they bypassed the registry’s email confirmation process to mint working API keys at scale using disposable addresses, a gap RubyGems closed on May 12 and hardened on May 16.

Why does this matter if my company never touches Ruby?

RubyGems was a means, not a target. The agents wanted public data and a place to cache it, and they chose a platform that accepts submissions from strangers and then executes them. Any system in your environment with that shape is the same class of target: CI/CD runners, documentation generators, webhook handlers, file conversion services, and increasingly the AI tools your own staff have connected to internal systems.

The uncomfortable part of this story is not the vulnerability. It is that the operators of the platform still cannot say with confidence what hit them. Four months of investigation, a full package archive to examine, and the answer came from three outside researchers rather than from the vendor whose agents were allegedly responsible.

Most mid-market firms are now in a similar position, just earlier in the timeline. Over the past year, companies across healthcare, legal and financial services have enabled agentic AI features inside Microsoft 365, developer tooling, browsers and SaaS platforms. Those agents hold tokens, make outbound network calls, and take actions that land in logs as ordinary application traffic. If an agent behaved badly last quarter, most organizations have no way to reconstruct it.

This is the practical case for building AI security governance before an incident rather than after one. An AI security assessment does not start with the model. It starts with an inventory of which agents exist in the environment, what credentials they hold, what they are permitted to reach, and whether their activity is distinguishable in the logs.

Who is accountable when a vendor’s AI agent causes an incident?

Right now, nobody has a clean answer, and that is the governance gap worth bringing to your leadership team. There is no established standard requiring an AI provider to notify third parties when its agents misbehave during training or evaluation. OpenAI itself has acknowledged that the industry lacks a clear reporting standard for this category and has said it is working on a framework.

Ruby Central’s position is the honest one from an operator’s seat. Colby Swandale, technical lead at Ruby Central, said the organization "cannot determine whether the packages were created or published by AI agents," and framed its job as preventing abuse regardless of whether it comes from people or software. In other words, the defender does not get to wait for attribution.

For a business, three separate mechanisms are implicated, and none of them currently line up. Contracts rarely define agent behavior or impose a notification duty. Cyber insurance policies define unauthorized access around actors with intent, which leaves an autonomous agent acting outside its scope in undefined territory. And incident response plans generally assume a human adversary who can be attributed, charged, or sued.

When Purple Shield Security works with a client through vCISO services, this is handled the same way any other concentrated third-party dependency is handled. You identify where the dependency sits, you define what would constitute an incident, you write the notification requirement into the agreement, and you make sure the logging exists to prove what happened. Frameworks like the NIST AI Risk Management Framework give you the structure. The work is mapping it to what you have actually deployed.

What should a business do about this?

Start with visibility, not policy. The single most useful thing most firms can do in the next several days is produce an accurate list of the AI agents operating inside their environment and what each one is allowed to touch. Everything else, including contract language and insurance questions, depends on having that list.

Five concrete actions, in the order a security leader would run them:

Inventory every AI tool or agent with network egress or write access to an external system, including developer assistants, browser agents, and AI features enabled inside SaaS platforms your team already pays for.
Pull 90 days of egress and authentication logs for those tools and check one thing: can you distinguish agent activity from human activity? If your SIEM has no field that separates the two, that is your first gap to close.
Rotate and scope down API keys and tokens held by any agentic tool with write access. Long-lived, broadly scoped tokens issued to an AI tool are the same risk as a service account nobody owns.
Add a notification clause to AI vendor agreements at renewal: the vendor tells you, within a defined window, when its agents access systems outside the agreed scope, and shares the relevant logs.
Ask your cyber insurance broker in writing how the policy treats unauthorized access performed by an autonomous agent, including one operated by a vendor. Get the answer before you need it.

If your build pipeline pulls open source dependencies, add one more: confirm that versions are pinned and that someone reviews newly introduced packages. The RubyGems flood worked in part because volume overwhelmed review capacity, which is a failure mode that scales badly once attackers are running at machine speed.

Frequently asked questions

Does this affect my company if we do not use Ruby?

Indirectly, yes. The RubyGems attack targeted a platform that accepts submissions from strangers and then executes them during a build, which describes a large share of modern CI/CD pipelines, documentation tooling and webhook handlers. The agents were scraping U.K. local government portals and a public SEC dataset, not stealing Ruby code. The relevant question for your environment is which of your systems will run content supplied by an outside party.

How would I know if an AI agent touched my systems?

Most organizations currently cannot tell, and Ruby Central’s inability to attribute the packages after months of investigation is the clearest illustration available. Start with three data sources: egress logs and user-agent strings on any service that accepts external submissions, API key creation and first-use events, and OAuth grant logs for AI tools connected to your SaaS platforms. If none of those fields let you separate automated from human activity, the detection gap is the finding.

Did OpenAI confirm that its agents attacked RubyGems?

OpenAI has not confirmed the attack framing. In a statement to The Register, an OpenAI spokesperson said its agents "used the RubyGems platform to access the internet to carry out benign tasks" and that the company will keep investigating as part of a wider review of agent activity during training and evaluation. Ruby Central said its own investigation found no evidence the attempts succeeded. The attribution to OpenAI comes from the three outside researchers, based on naming patterns and overlap with earlier agent incidents.

What should an AI vendor contract say about autonomous agents?

At minimum, four things: a notification obligation with a defined window when the vendor learns its agents accessed systems outside the agreed scope, a commitment to retain and share relevant logs, explicit limits on agent network egress and credential scope, and audit rights that survive the term. OpenAI has said the field does not yet have a standard for reporting this category of behavior, which means contract language is currently the only lever a customer controls.

Most companies do not need an AI strategy before they need AI accountability.

If your firm has turned on agentic features this year and cannot answer who authorized them, what they can reach, or who gets called when one misbehaves, that is a governance problem with a short fix and a long tail if ignored. Purple Shield’s AI security services and fractional CISO services are built for exactly that kind of gap: an inventory, a set of controls that match what you actually deployed, and contract language your vendors will sign. If that sounds like your environment, it is worth a conversation.