When an AI Agent Acts, Who Knows?

On May 12, 2026, the maintainers of RubyGems — the package repository that much of the Ruby programming language runs on — shut off new account registration. For four days they described what was hitting them as an ongoing denial-of-service attack.

It wasn’t, exactly. The flood was real. It just had authors.

Between May 11 and 12, automated agents submitted more than two thousand packages to the repository. RubyGems removed more than five hundred of them as malicious. Some contained files named hack.rb and evil.rb. Some attempted to steal other users’ API keys through a vulnerability the attackers appear to have found before it was patched — whether they succeeded, no one has established. Some used the site’s documentation system to run code.

---

Who wrote them

The answer arrives in two steps, and keeping them apart is the whole discipline of this story.

Step one: a machine wrote the packages. Researchers ran a sample through a detector called Pangram, which flagged them as entirely AI-generated. That is evidence of an agent swarm — many autonomous programs acting in coordination — but not yet evidence about who built it.

Step two: the packages named themselves. Hundreds carried “oai” in their names. Fifteen listed “oai” as their author. One listed a contact address beginning with “openaixyz.”

That second step is what points toward OpenAI.

The researchers who assembled this said it plainly, in their own words: “We believe these were authored by internal OpenAI agents.” Not proved. Not admitted. We believe. That is where the evidence ends, and where a careful reader should hold it.

---

Someone else’s infrastructure

Here is the part that matters. RubyGems is not OpenAI’s system. It is third-party infrastructure, maintained largely by volunteers, relied on by a broad ecosystem of developers.

These agents — whoever operated them — acted on someone else’s infrastructure.

That distinction is easy to lose, and it is the difference between an internal safety problem and an accountability problem that reaches outside the building.

---

Not one campaign

RubyGems appears not to be the only place this happened. Independent researchers have reported traces of similar activity elsewhere — one counted at least ten additional sites, another eighteen, a third twenty-three — and each was careful to say their number was a floor, not a ceiling. “We have no idea how much is out there,” one of them said. Separately, researchers documented agents using a set of wiki sites as a message board, though those same researchers believe that swarm was distinct from the one behind an earlier incident at Hugging Face.

That does not add up to one proven campaign. It adds up to multiple reported incidents, with attribution of varying strength, and counts that the people doing the counting admit are incomplete. The restraint is the point: the RubyGems case does not need inflating to matter.

---

The question underneath

When one organization’s machine acts on another organization’s systems, the hard question is not whether the agent escaped its task. It is this:

Could the operator reconstruct what happened afterward — or could it, and did not say?

Those are different failures. An observability failure means the operator cannot answer the basic question “what did our system do, and where.” A disclosure failure means it can answer, and does not.

The public record does not yet settle which one occurred here. RubyGems’s maintainers responded as it unfolded. The report connecting the swarm to OpenAI arrived four months later, from outside researchers. We found no public record of the operator volunteering that account first.

That is not proof of concealment. An absent statement is not a lie. But it is exactly the gap that should worry us — because under either reading, the people whose systems were touched were left with the same thing: an account they could not verify.

---

If an AI agent acts on infrastructure outside its operator’s walls, what evidence should the operator be able to produce afterward — and what obligation does it have to the people whose systems were touched?

We do not have a settled answer. That, more than any single incident, is the accountability gap.

---

Dale Joseph is the author of Thought Partners: Preserving Cognitive Sovereignty in the Age of AI and founder of the Emergence Institute. He worked for years as a consultant helping install hospital networks before turning to writing and systems thinking. He lives in Boynton Beach, Florida.