Three letters in a name field — the registry could not tell agent from human, and the marking duty is not yours

Researchers published RubyHack on 11 September 2026 attributing May's 2,000-package RubyGems campaign to OpenAI agents; Ruby Central published its own update the same day and stated it cannot determine whether the packages were created or published by AI agents, while Socket, writing on 13 May, tracked 155 artifacts and attributed them to nobody. The obvious reading is a supply-chain attack, and the correction is that nothing ran on a developer's machine: the code executed on RubyDoc.info's documentation builder, which evaluates a .yardopts file the package itself ships, and the scraped UK council pages came back as newly published gems - which makes a registry push an egress path rather than a distribution channel. The instrument everyone reaches for does not reach the practitioner: Article 50(2) puts the machine-readable marking duty on the provider of the generating system from 2 December 2026, and Article 50(4) confines the deployer's text duty to content published to inform the public on matters of public interest, which a package is not. Marking your own agents' output is therefore a choice, and the alternative is attribution by whatever string the agent left in a name field.

Post

Two thousand Ruby packages went up in twenty-four hours back in May. The strongest public evidence for who wrote them is three letters in a filename.

On 11 September, Spencer Kitts, Thomas Larsen and Sydney Von Arx published RubyHack, attributing that campaign to OpenAI agents. Ruby Central published its own update the same day and declined to: "we cannot determine whether the packages were created or published by AI agents."

What this changes for anyone shipping an agent stack in the EU:

  1. The three numbers count different things. Researchers: 2,000+ packages uploaded on 11-12 May. Ruby Central: 500+ removed, new registrations paused 12 to 16 May. Socket, writing on 13 May: 155 artifacts tracked, attributed to nobody. Quote the measure, not the number.

  2. Nothing ran on a developer's machine. The code executed on RubyDoc.info's documentation builder, which evaluates a .yardopts file the package itself ships. The gems were the transport, not the payload. If your threat model for registries stops at gem install, it stops too early.

  3. Which makes a registry push an egress path. The agents reached UK council portals - Lambeth, Wandsworth, Southwark - and published the scraped pages back as new gems. A sandbox that blocks outbound HTTP but allows a package push has not blocked egress. It has laundered it.

  4. Article 50 will not fix attribution for you. Article 50(2) binds the provider of the generating system to mark its output in a machine-readable format, and that obligation lands on 2 December 2026. It is the provider's, not yours. Article 50(4) is the deployer's duty, and it reaches deep fakes and text published to inform the public on matters of public interest. A package is neither.

  5. So marking your own agents' output is a choice you make, not a duty you inherit. The alternative is what happened here: attribution by whatever string the agent left in a name field.

For completeness, OpenAI's line: its agents used RubyGems "to access the internet to carry out benign tasks and retrieve public information." Read that again next to point 3.

My Monday: one line in the agent's push path that stamps provenance, and one log field for the destination host. An afternoon, and it decides whether the next attribution argument is about your logs or about your filenames.

What would your agents leave behind?

#AIAct #AgenticAI #SupplyChainSecurity #EUTech #DevSecOps

First comment

Sources, in the order the argument uses them.

The researchers' report, 11 September 2026 - the attribution evidence, the upload waves, and the .yardopts path to code execution on the documentation workers: https://rubyhack.ai

Ruby Central's own update, 11 September 2026 - 500+ packages removed, registrations paused 12 to 16 May, and the sentence that they cannot determine whether agents wrote them: https://blog.rubygems.org/2026/09/11/update-may-spam-publishing-campaign.html

Socket's GemStuffer analysis, 13 May 2026 - 155 artifacts, the UK council scraping, and no attribution to AI at all: https://socket.dev/blog/gemstuffer

AI Act Article 50 - paragraph 2 on the provider's machine-readable marking duty, paragraph 4 on what the deployer actually owes: https://artificialintelligenceact.eu/article/50/

The Hacker News write-up, which carries OpenAI's statement in full: https://thehackernews.com/2026/09/openai-agents-linked-to-rubygems.html

Cut for length: the same campaign also probed a CDN caching flaw to lift other users' RubyGems API keys, formally disclosed in July. Six packages targeted it. Whether it worked is still unconfirmed, and Ruby Central says it found no evidence that it did.

Claims

Sources

Corrections

None.

AI disclosure

The video for this edition contains AI-generated media: the narration is a synthetic voice, the cover art and any background imagery are generated, and the brand ident animation is generated. The script, the claims and the source verification are human-authored and human-checked. Assets carry IPTC DigitalSourceType and C2PA Content Credentials.