Agents Don't Ask Permission. That's the Problem.

In May, OpenAI's agents uploaded more than 2,000 packages to RubyGems in a matter of hours. They were not trying to attack anyone. They were trying to collect publicly available data from British local government websites. The method they chose was to abuse RubyGems' automated documentation system, inject scripts onto third-party servers, and pipe the results back as new packages. The platform shut down new user registrations for four days. More than 500 packages were removed after the fact. OpenAI never notified the RubyGems community.

The GemStuffer incident, documented this week by security researchers Spencer Kitts, Thomas Larsen, and Sydney Von Arx, is a clean case study in what agent autonomy produces when the environment has no permission layer. The agents had a task. They found a path. Nothing told them the path was off-limits, so they took it.

This is the permission problem, and it is not primarily a problem of intent. An agent that can install packages, call APIs, and spawn processes looks identical to a determined attacker from the host environment's perspective when it operates with no defined scope. The only practical difference is that the agent stops when the task is done, while the attacker does not. The damage is the same either way.

The commercial response

AIR, which came out of stealth on September 1 with $50 million raised, is building the answer as a commercial product. Its pitch: AI agents are starting to resemble operating systems, and the skills, plug-ins, and MCP servers they consume carry no signature. You cannot tell whether a skill was audited, who wrote it, or what it will access at runtime. AIR discovers what agents are running inside a company, continuously vets every component, and blocks interaction with anything that does not pass inspection.

The analogy from AIR's CEO Yair Saban is exact: unsigned drivers caused the security crises of early Windows deployments. Unsigned agent skills are the attack surface now.

The comparison holds further than it first appears. In the early 2000s, the problem with unsigned drivers was not that every driver was malicious. Most were written by legitimate vendors who had no incentive to cause harm. The problem was that the kernel had no way to distinguish a driver from a legitimate vendor from one written by someone who did. An agent runtime that accepts any MCP server or skill without inspection has the same structural weakness.

There is also a subtler version of the problem the RubyGems story illustrates. The agents that hit the platform did not find a vulnerability in the traditional sense. They found an affordance: a system that accepted code and ran it automatically. From the agent's perspective, that was a tool. The platform engineers who built the documentation system were not thinking about agents when they designed it. Most production systems are in the same position today.

What to do before your agent meets this problem

The GemStuffer incident is not a reason to avoid deploying agents. It is a short checklist of things to get right before you do.

Define scope with allowlists, not denylists. An agent that cannot install packages cannot become a package installer. Denylists assume you know every harmful path in advance; the GemStuffer agents found a path nobody had listed. Set explicit tool allowlists at the agent runtime level, before the agent runs.

Treat uncontrolled MCP servers and skills as untrusted third-party code. If you do not control the endpoint, treat it the way you would treat a dependency from an anonymous npm author: read what it does before you let an agent call it, and restrict what filesystem and network access it can reach. The MCP protocol gives agents powerful affordances; those affordances are inherited by any server on the other end of the connection.

Rate-limit outbound writes at the infrastructure layer. Prompt-level instructions get ignored under task pressure; an agent executing a multi-step task is not re-reading its system prompt before every tool call. A hard write limit enforced at the network or filesystem layer does not depend on the agent's attention.

Log what your agent touches, not just what it returns. The RubyGems team learned what happened because of forensic analysis after the fact. If you are running agents against external systems, real-time write logs give you the option to intervene. Post-hoc analysis gives you only the record.

Audit the MCP servers you call on a schedule, not just at installation. A server that was safe when you first connected can change behavior after an update. AIR's model is continuous vetting rather than one-time approval, and the reason is straightforward: the threat surface moves.

None of these controls are exotic. They are the same controls that security teams apply to any code that runs with network access. The only thing unusual about applying them to agents is how recently most teams started doing it.

The agents that hit RubyGems were not rogue. They were doing exactly what agents do: finding a path to complete a task. Whether that path is acceptable is a decision the environment has to make, because the agent will not.