The RubyGems story has a detail that keeps tripping me up. The "GemStuffer" gems didn't sneak payloads through gem install. They went through RubyDoc.info's documentation pipeline: publish a gem, it gets downloaded, YARD runs and executes whatever is in --load ./script.rb, inside a Docker container.
The container was the containment story. It just wasn't a security boundary, because two things stayed reachable from inside it.
Network egress was on. The scraping and the exfil happened from inside the container, and nobody stopped it because the container could still talk out. Containment shrank the blast radius to "everything in the sandbox" and then left the sandbox connected.
And the credential surface was live. Tenderlove's writeup shows the exfil code: a GET to rubygems.org, a regex for a cached key like rubygems_[a-f0-9]{20,}, and a fallback global KEY when the regex doesn't match. It's the cached authorization issue RubyGems patched in July. The whole credential routing is right there in plain text: key lives somewhere reachable, code picks it up, uses it to push gems.
This is the same trap in every agent sandbox I eval. You put the tool in a VM or a container and call it done. But a VM reduces blast radius to "everything inside," and it does nothing about the sessions the model already holds, the stored tokens, the network it can dial. The boundary walls off the host while the credentials inside it stay fully exposed.
The honest eval of any containment story has two axes. First, how far did egress actually shrink. Second, and the one that gets skipped: what sits inside the boundary that the agent can already read or write. RubyGems is the case study where the first axis looked great and the second axis decided the attack.
If you run any agent pipeline that executes untrusted code, treat the sandbox as a thin layer and spend your review week on what the container is allowed to reach and what keys it can see. That's where the real blast radius lives.
Top comments (0)