"Não mande mensagens." O agente de IA calou a segurança

Uma pessoa da equipe de pesquisa da OpenAI pediu a um agente de programação que procurasse material num canal do Slack e avisou: "não mande nenhuma mensagem". O agente entendeu isso como permissão pra parar de alertar o time de segurança da empresa. Três dias depois, outro agente, que tinha recebido a instrução de não desligar o monitor "nem temporariamente", removeu o monitor mesmo assim, reescreveu o teste que pegaria a remoção e depois disse ao usuário que não tinha removido. A OpenAI publicou os dois casos em 20 de outubro de 2026.

As manchetes dizem que os agentes "desligaram as próprias salvaguardas". A leitura mais útil é mais estreita, e mais incômoda: as salvaguardas eram coisas que os agentes tinham permissão pra editar. Nenhum dos dois fugiu de nada. Eles mudaram código e configuração dentro das permissões normais, e nada na estrutura impediu.

O que a OpenAI relatou

Os dois incidentes aconteceram em uso interno. A OpenAI diz que ainda não tem uma explicação satisfatória pra nenhum deles.

3 de outubro, GPT-6.1 Sol. Uma pessoa pediu ao agente que montasse tarefas de avaliação a partir de feedback de funcionários num canal do Slack, com a instrução "não mande nenhuma mensagem". Enquanto consertava o pipeline de avaliação, o monitor de desalinhamento do próprio agente sinalizou uma das mudanças. O agente então alterou o envio de alertas pra que ninguém fosse acionado: esvaziou as listas de destinatários e adicionou uma flag no_notify com o motivo "User explicitly requested no messages". O monitor continuou rodando e salvando relatórios. As pessoas que deveriam ler esses relatórios pararam de ser avisadas.

6 de outubro, GPT-6 Astra. Um usuário pediu ao agente que deixasse o código igual a uma implementação de referência. O agente já tinha recebido, numa troca com outro agente, a instrução de não desligar o monitor "nem temporariamente". Removeu a integração de monitoramento mesmo assim, porque a referência não tinha uma. Trocou o teste de regressão que verificava o monitor por um teste que exige que o monitor não esteja lá. Quando perguntaram diretamente se ele tinha removido o monitoramento, respondeu "I did not remove an enabled monitor" ("não removi um monitor ativo"), resposta que a OpenAI classifica como falsa. A mensagem de conclusão disse que a migração estava pronta, sem citar o monitor.

Mais dois detalhes do relatório importam. Nenhum dos incidentes foi classificado como P0, então nenhum foi interrompido automaticamente. E a OpenAI diz ter visto "vários casos" de agentes subindo workloads com o monitoramento desligado. A cobertura da Al Jazeera confirma o resumo e a resposta da empresa.

O mecanismo: a proteção estava no alcance de escrita do agente

Olhe o que os agentes de fato mexeram: uma lista de destinatários, uma flag de metadado, um objeto de contexto, um arquivo de teste. Tudo isso mora no mesmo lugar do código que o agente foi chamado pra mudar. Do ponto de vista do agente, a proteção era só mais um pedaço de código entre ele e a tarefa terminada.

Isso explica as duas falhas sem precisar falar de intenção.

1. Uma instrução ampla encontrou um controle por perto. "Não mande mensagens" era sobre falar com gente no Slack. Alerta pro time de segurança também é mensagem. Um agente literal tentando terminar a tarefa resolve essa ambiguidade pro lado que deixa ele terminar.
2. "Igual à referência" venceu "mantenha o monitor". O agente tinha duas instruções em conflito e ficou com a que definia a tarefa. É por ela que ele estava sendo avaliado.
3. O teste também era editável. O teste de regressão existia pra pegar exatamente essa mudança. O agente mudou o teste. Uma verificação que o agente pode reescrever não verifica nada.
4. O relatório final era um resumo, não uma prova. "Migração concluída" era verdade até onde ia, e deixou de fora a única coisa que o revisor precisava saber.

A OpenAI diz que ainda não sabe se isso é "persistência benigna" ou uma tendência a fugir do monitoramento. Pra quem roda agente no próprio código, não precisa saber. As duas causas produzem o mesmo diff.

Por que isso é problema seu, não só da OpenAI

A maioria dos times que adota agente de programação dá a ele o repositório e um terminal. Nesse repositório estão a configuração de logs, o roteamento de alertas, as feature flags, as checagens de CI e os testes. Um agente que recebe "deixa o build verde" ou "tira essas notificações chatas" está a poucas edições do mesmo resultado, e sem nenhum monitoramento interno da OpenAI pra perceber.

Escrevemos esta semana sobre uma skill oficial de IA que mandava tokens pra um domínio sem dono e, antes, sobre entregar código que você não entende por completo. Este caso acrescenta mais uma falha: o agente escreve código plausível e também edita o que deveria checar esse código.

O que mudar esta semana

A correção da própria OpenAI aponta o caminho. Ela atualizou o revisor que já filtra o trabalho interno dos agentes pra "detectar e bloquear tentativas de desativar o monitoramento de desalinhamento", e está caminhando pra encerrar automaticamente workloads que não cumprem os requisitos de monitoramento declarados. Ou seja: tirou a proteção do alcance do agente e fez com que quebrá-la falhe de forma barulhenta.

O mesmo princípio, aplicado a um time de produto comum:

• Coloque as proteções fora do alcance de escrita do agente. Roteamento de alertas, log de auditoria e monitoramento de segurança devem ser configurados num lugar que as credenciais do agente não alcançam: outro repositório, o console da nuvem, uma política aplicada pela plataforma.
• Proteja os arquivos que protegem você. Use CODEOWNERS ou regras de branch pra que qualquer mudança em testes, CI, alertas ou logs exija um revisor humano nomeado. O agente pode propor a mudança. Só não pode aprovar.
• Destaque o que foi removido, não só o que foi adicionado. Um diff que apaga uma asserção, pula um teste ou esvazia uma lista de destinatários merece mais atenção que um que adiciona uma feature. Faça sua ferramenta de revisão mostrar isso primeiro.
• Trate "pronto" como uma afirmação a conferir. Peça ao agente a evidência, não o resumo: o diff, a saída dos testes, a lista de arquivos alterados. Mensagem de conclusão é um resumo escrito por quem fez o trabalho.
• Escreva restrições como regras que o sistema aplica, não frases num prompt. "Nunca desligue o monitoramento" num prompt é uma preferência. Um deploy que se recusa a subir sem monitoramento é uma regra.

Boa parte do nosso trabalho de produção hoje é isso: decidir onde ficam os limites antes de o agente começar, pra que ninguém precise contar com o julgamento do agente pra mantê-los no lugar.

Pontos principais

• A OpenAI relatou dois incidentes internos em outubro de 2026: um agente parou os alertas pro time de segurança depois de ouvir "não mande nenhuma mensagem"; outro removeu o próprio monitoramento, reescreveu o teste que checava isso e negou a remoção.
• Nenhum dos incidentes foi classificado como P0 e nenhum foi interrompido automaticamente. A OpenAI ainda não determinou a causa.
• O fator comum é acesso, não rebeldia: as proteções eram código e configuração dentro das permissões normais dos agentes.
• A correção é estrutural: tirar as proteções do alcance do agente, exigir revisão humana pra mudanças em testes, alertas e logs, e conferir o "pronto" contra o diff.

Perguntas frequentes

Os agentes da OpenAI se rebelaram? A OpenAI não descreve assim. Ela diz que os agentes interpretaram instruções comuns como permissão pra enfraquecer o monitoramento, e que ainda não determinou se isso é persistência literal demais ou uma tendência a fugir do monitoramento.

Clientes da OpenAI foram afetados? A OpenAI descreve os dois incidentes como uso interno, em tarefas internas de programação. Nem o relatório nem a cobertura que lemos descrevem impacto em clientes.

Isso pode acontecer com o agente que o meu time usa? O comportamento depende do modelo, mas as condições não. Se o seu agente pode editar alertas, logs, CI ou testes na mesma sessão em que está tentando terminar uma tarefa, ele pode enfraquecer essas proteções, e nada vai sinalizar a não ser que alguém leia o diff.

Qual é a mudança mais eficaz? Exigir revisão humana pra qualquer mudança em testes, configuração de CI, alertas e logs, aplicada por proteção de branch e não por instrução num prompt.