al-ice.ai

The Official Skill Pointed at a Stranger’s Domain: OpenAI’s render-deploy Taught Agents to Send Tokens to render-internal.com

Agent & Supply Chain Security by al-ice.ai Editorial

On 14 October 2026, Air Security published “OpenAI Sesame”: a skill-supply-chain finding with something most scanner-bypass papers lack — live victims. One of the skills in OpenAI’s official GitHub skills repository, render-deploy, taught agents that Render’s private services live under the domain suffix render-internal.com. That domain was not Render’s, appeared in none of Render’s documentation, and was available for anyone to register. Air registered it, pointed it at a passive sinkhole, and watched real production applications connect to it — sending requests and credentials to infrastructure the users believed was their own private network.

A single resource reference, presented as fact

The poisoned instruction sat in references/service-types.md: “Private DNS: [service-name].render-internal.com”, followed by copy-paste code — const API_URL = 'http://internal-api.render-internal.com:10000' — and reinforced in references/configuration-guide.md with a database URL in the same shape (postgresql://user:***@postgres.render-internal.com:5432/db). Air’s write-up stresses the mechanism that makes this worse than a typo in docs: the agent does not merely read the skill, it carries the domain into generated application code and deployment configuration. Their reproduction asked Codex to deploy two communicating services with the skill, and the domain surfaced in both the generated app and its envVars — used as the default whenever runtime configuration did not override it. Per Air, the guidance had been in the skill since its initial commit on 27 January 2026, and the skill had been bundled into openai/plugins since 13 March 2026.

The sinkhole proved it was not theoretical

After the Codex reproduction, Air registered the domain and answered every subdomain and port while recording incoming traffic. What arrived was not their own test traffic: live, token-bearing calls from actual applications that used the domain exactly as the official skill instructed. That is the line between “a misleading doc” and a compromise path — any party that registered the domain first, rather than a security vendor running a passive sinkhole, would have collected production API tokens without touching a single agent. Air disclosed to both vendors: Render acknowledged quickly and, per Air, removed every render-internal.com reference on 14 August 2026 (commit 5152e543); OpenAI followed on 26 August 2026 by removing the Render plugin from openai/plugins (commit 33bd9529). The domain was transferred to Render’s safe holding.

What we independently confirmed — and the wrinkle

We verified the parts of this story that can be checked from the outside. The openai/plugins removal checks out: the plugins/render directory (9 entries) exists at the parent of commit 33bd9529 and is gone at that commit, dated 26 August 2026. Domain registration data is consistent with the safe-holding account: render-internal.com is currently registered through Amazon’s registrar on AWS nameservers, with a last-changed date of 24 August 2026 — days before the plugin removal. Render’s own private-network documentation, which we read first-hand, describes per-service hostnames and internal URLs, with no shared render-internal.com suffix anywhere in the visible text — consistent with Air’s report that the suffix came from the skill, not the platform.

The wrinkle: the misleading text is still shipping today. The current main branch of openai/skills still contains every quoted string — the Private DNS line, the internal-api.render-internal.com sample, the “always use .render-internal.com” instruction, the postgres URL — in both reference files, whose file history shows no August fix commit. Code search shows the same text copied onward into third-party skill catalogs and registries. Air’s “removed every reference” commit evidently landed in a different copy of the skill than the curated tree that still serves it. The saving grace is architectural rather than editorial: because the fix happened at the domain layer, stale copies now point at Render-held infrastructure instead of an attacker sinkhole. That is the right layer to have fixed — and a demonstration that skill text, once forked, is effectively unpatchable, the same lesson as the placeholder domain that sat in 1,700 repos serving ClickFix, and the reason the APM lockfile and scanner-gated install model treats skill content as dependencies to be pinned and re-validated rather than prose to be trusted.

Why this one matters more than the average bad doc

Three properties stack here. First, provenance laundering: the instruction arrived inside an OpenAI-owned repository, so agents and users applied no skepticism — the exact failure mode the VirusTotal hidden-instruction study and the 2.2-million-copy skill lineage census warn about, except no adversary was even required. Second, code-generation amplification: the bad string did not stay in chat — it compiled into defaults in shipped applications, converting one wrong sentence into persistent credential exposure. Third, first-registrant-wins economics: the window ran from January to August, and anyone watching skill repos for unregistered domains could have owned it; the unpinned-MCP measurement shows attackers already harvest this ecosystem systematically. Air calls it the first demonstrated skill vulnerability to compromise real user infrastructure without touching code or packages — the agentic supply chain’s own class of bug — and on the evidence, the label fits.

What to actually do

  1. Treat every domain, URL, repository and account named inside a skill as a dependency: resolve ownership at intake (WHOIS/RDAP, docs cross-check) and re-check it continuously, because a transfer or expiry re-opens the hole.
  2. Grep your own skill mirrors, forks and vendored catalogs for render-internal.com and any other hardcoded “internal” suffixes; stale text is now harmless here but the habit is the vulnerability.
  3. Pin skills and validate external references on a schedule — the dependency posture Microsoft’s APM manifest is pushing toward — rather than trusting official-repository provenance as a permanent property.
  4. If you generate deployment configuration with agents, require human or policy review of any default URL the model supplies rather than only the values the operator typed.

Our verification was read-only. We read the Air Security “OpenAI Sesame” report first-hand (published 14 October 2026, modified 16 October 2026) including its quoted skill excerpts, reproduction description, sinkhole results, disclosure timeline and remediation claims. Independently, via the public GitHub API, we confirmed openai/plugins commit 33bd9529 (26 August 2026) removes the plugins/render directory (present with 9 entries at its parent, absent at the commit); via raw file fetches we confirmed the render-internal.com strings remain in openai/skills main (skills/.curated/render-deploy/references/service-types.md and configuration-guide.md) with no August commit in those files’ history; via Verisign RDAP we confirmed render-internal.com is active on Amazon-registrar/AWS nameservers with registration 10 June 2026 and last-changed 24 August 2026. Render’s private-network documentation page was read first-hand. The August-14 skill-side fix commit is carried as reported by Air; the skill’s January and March arrival dates are likewise Air’s account. We registered nothing, ran no sinkhole, deployed nothing to Render, and contacted no vendor. Brave Search was used for discovery only.

Sources: