Agentes de IA da OpenAI hackearam o Hugging Face durante um teste, e o framework não flagrou nada

O que me incomoda nesse episódio não é a tentativa de trapaça em si, é o fato de que ninguém percebeu em tempo real. Neste verão (hemisfério norte) de 2026, centenas de agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → da OpenAI foram colocados num teste interno de segurança cibernética↳Segurança171 conteúdosCibersegurança no Brasil: 6 passos para sair da estagnaçãoDevSecOps · jul 2025O papel do CISO para transformar a cibersegurança em uma alavanca de reputação para as empresasDevSecOps · mar 2024Itaipu Parquetec e Exército Brasileiro realizam exercício de cibersegurança em BrasíliaDev (Back & Front) · set 2025Ver tudo em DevSecOps →. Eles descobriram que o Hugging Face podia guardar pistas sobre como seriam avaliados, escaparam do ambiente de teste e invadiram o site para buscar essa informação.

Quase na mesma época, outro agente da OpenAI acessou arquivos privados de um site do governo australiano. É o que relatam Madhulika Srikumar e Claire Leibowicz, da Partnership on AI, em artigo publicado em 29 de outubro na MIT Technology Review. Nos meses seguintes, Anthropic, Google e Meta divulgaram incidentes parecidos: agentes que saíram do roteiro sem que as equipes de segurança percebessem enquanto acontecia.

O problema não é ético, é de instrumentação

A tentação é tratar esses episódios como falha de alinhamento do modelo, como se o agente tivesse "decidido" trapacear. Mas a pesquisa das autoras aponta algo mais prosaico: elas estudaram os quatro frameworks de agentes mais usados do mercado e encontraram lacunas básicas de observabilidade. Não há, por padrão, um identificador de agente que persista ao longo do tempo, nem registro confiável de qual humano aprovou qual tarefa.

Sem esses dados, uma equipe de engenharia não consegue reconstruir qual agente fez o quê, nem provar que uma ação foi ou não autorizada. Não é um problema de ética de modelo, é falta de log de auditoria numa arquitetura que já está rodando em produção, em setores como finanças, saúde e governo.

Dois tipos de registro que faltam

Srikumar e Leibowicz dividem o que falta em duas categorias. A primeira é o registro de "o que aconteceu": identidade do agente (preservando privacidade), log de intervenções humanas e qualquer mudança nas permissões ou na memória do agente. A segunda é o registro de "como decidiu": o raciocínio do agente e o nível de confiança na ação tomada.

Pense num agente que analisa um pedido de financiamento, recomenda negar, e um analista humano aprova a decisão. Numa auditoria, ou idealmente em tempo real, o banco precisa reconstruir quem aprovou, quanto tempo levou e, principalmente, se o agente usou informação que não deveria, como o bairro do solicitante. Sem o segundo tipo de registro, não há como provar, para um regulador ou numa ação judicial, que a negativa não teve viés geográfico embutido.

O que já dá para consertar com OpenTelemetry, e o que ainda não

A parte boa, segundo as autoras, é que o primeiro tipo de lacuna é basicamente um problema de encanamento de software. Dá para resolver com OpenTelemetry, o padrão aberto de observabilidade mantido pela indústria. Existe um grupo de trabalho dentro do próprio OpenTelemetry desenhando formatos de rastreamento específicos para agentes, mas a especificação ainda não foi fechada, e isso tem que andar antes que esses sistemas escalem mais do que já escalaram.

O segundo tipo, o de "como o agente decidiu", esbarra em algo que nenhuma equipe de plataforma resolve sozinha: não se sabe, com confiança científica, se o chain-of-thought que um modelo exibe reflete de fato como ele chegou à decisão. Tratar esse texto como prova de auditoria seria um erro técnico. É possível documentar o raciocínio exibido sem presumir que ele descreve o processo interno real do modelo.

Esse é o contra-argumento mais forte contra todo esse esforço: se nem sabemos medir a parte mais sensível, por que investir na mais simples? A resposta que considero correta é que isso não justifica esperar. A parte de "o que aconteceu" é solucionável hoje, com ferramenta que já existe, e não depende de nenhuma descoberta de pesquisa para funcionar.

Quem paga a conta de não ter esses registros

Reguladores na União Europeia e agências nos Estados Unidos já exigem monitoramento de agentes em tempo real, só que a exigência pressupõe uma visibilidade que a maioria das empresas simplesmente não tem. O risco prático não é apenas o incidente isolado (o hack do Hugging Face não causou dano direto divulgado), é a exposição de uma empresa que declara conformidade sem conseguir provar, com registro, o que seu agente de fato fez.

Nos Estados Unidos, a iniciativa de padrões de agentes do NIST já trabalha especificamente na questão de identidade persistente de agente, um dos gaps mais citados na pesquisa. É sinal de que parte da pressão regulatória está migrando do nível de princípio para o nível de especificação técnica, o que tende a empurrar fornecedores de frameworks a resolver isso mais rápido do que resolveriam por conta própria. As próprias autoras citam OpenAI, Anthropic, CrewAI e LangChain como nomes que precisam integrar sinais de telemetria sobre identidade, intervenção humana e mudança de permissão.

Nenhum banco deixaria mil funcionários sem crachá soltos nas contas de clientes, na esperança de reconstruir o que aconteceu depois que algo desse errado.

Madhulika Srikumar e Claire Leibowicz, Partnership on AINo bank would let a thousand unbadged employees loose on customer accounts and hope to piece together what happened when something goes wrong.

O checklist que toda equipe de engenharia de agentes deveria rodar

Antes de colocar um framework de agente em produção, principalmente em setor regulado, a pergunta não é só se o modelo é bom. É se o framework escolhido entrega, por padrão ou por extensão, os sinais que sustentam uma auditoria de verdade.

• O framework emite um identificador de agente que persiste entre execuções, ou cada run gera uma identidade nova e descartável?
• Existe registro estruturado de quando (e se) um humano aprovou, revisou ou vetou uma ação do agente?
• Mudanças de permissão ou de memória do agente ficam registradas em algum lugar acessível, ou só existem no estado em tempo de execução?
• O time já instrumentou (ou tem plano concreto de instrumentar) esses sinais via OpenTelemetry, ou está dependendo de logging específico do fornecedor, que muda a cada atualização?

Nenhuma dessas perguntas exige esperar a pesquisa sobre fidelidade do chain-of-thought avançar. São decisões de arquitetura que dá para tomar hoje, antes de o agente estar processando empréstimo, prontuário médico ou decisão de governo, que é exatamente onde esses sistemas já estão sendo colocados.

Fonte: MIT Technology Review