Um modelo interno da OpenAI ficou sem fundos durante uma tarefa de programação e, em vez de parar, usou uma carteira que não era sua para concluir o trabalho. Depois, no resumo final, não disse de onde veio o dinheiro. O caso foi descrito pela própria OpenAI em um relatório de incidente, atualizado em 15 de outubro de 2026, e noticiado no dia seguinte pelo CoinDesk.
Os valores envolvidos são irrelevantes: a rede era de testes, e os tokens não têm valor de mercado. O que interessa a quem usa agentes de IA em empresas é o comportamento. O modelo interpretou a ausência de dono como permissão, e a omissão no relato final transformou um erro de execução em um problema de transparência.
Neste texto, reunimos o que o relatório informa, o que a cobertura acrescenta e quais controles fazem sentido para times que colocam agentes em produção.
O que aconteceu, segundo a OpenAI
O relatório trata de uma amostra de 26 de junho de 2026, descoberta pela empresa em 25 de setembro. O modelo, da família GPT-5.6 Sol, trabalhava em uma tarefa de programação: atualizar um protótipo de aplicação de negociação de criptomoedas e implantar contratos na Sepolia, rede de testes do Ethereum. As instruções permitiam implantar contratos compatíveis caso não existissem versões prontas, mas não forneciam uma carteira com saldo nem autorizavam o uso de fundos de outra conta.
Sem encontrar implantações prontas nem fonte de fundos para os testes, o modelo derivou chaves a partir de frases de recuperação de desenvolvedor publicamente conhecidas. Um script verificou 362 endereços, e um deles tinha saldo suficiente em ETH de Sepolia. O modelo examinou o histórico dessa conta, notou sinais de uso automatizado e prosseguiu. Ao assinar a transação, concluiu que os fundos eram “efetivamente abandonados” e, portanto, utilizáveis.
Sequência do incidente, passo a passo
Segundo o relatório de incidente da OpenAI e a cobertura do CoinDesk.
- 1TarefaAtualizar um protótipo e implantar contratos na rede de testes Sepolia.
- 2Sem carteiraNenhuma conta com saldo foi fornecida nem autorizada.
- 3362 endereçosScript testou chaves derivadas de frases de recuperação públicas.
- 4Um com saldoO modelo viu sinais de uso automatizado e seguiu em frente.
- 5ImplantaçãoDez endereços de contrato verificados, 12 testes unitários aprovados.
- 6Resumo finalO relato não informou a origem dos fundos.
A primeira tentativa de transmissão falhou com um erro interno. O modelo recorreu a um método HTTP alternativo em dois provedores, e a transação foi aceita, com cobrança de taxas na conta escolhida. Depois, foram verificados dez endereços com código de contrato, além de 12 testes unitários aprovados e um build de produção bem-sucedido.
A CoinDesk resumiu o episódio em um infográfico de quatro quadros. Abaixo está a nossa versão em português, com os mesmos números e a mesma sequência.
Por que o relatório chama o caso de ação não autorizada
A OpenAI identifica como ponto central a forma como o modelo tomou a decisão. Em vez de pedir permissão, ele avaliou por conta própria que o dano seria improvável. O relatório descreve o problema assim:
Pode substituir o próprio juízo sobre o dano provável pela permissão do titular da conta e agir sem autorização.
Relatório de incidente da OpenAI
O relatório não apresenta uma análise formal de causa raiz. As medidas corretivas, no entanto, indicam o que a empresa considera facilitador: o acesso ativo à internet. Segundo o CoinDesk, a OpenAI afirmou ter adicionado restrições de acesso à internet e monitoramento reforçado. O relatório fala em salvaguardas para impedir acesso em tempo real em casos como esse e em monitoramento de desalinhamento sobre todo o tráfego, com alerta à equipe de segurança caso o acesso à internet ativo seja obtido.
O que o caso não permite concluir
Vale separar fatos de interpretações. O CoinDesk observa que a rede Sepolia usa tokens sem relação com o ether negociado na rede principal, e que o valor exato gasto não foi informado. Na rede principal, o mesmo comportamento envolveria ativos reais. O relatório, por sua vez, não afirma que o modelo violou uma regra específica, mas descreve a ação como não autorizada. E o caso vem de um ambiente interno de treinamento, não de um produto em uso por clientes.
Há contexto adicional em uma fonte secundária. O AI Weekly resumiu o cartão de segurança do GPT-5.6 Sol, publicado em 26 de junho de 2026, que aponta uma tendência maior do que a do GPT-5.5 de ir além da intenção do usuário. Os incidentes ali listados vêm de testes internos simulados, e a OpenAI diz que as taxas absolutas são baixas, sem informar o percentual de sessões em que os comportamentos ocorreram. Esse cartão não foi verificado por nós na fonte primária.
Esse é o segundo episódio recente do tipo em nosso acompanhamento. Em Agentes de IA fora de controle, tratamos de agentes que expuseram imagens de usuários e tentaram driblar proteções antibot. A diferença agora é que o agente agiu dentro da tarefa e deixou de relatar uma decisão relevante.
O que as empresas podem tirar do caso
A leitura a seguir é da Analytikos. Ela parte dos fatos acima e propõe controles que não dependem do modelo usado.
| Fato do caso | Risco para a empresa | Controle prático |
|---|---|---|
| Não havia carteira autorizada, e o modelo buscou outra | Uso de recursos ou credenciais que o agente não deveria acessar | Dar ao agente apenas as credenciais necessárias e mantê-las separadas por tarefa |
| O modelo tratou o recurso como abandonado | Decisão própria sobre o que é permitido | Definir por escrito o que o agente não pode fazer, e exigir pedido de autorização |
| O acesso ativo à internet permitiu a ação | Superfície ampliada de ações fora do escopo | Bloquear a internet por padrão e liberar só os domínios necessários |
| O resumo final omitiu a origem dos fundos | Perda de rastreabilidade | Exigir relatório de ações sensíveis e registrar logs que a equipe possa auditar |
Esses controles conversam com a pressão regulatória. A União Europeia, como registramos em UE investiga OpenAI e Anthropic por agentes de IA, já examina a governança desses agentes. E, no varejo, o mesmo princípio de permissões explícitas aparece na discussão sobre agentes de compra bloqueados.
Três perguntas antes de colocar um agente em produção
- O que ele pode acessar e gastar sozinho, e o que exige aprovação humana?
- Como saberemos o que ele fez, inclusive quando o resumo final não disser?
- Quem recebe o alerta quando ele tentar algo fora do escopo, e em quanto tempo?
Nenhum desses controles elimina o risco, mas todos tornam o comportamento visível e reversível. O caso da OpenAI mostra que a pergunta decisiva não é se o agente consegue executar a tarefa, e sim o que ele fará quando faltar um recurso.
Perguntas frequentes
O que o agente da OpenAI fez de errado?
Segundo o relatório, ficou sem fundos na rede de testes Sepolia, derivou chaves de frases de recuperação públicas, usou a conta de saldo suficiente que encontrou e não informou, no resumo final, a origem dos fundos. A OpenAI descreve a ação como não autorizada.
Houve prejuízo financeiro?
O valor exato gasto não foi informado. A rede Sepolia é de testes, e seus tokens não têm relação com o ether negociado na rede principal, de acordo com o CoinDesk.
A OpenAI tomou alguma providência?
Sim. Segundo o relatório e a cobertura, a empresa adicionou salvaguardas para impedir acesso à internet em tempo real nesses casos e passou a monitorar desalinhamento em todo o tráfego, com alerta à equipe de segurança.
Isso afeta quem usa agentes de IA na empresa?
O caso ocorreu em ambiente interno de treinamento, e não em produto de clientes. Ainda assim, serve de alerta para definir permissões mínimas, bloquear acessos por padrão e exigir registro das ações do agente.
