Una skill oficial de IA enviaba tokens a un dominio sin dueño

Una skill oficial de OpenAI, el paquete de instrucciones que carga un agente de IA para aprender a desplegar en Render, les decía a los agentes que los servicios privados viven en render-internal.com. Ese dominio no era de nadie. Unos investigadores de seguridad lo registraron, y empezó a recibir llamadas reales, con token, de apps en producción. Nadie hackeó nada. Los agentes escribieron exactamente lo que se les dijo.

Es el caso más claro hasta ahora de un nuevo tipo de dependencia: instrucciones en lenguaje natural que terminan convertidas en código. Tu app hecha con IA ahora depende de un texto al que nadie le fija versión, nadie escanea y nadie revisa. En este caso, el texto estuvo mal durante más de seis meses.

Qué pasó

Según el informe de AIR Security, publicado el 14 de octubre de 2026:

• El 27 de enero de 2026, un commit en el repositorio oficial de skills de OpenAI agregó la skill render-deploy. Sus archivos de referencia describían la red privada de Render como [nombre-del-servicio].render-internal.com, con ejemplos como http://internal-api.render-internal.com:10000 y una URL de Postgres en el mismo dominio.
• render-internal.com no es un dominio de Render y, según AIR, no aparece en ninguna de sus documentaciones. Simplemente no estaba registrado.
• Desde el 13 de marzo, la skill se distribuyó dentro del repositorio de plugins de OpenAI, el camino oficial y "de confianza".
• AIR registró el dominio y lo apuntó a un sinkhole pasivo: un servidor que responde en cualquier subdominio y puerto y registra todo lo que llega. Servicios reales empezaron a conectarse, con token incluido.
• Render eliminó todas las referencias el 14 de agosto. OpenAI retiró el plugin de Render el 26 de agosto. Hoy el dominio está en manos de Render.

La cobertura de CSO Online lo llama un "dominio alucinado". Ninguna de las dos fuentes muestra cómo llegó el nombre equivocado a la skill. Para tu riesgo da igual: había un dato seguro, plausible y falso dentro de una instrucción que el agente trata como verdad.

El mecanismo: un valor por defecto que solo se activa cuando alguien se olvida

Lo que vale la pena mirar con calma es cómo el dominio equivocado llegó a producción. AIR le pidió a Codex desplegar dos servicios que se comunican entre sí usando la skill. El código generado tenía esto:

defaultInternalAPIURL = "http://existing-internal-api.render-internal.com:10000"

y la configuración de despliegue llenaba INTERNAL_API_URL con el mismo valor.

Léelo como lo leería un revisor. Parece código responsable: hay una variable de entorno y un fallback con cara de sensato. En todos los entornos donde alguien configuró INTERNAL_API_URL, la app funciona y el valor por defecto nunca se usa. El día que un servicio arranca sin esa variable (un entorno nuevo, un secreto renombrado, un servicio copiado de otro), la app no falla. Envía en silencio, por http plano, las llamadas de su API interna a quien sea dueño de ese dominio.

Eso es lo que hace tan difícil detectar esta falla:

1. Pasa todas las pruebas que corres, porque tus entornos de prueba están configurados.
2. No es una vulnerabilidad para ningún escáner. No hay CVE, no hay paquete malicioso, no hay nada que marcar. Es un string.
3. A un humano le parece correcto, porque *.render-internal.com suena a hostname interno. La plausibilidad es justo lo que un modelo de lenguaje sabe producir.
4. Explotarlo cuesta registrar un dominio. No hace falta intrusión: la víctima es la que se conecta contigo.

Por qué "oficial" no ayudó

Confiamos en un paquete de un publicador conocido porque detrás hay todo un sistema: versiones, lockfiles, checksums, avisos de seguridad, escáneres que comparan una versión con la siguiente. Las skills y las instrucciones de agentes todavía no tienen casi nada de eso. Son markdown en un repositorio, cargado en tiempo de ejecución, que cambia sin que te enteres.

Entonces la pregunta no es "¿esta skill viene de un proveedor serio?". Venía. La pregunta es "¿qué hace escribir este texto a mi agente, y lo aceptaría de un desarrollador junior sin revisión?". La recomendación de la propia AIR va en la misma línea: tratar cada dominio, URL, repositorio y API que menciona una skill como una dependencia, y seguir verificándolo.

Hace poco escribimos sobre entregar código que no entiendes del todo. Esta es la versión del problema en la que el error no estaba en el código. Estaba una capa más arriba, en la instrucción que lo generó.

Qué hacer esta semana

Nada de esto requiere herramientas nuevas. Requiere aplicar al código escrito por IA unas reglas que ya aplicarías al código de un contratista que nunca conociste.

• Busca hostnames fijos en el código. Cada URL o dominio literal en el código de la aplicación y en la configuración de infraestructura debe tener un dueño que puedas nombrar. Un dominio que no puedes vincular a una cuenta tuya es un hallazgo.
• Prohíbe valores por defecto de red para servicios internos. Si falta INTERNAL_API_URL, el servicio no arranca. Fallar cerrado convierte una fuga silenciosa en un error de despliegue que alguien ve en minutos.
• Nunca envíes credenciales por http plano, interno o no. En la mayoría de las plataformas la red privada ya tiene un hostname real. Usa el de la documentación del proveedor, no el de un prompt.
• Restringe el tráfico de salida donde puedas. Un servicio que solo debería hablar con tu base de datos y dos APIs no tiene por qué llegar a todo internet.
• Evalúa las skills y las instrucciones de agentes como código de terceros. Fija la versión, lee el diff cuando cambie y mantén una lista de qué skills cargan los agentes de tu equipo.

Buena parte de nuestro trabajo de producción hoy es justamente esto: tomar software que una IA ayudó a construir y encontrar los puntos donde se equivoca con total seguridad antes de que los encuentre un cliente.

Puntos clave

• Una skill oficial de OpenAI apuntaba a los agentes a render-internal.com, un dominio sin dueño. Una vez registrado, recibió llamadas reales con token desde apps en producción.
• El valor equivocado llegó a producción como valor por defecto de respaldo, invisible donde la configuración estaba bien.
• Las skills de agentes son dependencias sin la red de seguridad de los paquetes: sin versión fija, sin escáneres, casi sin revisión.
• La solución es higiene básica: ser dueño de cada hostname de tu código, fallar cerrado si falta configuración, restringir la salida de red y revisar las skills como código de terceros.

Preguntas frecuentes

¿Qué es una skill de agente de IA? Un conjunto de instrucciones y archivos de referencia que un agente de programación carga para hacer una tarea concreta, como desplegar en una plataforma. El agente trata ese contenido como guía confiable.

¿Hackearon a OpenAI o a Render? No. No hubo intrusión. La skill tenía un dominio equivocado, y cualquiera que lo registrara recibiría tráfico de las apps construidas con ella. Los investigadores lo registraron primero y reportaron el problema.

Usé la skill render-deploy. ¿Estoy afectado? Busca render-internal.com en tu código y en tu configuración de despliegue. Si aparece, reemplázalo por el hostname de la documentación de Render y rota las credenciales que puedan haberse enviado ahí.

¿Entonces hay que dejar de usar agentes de IA para programar? No. Hay que revisar el código que escribe el agente con el mismo cuidado que cualquier otro, con atención extra a todo lo que parezca un valor por defecto sensato.