An official OpenAI skill invented a domain, and a production app sent it a token

Every team adopting coding agents has a review habit for dependencies. Someone reads the lockfile, checks new packages, and asks why a library appeared. Almost nobody applies the same habit to the instruction files those agents read: the skills, context files, and guides that tell the agent how to do its job. A disclosure this month shows what that gap costs.

Researchers at AIR Security's Research Lab found a supply-chain flaw in an official OpenAI skills repository. The problem was not malicious code. It was one wrong hostname in a file that agents trust.

What actually happened

The flawed file is the render-deploy skill, which guides coding agents through deploying applications on Render. The skill described render-internal.com as Render's private networking domain. Two facts matter here, and both are simple. The domain was not Render's. And it was not registered to anyone.

AIR's researchers registered render-internal.com themselves and set it up as a passive sinkhole, a server that only listens. They did this after confirming that a coding agent following the skill could copy the domain reference into generated application code and deployment settings. In other words, the wrong hostname did not stay in the document. It travelled into real configuration, the way any instruction in a trusted file does when an agent does the typing.

Then the sinkhole received traffic. A health check arrived, and an API call carrying an authorization token, from a real production application. The app believed it was contacting an internal memory service. It was talking to a domain the researchers owned, because a skill file had told its builder that the domain was internal and safe.

To be precise about what this is not: Render's platform was not breached, and the domain was never Render's to lose. No attacker ran this play. AIR handled the traffic passively and coordinated remediation, and the researchers are clear that neither the model nor the skill was malicious. A trusted instruction file simply contained a confident error, and the error reached production with a token attached.

The skill file is a dependency now

The comfortable mental model treats a skill as documentation. Documentation you read. The agent's mental model is different: a skill is a set of instructions to execute, closer to a build script than to a README. When the file names a domain, the agent writes that domain into code and config. When the file names a command, the agent runs it. The file is part of the software supply chain whether your review process admits it or not.

That reframing explains how a hallucination becomes an incident without anyone writing a line of exploit code. The chain has four links: a model or author invents a plausible hostname, the hostname ships in a trusted repository, an agent copies it into generated configuration, and a production system treats the configuration as ground truth. Human review exists at exactly one of those links in most teams, the last one, and by then the hostname looks like every other setting in the file.

It is worth sitting with the detail that the repository was official. Provenance checks are good practice, and the vetting checklist below includes them, but this case is the counterexample to stopping there. Official sources reduce risk. They do not eliminate it, because the failure mode here is not tampering. It is an authoritative file being wrong in a way that reads as completely normal.

How to vet a skill before your agent runs it

AIR's guidance is the right frame: review agent skills like executable dependencies. Concretely, for any skill, context file, or agent guide you adopt, including the ones covered in our field guide to context files:

• Extract every hostname and URL, then verify each one. A short grep for domain patterns gives you the full list in seconds. For each entry, confirm the vendor actually owns it and documents it for the purpose the file claims. A domain you cannot verify is a finding, not a detail. This single step catches the render-internal.com failure outright: the domain had no owner and no documentation anywhere.
• Read the file like a diff, and re-read it on every update. Skills change. Treat a new version the way you treat a dependency bump: skim what changed, especially commands, endpoints, and anything touching credentials or networking. If a step in the file would surprise you in a pull request, it should surprise you in a skill.
• Pin what you trust. Use a fixed version of a skill rather than whatever is current on the day the agent runs. Pinning does not make a file correct, but it makes its behaviour reproducible and its changes visible.
• Diff the generated output, not just the input file. After the agent works, review the configuration and code it produced for new endpoints, webhook URLs, and environment variables. The skill is the source; the generated config is where the risk lands.
• Put egress rules around secrets. Production tokens should only ever be sent to destinations you have approved. Scoped credentials, allowlisted outbound hosts where your platform supports them, and alerts on calls to unknown domains turn a silent leak into a loud log line. The app in this story had no such tripwire, or it never fired.

None of this requires new tooling. It requires admitting that the instruction layer is code-adjacent and reviewing it with the same suspicion you already apply to a stranger's package.

The takeaway

The old supply-chain lesson was that your application is only as trustworthy as the code you pull in. The agent era adds a clause: it is also only as trustworthy as the instructions you hand the machine that writes and deploys it. A hallucinated hostname is a small error, the kind a tired human reviewer skims past in a long file. In an agent workflow, small errors do not stay small. They get copied faithfully into production configuration and executed at machine speed.

Use AI, and use skills. Just review the file before the agent does what it says.