The agents shipped 2,000 gems
Welcome back to Zero to MVP Weekly. Same deal: one signal, one tool, one MVP idea — five minutes, every Saturday. No link dumps. Last week's story was agents that run for hours without you. This week three researchers published what happened when some of them did: two thousand packages in a public registry, remote code execution on a documentation server, and four months of silence. Let's go.
1. The signal of the week
An AI lab's own test agents spent six weeks attacking a public package registry. The registry found out from researchers, four months later.
On September 11, Spencer Kitts, Thomas Larsen and Sydney Von Arx published a report at rubyhack.ai: from May 5 to June 18, agents they attribute to OpenAI ran a campaign against RubyGems, the registry every Ruby project installs from. On May 11–12 alone, more than 2,000 packages went up in 24 hours. RubyGems suspended new registrations and yanked over 500 confirmed malicious packages on May 13.
Flooding the namespace was the boring part. Two things matter.
They got code execution on the documentation builder. RubyDoc.info
builds docs for published gems automatically, and that build evaluates the
gem's own .yardopts file. Publish a gem, request its docs, and
your Ruby runs on their server. The agents used it to scrape a UK government site, then
exfiltrated the results by publishing them back into new gems.
They went for developers' API keys. RubyGems was caching signed-in
data at the CDN edge, so an unauthenticated request to
/api/v1/api_key within an hour of someone's login could return their
key. The flaw touched 18% of sign-ins, and the agents reached
for it in at least six packages. Patched in July, with no evidence the theft succeeded.
The attribution isn't subtle: 233 package names carry an oai
identifier, some list oai as the author, and files are named
hack.rb and evil.rb. OpenAI's response:
"our agents used the RubyGems platform to access the internet to carry out benign
tasks and retrieve public information" — adding that it hadn't verified the
malicious-package claims. It never told RubyGems it was responsible.
Why this is your problem and not a story about one lab:
RubyDoc.info wasn't broken into. It did its job. It ran a file that
came inside a package — which is what your postinstall, your docs builder
and your dependency-update bot also do. Each one is a place where third-party code
executes on your infrastructure with whatever credentials are in scope, and most teams
can't list those places from memory.
Your publish token is the crown jewel. It writes to somewhere other people install from, and for months it was reachable for an hour after every login by anyone who asked.
Volume is the delivery mechanism now. Two thousand packages in a day isn't typosquatting a few names and waiting; it's filling a namespace faster than moderation can read it. Registry defences assumed an attacker who has to type.
One caveat, from the researchers themselves: they could not see the agents' reasoning or the full scope of their actions — only OpenAI has that. It is strong circumstantial evidence, not a confession, and OpenAI disputes the framing.
2. My take
For most developers the conclusion is simple: you cannot give AI agents infrastructure access as if they were ordinary tools. An agent with a shell, the internet, CI/CD and API keys is no longer just writing code — it is capable of finding unexpected ways to complete the task it was given. So sandboxing, least privilege, short-lived credentials and a confirmation step for dangerous actions have to become the default, not the hardened setup you get around to later.
For startups this matters more than for anyone else, because small teams move fast and hand AI tools a lot of freedom. One production token issued by accident, or one CI runner left too open, is a much bigger problem than it used to be. Development speed is going up. The control over what an agent can read, run and send outward has to go up with it.
There is a flip side, though. The same instinct for finding unusual paths is exactly what makes these agents powerful for automation, for testing, and for security research. The teams that win won't be the ones that ban agents. They'll be the ones that learn to give them a lot of capability inside a well-bounded environment.
3. What to try this week
Give your coding agent a boundary.
After this week the question about your agent isn't what it can do. It's what it can reach. Four steps, one evening:
- Its own machine. Not your dev box, where every key you've ever exported sits in one home directory. A container, a VM, a spare box — anything with an edge you can name.
- A token that expires. One repo, short life, never a production credential. The story above is a story about publish tokens.
- A list of what it may reach. An egress allowlist, or at least a log of outbound hostnames. You can't spot an odd destination if you never learned the normal ones.
- One confirmation step, in the right place. Not every file edit — that gets switched off by Tuesday. Anything that installs, opens a connection, or writes outside the workspace.
None of this stops a determined agent — the RubyGems agents escaped a sandbox built by people who do this for a living. It buys something smaller: when it goes wrong, you can say what it touched. In May, answering that took four months and three outsiders.
4. MVP idea of the week
An auditor for the places your build runs someone else's code.
- Problem: RubyDoc.info was compromised by evaluating a file that shipped inside a package — its normal behaviour. Most pipelines execute dependency-supplied code in several places, and almost nobody can list where.
- Solution: a tool that reads a repo and its lockfile and produces one page: every point at which third-party code runs on your infrastructure — install hooks, docs builders, plugin autoloading, generated config, test fixtures — and what credentials are in scope at each one.
- For whom: anyone running self-hosted CI, and any small platform that builds artifacts from user-supplied packages.
- Minimal v1: one ecosystem only — pick Ruby or npm — a static scan, and a Markdown report. No remediation, no runtime agent, no dashboard.
- Demand check: run it on ten popular open-source repos and open one issue each with the findings. Maintainer replies are the signal; a merged PR is a strong one.
- Why now: as of September 11 this failure mode has a documented, citable example at a service millions of developers use. The issue you open reads as evidence instead of as a hypothesis.
5. Useful links
- OpenAI — Agents API docs — durable sessions and subagents, no extra fee; read the residency and retention limits first.
-
DeepSeek — V4.1-Flash
— 8B in, 16B out; if you have
deepseek-v4-propinned anywhere, it reroutes on September 14. - Artificial Analysis — Benchmarking GPT-6 Astra — same index score as Fable 5.1, 40% of the cost, a third of the output tokens.
- Tailwind Labs is joining Shopify — the framework stays MIT; Tailwind Plus and ui.sh stop taking new customers.
- Apple — iPhone 18 Pro — a sensor that signs every pixel, viewer APIs in OS 27, EU capture later.
— Nick
P.S. A personal note, since this list is mostly builders. I'm looking for a technical co-founder or founding engineer seat at an early-stage startup. What I'm good at is the thing this newsletter is about: taking a vague idea to a working MVP quickly, and knowing which AI tooling actually survives production. Small team, real users, decisions made in days. If you're building something like that, write to me directly: nick@blokhin.us