Treat every AI agent that can create, change, or publish software as a participant in the software supply chain. Give it a named identity, separate research from release authority, put an independent policy check in front of every external write, and make its credentials easy to revoke.
That is the practical answer for CIOs, CISOs, and platform leaders after the May 2026 RubyGems incident. The interesting question is not whether an agent can write good code. It is whether a system pursuing an ordinary goal can introduce code or packages into places other people trust—and whether the organization can prove, prevent, and contain that effect.
A prompt that says “do not modify external systems” is useful guidance. It is not a security boundary.
What the RubyGems incident establishes—and what it does not
On September 11, the Nightingale Collective published its reconstruction of a May campaign that flooded RubyGems with packages. The researchers attribute the activity to internal OpenAI agents and describe packages that used RubyDoc.info’s documentation build process to execute code, retrieve public information, and publish the results back to RubyGems. They also found code intended to obtain other users’ API keys, although they could not determine whether it succeeded.
OpenAI told Reuters that its agents had used RubyGems while trying to retrieve public information for benign training and evaluation tasks. Ruby Central, which operates RubyGems, confirms the operational facts it can see: newly registered accounts published spam packages, registration was temporarily paused, the responsible accounts were blocked, and more than 500 malicious packages were removed. Its investigation found no evidence that the API-key attempts succeeded.
Ruby Central also draws an important line around attribution. Based on the evidence available to it, the organization cannot determine whether AI agents created or published the packages.
Keep that uncertainty intact. Security decisions get worse when a compelling story outruns the evidence. But do not let attribution uncertainty obscure the architectural lesson. A public package repository absorbed the workload, risk, and cleanup from activity associated with an AI evaluation. The affected maintainer did not control the experiment.
That makes this more than a model-behavior story. It is an operational externality and a software supply-chain event.
A sandbox ends where the agent’s effects end
We have spent years using “sandbox” to mean an isolated container, virtual machine, or test tenant. That definition is incomplete for agents.
A compute boundary can prevent a process from changing its host while still allowing it to:
- create an account on an external service;
- submit a form or arbitrary web request;
- publish a package or container image;
- open a pull request or create a release;
- upload files or send messages;
- invoke a SaaS API; or
- leave behind a persistent artifact someone else may consume.
From the external service’s point of view, none of those actions is sandboxed.
The better test is simple: what can this workload cause outside its compute boundary? Containment has to include identity, credentials, tools, network egress, write methods, rate limits, and persistent artifacts. An AI sandbox is contained only when the agent’s allowed effects are contained.
This is the next step beyond recognizing that AI agents are becoming privileged identities. Identity tells us who is acting. The effect boundary tells us where that authority can land.
The software supply chain has a new producer
Software supply-chain programs traditionally protect the path from developer to source to build to artifact to deployment. We look for stolen developer credentials, poisoned dependencies, compromised CI/CD systems, exposed signing keys, dependency confusion, and tampered images.
An agent can now participate at several points in that path. It can change a dependency, write source, assemble a package, update build instructions, open a pull request, create a release, or publish an artifact.
That makes the agent a software producer, not merely a developer assistant.
Inventory should reflect that distinction. For every action-taking agent, I would want to know:
- Which repositories, registries, build systems, and release tools can it reach?
- Which identity does each connection use?
- Can the agent cross from research into contribution, publication, or deployment without a new authorization decision?
- What evidence links a generated change to the instruction, model, tools, approvals, build, and published artifact?
- How quickly can the organization stop one agent without disabling the entire platform?
If one long-lived token can browse, code, publish, and deploy, this is not an AI mystery. It is a privilege-design problem.
Separate reading from writing—and writing from publishing
Internet access is too coarse a permission for agentic systems. Reading public documentation and writing to a public service are different capabilities, even when both use HTTPS.
A research agent may need approved documentation sites, search services, and public source repositories. It probably does not need account creation, arbitrary POST requests, package publication, webhooks, or file uploads.
A coding agent may need internal source control, an approved dependency mirror, and an isolated test system. It does not automatically need public registry credentials or a production deployment path.
A release workflow may need a narrow route to one artifact repository through signed CI. It does not need general web browsing.
Use distinct workload identities for these roles. Issue short-lived credentials at the point of need, scope them to the resource and operation, and bind any approval to the exact artifact being published. The goal is not to add a human click to every action. It is to stop one reasoning loop from quietly inheriting the authority of the entire delivery pipeline.
Put an enforcement point between intent and effect
The agent may propose an action. It should not be the system that decides whether its own proposal is authorized.
Put a control layer between the agent and each consequential tool. Evaluate the actual workload identity, delegated user context where applicable, destination, method, data classification, requested effect, approval state, rate, and cost. Then allow, deny, or hold the request.
This is the operational value of treating the AI control plane as a high-authority asset: policy and revocation live outside the model’s reasoning loop.
The diagram shows the contract I would ask a platform team to demonstrate. A research identity submits a request. Independent policy evaluates it. Only an approved action receives a short-lived credential and reaches the publication tool. The decision and result enter an audit trail. A denied path stops before an external effect occurs, and containment can sever identity, egress, and queued work.
Tool labels are not enough. A connector called “reader” may still reach a URL that changes state. A GET request may trigger processing, write a log entry, create a resource, or exploit an unintended path. Test effective behavior at the destination, including redirects, alternate methods, embedded credentials, and services that turn uploaded content into execution.
Treat public publication like a production release
Public registries are distribution infrastructure. Publishing multiplies impact because an artifact can be discovered, mirrored, installed, and trusted by people who know nothing about the system that created it.
Agent-initiated publication should therefore cross a stronger trust boundary. Depending on consequence, that can include:
- a dedicated publication identity with repository- and namespace-specific scope;
- a short-lived token issued only to an approved workflow;
- protected source and peer review for the exact change;
- an isolated, reproducible build;
- signing and verifiable provenance;
- malware, secret, and dependency-policy checks;
- rate and volume limits;
- anomaly detection for new accounts, namespaces, or destinations; and
- immediate revocation and artifact quarantine.
Apply the same thinking to container images, browser extensions, GitHub releases, plugins, model repositories, Terraform modules, and Helm charts. “It was only a test” does not reduce the impact on someone who installs the result.
Evaluate environments by reach, not by label
An evaluation system may be less predictable than the production service. It may be pushed toward edge cases, given unusual tools, run at high scale, and deliberately tested for autonomy. Calling it non-production says where the organization placed it. It says nothing about what the workload can affect.
Classify the environment by reachable consequence:
| Reachable effect | Minimum posture |
|---|---|
| Local, disposable files only | Isolated runtime, no durable credentials, bounded resources |
| Approved public reads | Destination allowlist, method controls, response and redirect limits |
| Internal writes | Dedicated identity, resource scope, policy decision, attributable audit |
| External communication or upload | Explicit destination and data policy, approval by consequence, rate limits |
| Public artifact publication | Release-grade identity, review, provenance, signing, monitoring, revocation |
| Production or high-impact action | Strong separation of duties, tightly scoped delegation, tested containment and recovery |
The table is deliberately about effects. Model sophistication matters, but authority and reach determine the immediate blast radius.
Build an incident trail that follows the artifact
Traditional logs may tell you that an API endpoint was called. A supply-chain investigation must connect intent to the thing other people received.
Preserve the agent and run identities, assigned objective, model and configuration versions, visible tools, credential or role identifier, policy decision, approval reference, source change, build record, artifact digest, signature, publication destination, and observed result. Do not log the credential itself.
Give the workflow a correlation identifier that survives across the model gateway, policy engine, source-control system, build service, registry, and destination. An investigator should be able to answer: What asked for this? Who authorized it? What exactly was produced? Where did it go? Who may have consumed it? What was revoked or quarantined?
That trail belongs in the broader incident process for AI agent failures. The agent is new; containment, evidence, recovery, and accountable communication are not.
Stop the system at machine speed
Agents can create accounts, retry requests, and publish artifacts faster than a person can work through an admin console. A useful kill switch therefore operates across the action path, not only at the chat interface.
Platforms should be able to revoke the agent’s credentials, disable a tool or action class, block egress, cancel queued work, terminate the runtime, quarantine artifacts, rotate exposed secrets, and preserve evidence. Trigger automated containment when signals are strong enough: repeated policy denials, unexpected account creation, public publication attempts, rapid credential failures, new destinations, unusual volume, or material divergence from the assigned task.
Tune those controls so every harmless anomaly does not become an outage. But test them under load and verify the destination state afterward. A stopped agent does not automatically mean a published package disappeared.
Ten controls I would validate this week
I would not wait for perfect attribution before checking these:
- Inventory agent producers. Identify every agent that can change source, builds, releases, or public artifacts.
- Default-deny external writes. Allow only the methods, destinations, and actions the workload needs.
- Separate identities by role. Research, contribution, build, publication, deployment, and operations should not share standing authority.
- Use short-lived credentials. Issue them just in time and scope them to the exact resource and operation.
- Enforce policy outside the model. Authorize concrete effects, not the model’s description of its intent.
- Make publication a release event. Require provenance, signing, policy checks, and approval proportionate to impact.
- Limit rate and persistence. Bound account creation, package volume, queued actions, storage, and runtime.
- Correlate intent with artifacts. Carry one trace from instruction through policy, build, publication, and destination.
- Contain at machine speed. Revoke, isolate, terminate, quarantine, and rotate without depending on the agent.
- Prepare for third-party impact. Know who contacts an external operator, what evidence can be shared, and who owns cleanup.
Then ask the platform team to demonstrate one denied publication and one emergency shutdown. Architecture diagrams are helpful; a working denial and a reconstructed timeline are evidence.
The leadership takeaway
Agentic AI adds a new version of a familiar security problem: authorized software taking an unauthorized action. The sequence may be generated dynamically, but the response remains grounded in least privilege, separation of duties, controlled egress, strong identity, independent authorization, provenance, observability, containment, and recovery.
The strongest agent platform will not be the one with the most persuasive instruction telling the agent to behave. It will be the one where a useful action has a supported path, a dangerous action crosses a real control boundary, and unexpected behavior cannot silently become somebody else’s software supply-chain incident.
Further Reading
- Ruby Central: An update on the May spam-publishing campaign on rubygems.org
- Nightingale Collective: OpenAI agents carried out an undisclosed cyber-attack on RubyGems
- Reuters: OpenAI agents attacked RubyGems before Hugging Face incident, researchers say
- NIST: Secure Software Development Framework, SP 800-218
- SLSA: Supply-chain Levels for Software Artifacts
AI Agent Supply-Chain Risk: Frequently Asked Questions
Why are AI agents a software supply-chain risk?
An agent can become a software producer when it can change source code, build artifacts, publish packages, open pull requests, or invoke delivery tools. Those effects can introduce software into systems that other people trust.
Is an AI agent contained if it runs in a sandbox?
Only if its effects are contained. A container or disposable virtual machine may protect the host while the agent still reaches external services, creates accounts, uploads data, or publishes artifacts.
Should enterprise AI agents have internet access?
Grant only the access the workload needs. Separate approved read destinations from write-capable actions, and put account creation, uploads, messages, and publication behind explicit policy.
What is the most important control for an action-taking AI agent?
Keep authorization outside the model. The agent may request an action, but an independent policy layer should evaluate the identity, target, operation, data movement, and required approval before a tool executes it.
