Security · AI Agents · Supply Chain
An official AI skill sent tokens to a domain nobody owned
An official OpenAI agent skill pointed production apps at an unregistered domain. What it means for AI agent supply chain risk in your code.
An official OpenAI skill — the instructions an AI coding agent loads to learn how to deploy to Render — told agents that private services live at render-internal.com. That domain belonged to nobody. Security researchers registered it, and it started receiving live, token-bearing calls from production apps. Nothing was hacked. The agents wrote exactly what they were told to write.
This is the clearest case yet of a new kind of dependency: plain-language instructions that end up as code. Your AI-built app now depends on text nobody pins, scans or reviews, and in this case the text was wrong for more than six months.
What happened
According to AIR Security's write-up, published 14 October 2026:
- On 27 January 2026, a commit to OpenAI's official skills repository added a
render-deployskill. Its reference files described Render's private networking as[service-name].render-internal.com, with examples likehttp://internal-api.render-internal.com:10000and a Postgres URL on the same domain. render-internal.comis not Render's domain and, per AIR, appears in none of Render's documentation. It was simply unregistered.- From 13 March the skill shipped bundled in OpenAI's plugins repository, the trusted, vendor-published path.
- AIR registered the domain and pointed it at a passive sinkhole: a server that answers on every subdomain and port and logs what arrives. Real services started connecting, with tokens attached.
- Render removed every reference on 14 August. OpenAI pulled the Render plugin on 26 August. The domain now sits with Render.
CSO Online's coverage calls it a "hallucinated domain". Neither source shows how the wrong name got into the skill. For your risk it doesn't matter: a confident, plausible and false fact sat inside instructions an agent treats as ground truth.
The mechanism: a default that only fires when you forget
The part worth slowing down on is how the bad domain reached production. AIR asked Codex to deploy two services that talk to each other using the skill. The generated code contained this:
defaultInternalAPIURL = "http://existing-internal-api.render-internal.com:10000"
and the deployment config set INTERNAL_API_URL to the same value.
Read it the way a reviewer would. It looks responsible: there's an environment variable, and a sensible-looking fallback. In every environment where someone set INTERNAL_API_URL, the app works and the default never runs. The day a service starts without that variable (a new environment, a renamed secret, a copy-pasted service), the app doesn't crash. It quietly sends its internal API calls, over plain http, to whoever owns that domain.
That's what makes this failure so hard to catch:
- It passes every test you run, because your test environments are configured.
- It's not a vulnerability in any scanner's sense. No CVE, no malicious package, nothing to flag. It's a string literal.
- It reads as correct to a human, because
*.render-internal.comsounds like an internal hostname. Plausibility is exactly what a language model is good at producing. - The cost to exploit it is one domain registration. No intrusion needed: the victims connect to you.
Why "official" didn't help
We trust a package from a known publisher because a whole system stands behind it: versions, lockfiles, checksums, advisories, scanners that diff one release against the next. Skills and agent instructions have almost none of that yet. They're markdown in a repository, loaded at runtime, and they change under you.
So the question to ask is not "is this skill from a reputable vendor?" It was. It's "what does this text cause my agent to write, and would I accept that from a junior engineer without review?" AIR's own advice points the same way: treat every domain, URL, repository and API a skill references as a dependency, and keep checking it.
We wrote recently about shipping code you don't fully understand. This is the version of that problem where the misunderstanding wasn't in the code. It was one layer up, in the instructions that produced it.
What to do this week
None of this needs new tooling. It needs a few rules applied to AI-written code, the same ones you'd apply to code from a contractor you've never met.
- Search the codebase for hardcoded hostnames. Every literal URL or domain in application code and infrastructure config should be one you can name the owner of. A domain you can't trace back to an account you control is a finding.
- Ban network defaults for internal services. If
INTERNAL_API_URLis missing, the service should refuse to start. Failing closed turns a silent leak into a deploy error someone sees in minutes. - Never send credentials over plain
http, internal or not. On most platforms the private network already has a real hostname. Use the one in the vendor's docs, not the one in a prompt. - Restrict egress where you can. A service that should only talk to your database and two APIs shouldn't be able to reach the open internet at all.
- Vet skills and agent instructions like vendored code. Pin the version, read the diff when it changes, and keep a list of which ones your team's agents load.
| Traditional dependency | Agent skill today |
|---|---|
| Versioned, lockfile-pinned | Often loaded from main |
| Scanned for known vulnerabilities | Nothing to scan: it's prose |
| Failure is usually loud | Failure can be a plausible default |
| Reviewed as a diff | Rarely reviewed at all |
This is most of what our production work looks like right now: taking software an AI helped build and finding the places where it's confidently wrong before a customer does.
Key takeaways
- An official OpenAI skill pointed agents at
render-internal.com, a domain nobody owned. Once registered, it received live calls with tokens from production apps. - The bad value reached production as a fallback default, invisible wherever configuration was correct.
- Agent skills are dependencies without the safety net packages have: no pinning, no scanning, little review.
- The fix is ordinary hygiene: own every hostname in your code, fail closed on missing config, restrict egress, and review skills like vendored code.
FAQ
What is an AI agent skill? A packaged set of instructions and reference files that an AI coding agent loads to perform a specific task, such as deploying to a particular platform. The agent treats its contents as reliable guidance.
Was this a hack of OpenAI or Render? No. Nothing was breached. The skill contained an incorrect domain, and anyone who registered that domain could receive traffic from apps built with it. Researchers registered it first and disclosed the issue.
Am I affected if I used the render-deploy skill?
Search your code and deployment config for render-internal.com. If it appears anywhere, replace it with the hostname from Render's documentation and rotate any credentials that may have been sent to it.
Does this mean we should stop using AI coding agents? No. It means code an agent writes needs the same review as code from anyone else, with extra attention to anything that looks like a sensible default.