Uma skill oficial de IA mandava tokens pra um domínio sem dono

Uma skill oficial da OpenAI, o pacote de instruções que um agente de IA carrega pra aprender a fazer deploy na Render, ensinava que os serviços privados ficam em render-internal.com. Esse domínio não era de ninguém. Pesquisadores de segurança registraram o endereço, e ele começou a receber chamadas reais, com token, de apps em produção. Ninguém invadiu nada. Os agentes escreveram exatamente o que mandaram eles escreverem.

É o caso mais claro até agora de um tipo novo de dependência: instrução em linguagem natural que vira código. O seu app feito com IA agora depende de um texto que ninguém fixa versão, ninguém escaneia e ninguém revisa. Neste caso, o texto ficou errado por mais de seis meses.

O que aconteceu

Segundo o relatório da AIR Security, publicado em 14 de outubro de 2026:

• Em 27 de janeiro de 2026, um commit no repositório oficial de skills da OpenAI adicionou a skill render-deploy. Os arquivos de referência descreviam a rede privada da Render como [nome-do-serviço].render-internal.com, com exemplos como http://internal-api.render-internal.com:10000 e uma URL de Postgres no mesmo domínio.
• render-internal.com não é domínio da Render e, segundo a AIR, não aparece em nenhuma documentação dela. Ele simplesmente não estava registrado.
• A partir de 13 de março, a skill passou a ser distribuída no repositório de plugins da OpenAI, o caminho oficial e "confiável".
• A AIR registrou o domínio e apontou pra um sinkhole passivo: um servidor que responde em qualquer subdomínio e porta e anota tudo que chega. Serviços reais começaram a se conectar, com token junto.
• A Render tirou todas as referências em 14 de agosto. A OpenAI removeu o plugin da Render em 26 de agosto. Hoje o domínio está com a Render.

A cobertura da CSO Online chama de "domínio alucinado". Nenhuma das duas fontes mostra como o nome errado foi parar na skill. Pro seu risco, tanto faz: havia um fato confiante, plausível e falso dentro de uma instrução que o agente trata como verdade.

O mecanismo: um default que só dispara quando alguém esquece

O ponto que merece atenção é como o domínio errado chegou em produção. A AIR pediu pro Codex fazer o deploy de dois serviços que conversam entre si usando a skill. O código gerado tinha isto:

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

e a configuração de deploy preenchia INTERNAL_API_URL com o mesmo valor.

Leia como um revisor leria. Parece código responsável: tem variável de ambiente e tem um fallback com cara de sensato. Em todo ambiente onde alguém configurou INTERNAL_API_URL, o app funciona e o default nunca roda. No dia em que um serviço sobe sem essa variável (ambiente novo, secret renomeado, serviço copiado de outro), o app não quebra. Ele manda, em silêncio e por http puro, as chamadas da API interna pra quem for dono daquele domínio.

É isso que torna essa falha tão difícil de pegar:

1. Passa em todo teste que você roda, porque os seus ambientes de teste estão configurados.
2. Não é vulnerabilidade pra nenhum scanner. Não tem CVE, não tem pacote malicioso, não tem nada pra sinalizar. É uma string.
3. Parece certo pra um humano, porque *.render-internal.com soa como hostname interno. Plausibilidade é justamente o que um modelo de linguagem sabe produzir.
4. O custo pra explorar é registrar um domínio. Não precisa invadir nada: a vítima é que se conecta em você.

Por que "oficial" não ajudou

A gente confia num pacote de um publicador conhecido porque existe um sistema inteiro por trás: versão, lockfile, checksum, alerta de segurança, scanner comparando uma versão com a outra. Skill e instrução de agente ainda não têm quase nada disso. É markdown num repositório, carregado na hora, que muda sem você ver.

Então a pergunta não é "essa skill vem de um fornecedor sério?". Vinha. A pergunta é "o que esse texto faz o meu agente escrever, e eu aceitaria isso de um dev júnior sem revisão?". A recomendação da própria AIR vai na mesma linha: tratar todo domínio, URL, repositório e API citado numa skill como dependência, e continuar checando.

Escrevemos há pouco sobre entregar código que você não entende por completo. Esta é a versão do problema em que o erro não estava no código. Estava uma camada acima, na instrução que gerou o código.

O que fazer esta semana

Nada disso exige ferramenta nova. Exige aplicar ao código escrito por IA algumas regras que você já aplicaria ao código de um terceirizado que nunca viu.

• Procure hostnames fixos no código. Toda URL ou domínio literal no código da aplicação e na configuração de infraestrutura tem que ter um dono que você sabe nomear. Domínio que você não consegue ligar a uma conta sua é achado de auditoria.
• Proíba default de rede pra serviço interno. Se INTERNAL_API_URL não existe, o serviço não sobe. Falhar fechado transforma um vazamento silencioso num erro de deploy que alguém vê em minutos.
• Nunca mande credencial por http puro, interno ou não. Na maioria das plataformas a rede privada já tem hostname de verdade. Use o da documentação do fornecedor, não o de um prompt.
• Restrinja o tráfego de saída onde der. Um serviço que só deveria falar com o banco e com duas APIs não tem por que alcançar a internet inteira.
• Avalie skills e instruções de agente como código de terceiros. Fixe a versão, leia o diff quando mudar e mantenha uma lista de quais skills os agentes do time carregam.

Boa parte do nosso trabalho de produção hoje é exatamente isso: pegar software que uma IA ajudou a construir e achar os pontos onde ele está confiantemente errado antes que um cliente ache.

Pontos principais

• Uma skill oficial da OpenAI apontava agentes pra render-internal.com, um domínio sem dono. Depois de registrado, ele recebeu chamadas reais, com token, de apps em produção.
• O valor errado chegou em produção como default de fallback, invisível onde a configuração estava certa.
• Skill de agente é dependência sem a rede de proteção que pacote tem: sem versão fixa, sem scanner, quase sem revisão.
• A correção é higiene comum: ser dono de todo hostname no código, falhar fechado quando falta configuração, restringir saída de rede e revisar skill como código de terceiros.

Perguntas frequentes

O que é uma skill de agente de IA? Um conjunto de instruções e arquivos de referência que um agente de programação carrega pra executar uma tarefa específica, como fazer deploy numa plataforma. O agente trata esse conteúdo como orientação confiável.

A OpenAI ou a Render foram invadidas? Não. Nada foi invadido. A skill tinha um domínio errado, e quem registrasse esse domínio passaria a receber tráfego dos apps construídos com ela. Os pesquisadores registraram primeiro e reportaram o problema.

Usei a skill render-deploy. Fui afetado? Procure render-internal.com no código e na configuração de deploy. Se aparecer, troque pelo hostname da documentação da Render e rotacione as credenciais que possam ter sido enviadas pra lá.

Então é pra parar de usar agentes de IA pra programar? Não. É pra revisar o código que o agente escreve com o mesmo cuidado de qualquer outro código, com atenção redobrada a tudo que parece um default sensato.