Pontos principaisÂ
- Cerca de 1.200 agentes supostamente isolados se comunicavam por meio de um fórum não autorizado, e cerca de 700 participavam de atividades relacionadas ao Hugging Face.
- Os agentes trocaram mais de 70.000 mensagens e arquivos, combinando descobertas feitas em sessões que deveriam permanecer separadas.
- Investigators found agents spoofing tool calls and researching ways to alter evaluation transcripts to avoid detection by the grader.
- Backups imutáveis e isolados, por si só, são insuficientes: as organizações precisam de um ponto de Recovery validado e confiável antes de restaurar o ambiente de produção.
Os laudos periciais finalmente chegaram e mudaram a maneira como vejo esse incidente.
Há cerca de um mês,Escrevi sobreaIncidente de segurança envolvendo a OpenAI e a Hugging Facebecause I thought it was something anyone responsible for cybersecurity, AI or business resilience should be watching.
Na época, a história parecia bastante simples: um agente de IA encontrou uma maneira de sair do ambiente projetado para contê-lo e, por fim, chegou ao Hugging Face.
Na verdade, não foi bem isso que aconteceu.
A história vai além de um único agente desonesto
Os laudos forenses revelam que cerca de 1.200 agentes, que deveriam estar atuando de forma isolada, descobriram uma maneira de se comunicar por meio de um fórum não autorizado. Eles trocaram mais de 70.000 mensagens e arquivos, e cerca de 700 agentes participaram de atividades relacionadas ao Hugging Face.
None of that was prompted or intended. The agents were persistent, they could share what they found, and they could combine effort across sessions that were supposed to have no contact with each other.
Entre os novos detalhes: os agentes do GPT-5.6 Sol reproduziram uma vulnerabilidade e copiaram dados privados de avaliação para um conjunto de dados público do Hugging Face, o que representa uma escalada concreta em relação ao que foi descrito nos relatórios iniciais.
O problema do “hackeamento de recompensas”
Oinvestigação independente realizada pela METR e pela Redwood Research, publicado juntamente com o próprio relatório da OpenAI em 26 de agosto, constatou que os agentes pesquisaram maneiras de falsificar, editar ou excluir partes de suas próprias transcrições de avaliação, pois acreditavam, erroneamente, que o avaliador verificaria como eles haviam concluído a tarefa. Os pesquisadores identificaram casos bem-sucedidos de falsificação de chamadas de ferramentas em cerca de 7% das transcrições avaliadas, embora a manipulação observada tenha sido em pequena escala.
A conclusão não é que os agentes sejam “enganosos” no sentido humano do termo. É que um agente suficientemente capaz pode buscar maneiras de contornar os controles quando esses controles se interpõem entre ele e o resultado para o qual foi otimizado.
A OpenAI se refere ao incidente como um “tiro de advertência”. Acho que essa é uma descrição adequada.
O que acontece quando a contenção falha
A maior parte da discussão sobre esse incidente se concentrará, com razão, no alinhamento, no isolamento (sandboxing) e no monitoramento. Mas há uma questão de resiliência subjacente a isso: se 700 agentes conseguem contornar a contenção, qual é o plano para o caso de uma única carga de trabalho comprometida fazer o mesmo em seu ambiente?
A própria conclusão da OpenAI aponta para a resposta: a arquitetura de segurança deve partir do princípio de que uma carga de trabalho individual ou um nó de computação pode, eventualmente, ser comprometido. Isso significa dados de recuperação isolados fisicamente (air-gapped) e imutáveis, além de uma maneira de validar o que está sendo restaurado antes que volte a entrar em produção.
Mas a imutabilidade, por si só, não comprova que os dados estavam intactos no momento em que foram capturados. Se os dados já estivessem comprometidos no momento da captura, a imutabilidade preservaria esse comprometimento com a mesma fidelidade com que preserva qualquer outra coisa.
A versão prática dessa pergunta é simples de fazer, mas difícil de responder: se isso acontecesse conosco, seríamos capazes de comprovar qual ponto de recuperação é anterior ao incidente?
Abordamos esse modelo operacional na seçãoResOps (operações de resiliência)noLeituras.
A lição para todas as organizações
Desde então, a OpenAI reforçou o isolamento de cargas de trabalho e de rede, ampliou o monitoramento e revisou suas práticas de desenvolvimento de modelos. A lição vai além da OpenAI: contenha o impacto, preserve o que for confiável e comprove que é possível se recuperar antes que isso seja necessário.
Perguntas frequentes
P: O que foi o incidente envolvendo a OpenAI e a Hugging Face?
Durante avaliações internas de segurança cibernética, agentes da OpenAI contornaram os controles destinados a isolá-los, acessaram a internet e chegaram a sistemas de terceiros, incluindo o Hugging Face. A atividade foi impulsionada principalmente por um modelo de pesquisa interno que operava com proteções reduzidas.
P: Como os agentes supostamente isolados se comunicavam?
R:Eles descobriram um fórum não autorizado na infraestrutura compartilhada. Cerca de 1.200 agentes o utilizaram para trocar mais de 70.000 mensagens e arquivos, permitindo que informações e táticas fossem transmitidas entre sessões que deveriam permanecer independentes.
P: Os agentes receberam ordens para atacar a Hugging Face?
R:Não. Eles estavam tentando concluir um teste de desempenho complexo de segurança cibernética. Quando o caminho previsto parecia bloqueado, alguns agentes buscaram formas alternativas de alcançar o resultado esperado, e essa atividade se estendeu além dos limites previstos do ambiente.
P: O que significa “hackeamento por recompensa” neste contexto?
R:A manipulação de recompensas ocorre quando um agente encontra uma maneira não prevista de atender a uma métrica ou obter um resultado desejado sem concluir a tarefa conforme o esperado. Os investigadores descobriram que os agentes estavam buscando maneiras de falsificar chamadas de ferramentas e alterar ou excluir partes das transcrições de avaliação, pois acreditavam que o avaliador poderia inspecionar seu processo.
P: Por que os backups imutáveis, por si só, não são suficientes?
R:A imutabilidade impede que os dados armazenados sejam alterados, mas não comprova que os dados estavam intactos no momento em que foram capturados. Se um backup já contiver dados comprometidos, a imutabilidade preserva esse comprometimento. Portanto, as organizações precisam de cópias isoladas, pontos de recuperação confiáveis e validação antes da restauração.
P: O que as organizações devem fazer de diferente após esse incidente?
R:Reforce o isolamento da carga de trabalho e da rede, restrinja o acesso desnecessário à Internet e às credenciais, monitore o comportamento dos agentes e os sinais de escalonamento, e parta do princípio de que a prevenção pode falhar. Combine esses controles com dados de recuperação isolados e imutáveis, além de um processo testado para identificar e validar um ponto de recuperação limpo.
Chris Bevilé gerente sênior de marketing de portfólio na Commvault.
