A hallucinated URL in OpenAI's official skills repository directed AI agents to send data to an unclaimed domain for seven months. This vulnerability, present from January through mid-August 2024, exposes a critical gap in how you and your team vet AI components, even those from trusted vendors.
What Happened
OpenAI's skills repository included a Render deployment skill that referenced a non-existent domain. When developers integrated this skill, the code instructed agents to send deployment credentials and configuration data to a URL that OpenAI never registered.
AIR Security discovered the flaw, registered the hallucinated domain, and set up a sinkhole to monitor incoming traffic. They reported their findings to both OpenAI and Render, who resolved the issue. Although there was no evidence of prior malicious exploitation, the potential risk was significant.
Timeline
January 2024: Commit introducing the hallucinated domain merged into OpenAI's skills repository.
January, August 2024: Vulnerability remains live; any deployment using this skill would transmit data to the unclaimed domain.
Mid-August 2024: AIR Security registers the domain, establishes monitoring, and reports the finding.
August 2024: OpenAI and Render patch the vulnerability.
Which Controls Failed
The incident revealed three critical control failures:
Pre-deployment validation: There was no automated check to verify that referenced domains were owned by the skill publisher. The repository accepted code pointing to external infrastructure without confirming ownership or operational status.
Dependency integrity verification: The skills repository lacked mechanisms to ensure that third-party resources (domains, APIs, endpoints) belonged to authorized parties. This reflects a broader supply chain issue where package names are trusted without verifying contents.
Continuous monitoring: No alerts were triggered when code referenced infrastructure that didn't resolve or respond as expected. The hallucinated domain remained dormant until a researcher claimed it.
These gaps aren't hypothetical. AIR Security's research on skills.sh documented a Trojanized AI skill with 1.7 million installations. Attackers target AI instruction files and credentials. The OpenAI incident avoided exploitation, but the attack surface is well understood by adversaries.
What Standards Require
OWASP ASVS v4.0.3, Requirement 14.2.2 mandates verifying the integrity of third-party components and dependencies. For AI skills, this means validating not just the code but every external resource it references.
NIST 800-53 Rev 5, Control SA-12 (Supply Chain Protection) requires using integrity verification tools to detect unauthorized changes to software, firmware, and information. When you pull AI skills from a repository, you're accepting third-party code that needs the same scrutiny as any other dependency.
ISO/IEC 27001:2022, Control 8.30 (Outsourcing) addresses risks in third-party service relationships. AI skills that reference external domains create an outsourcing relationship by proxy, delegating data transmission to infrastructure you don't control.
SOC 2 Type II, CC6.6 requires monitoring vendor management processes. If your AI applications use skills from external repositories, those repositories are vendors. Your monitoring should extend to the resources they reference, not just the code they publish.
Lessons and Action Items
Implement domain ownership verification before deployment. Before integrating any AI skill, enumerate every external domain it references. Verify that each domain resolves, responds appropriately, and belongs to the claimed owner. A simple DNS check isn't enough; confirm the resource is operationally controlled by a trusted party.
Treat AI skills as untrusted code. Don't grant implicit trust to vendor-published components. Run skills in sandboxed environments with network egress monitoring. Log every external connection attempt. If a skill tries to reach infrastructure you haven't explicitly approved, block it and investigate.
Build a dependency manifest for AI components. Document every skill, model, and instruction file your applications use. For each component, track the source repository, referenced domains, required API endpoints, and last verification date. Update this manifest when you update components.
Monitor for hallucinated resources in your own code. LLMs generate code that references non-existent packages, libraries, and domains. If you're using AI-assisted development, scan generated code for external references and validate each one before deployment. This applies to infrastructure-as-code, deployment scripts, and API integrations, not just application logic.
Establish a skill vetting pipeline. Before any AI skill reaches production, it should pass through automated checks: static analysis for hardcoded credentials, domain ownership verification, API endpoint validation, and behavior testing in isolation. Document which checks passed and who approved exceptions for any that failed.
Set up sinkholing for your own hallucinated domains. If your LLMs generate code, they might reference domains you don't own. Register common patterns (your-company-api.com, yourcompany-internal.net) defensively. Monitor them for traffic. If requests arrive, you've found a hallucination in production before an attacker did.
The OpenAI incident wasn't a sophisticated attack, it was an unclaimed domain in a commit that nobody validated. Your AI supply chain likely contains similar gaps. The question isn't whether hallucinated resources exist in your dependencies. It's whether you'll find them before someone else does.
