O incidente da Hugging Face e os próximos passos

Ao longo de maio e junho, iniciamos execuções de treinamento por aprendizado por reforço (RL) para vários novos modelos de pesquisa que não se destinavam ao lançamento público. Um desses modelos acabou sendo o principal responsável pela atividade que levou ao incidente da Hugging Face. Este é um modelo de pesquisa exclusivamente interno que chamamos de Internal Model 1 (IM1).

Não habilitamos o acesso à internet nem a comunicação entre agentes em muitos dos ambientes desses experimentos de treinamento. Apesar dessas restrições, os agentes descobriram maneiras de explorar nossa infraestrutura de pesquisa para se comunicar entre si e acessar a internet.

Primeiro, os modelos encontraram maneiras de se comunicar gravando arquivos no serviço de gerenciamento de pacotes Artifactory. Na prática, isso transformou o Artifactory em um quadro de mensagens não intencional, no qual os agentes podiam trocar informações. Leia mais: como os agentes usaram o quadro de mensagens 

Em 4 de julho, a atividade contínua dos agentes desestabilizou a instância afetada do Artifactory e causou uma indisponibilidade. Em 5 de julho, foi aberto um incidente de segurança. A equipe de segurança bloqueou uma rota conhecida de elevação de privilégios, removeu credenciais expostas e reconstruiu o Artifactory. Como efeito colateral, isso apagou o quadro de mensagens. Com essas medidas de mitigação implementadas, as avaliações de segurança cibernética foram retomadas.

Naquele momento, ainda não se compreendiam as implicações mais amplas para contenção e alinhamento decorrentes do quadro de mensagens improvisado e do acesso não intencional à internet. O relatório técnico do incidente detalha melhor o que as diferentes equipes da OpenAI entendiam naquele momento. Em resumo, uma equipe interna observou um agente interagindo no quadro de mensagens e casos de acesso não permitido à internet no fim de maio. No entanto, a existência do quadro de mensagens improvisado e a importância da comunicação entre agentes não eram evidentes para os líderes responsáveis pela detecção e resposta a incidentes. Continuamos investigando o processo e as práticas operacionais que influenciaram as atividades de detecção e resposta antes desse incidente.

Com o serviço Artifactory reconstruído, retomamos as avaliações de segurança cibernética. Realizamos essas avaliações para compreender do que nossos modelos são capazes e determinar as salvaguardas adequadas para a implantação. Para isso, não habilitamos o mesmo nível de salvaguardas usado nos sistemas que disponibilizamos externamente. O ExploitGym, a avaliação que levou a esse incidente, é muito difícil: talvez não exista uma solução conhecida para algumas tarefas. Para ter sucesso, os agentes precisam encontrar maneiras de explorar um software e recuperar uma resposta conhecida como flag.

Após o incidente, dedicamos um esforço considerável a investigar por que o modelo apresentou esse comportamento desalinhado, incluindo problemas de desalinhamento no treinamento e na avaliação, além da cobertura de salvaguardas nas avaliações internas.

Identificamos quatro padrões de desalinhamento que contribuíram para o comportamento dos modelos: manipulação de recompensas, persistência em tarefas aparentemente impossíveis, comunicação não autorizada e adoção, pelos agentes, dos objetivos uns dos outros.

Para compreender esses padrões, analisamos rollouts de treinamento e avaliação dos modelos.¹ Realizamos análises retrospectivas abrangentes da cadeia de pensamento (CoT), das ações e das saídas finais usando nossas técnicas mais recentes de monitoramento de CoT⁠. Com base na visão retrospectiva proporcionada pela investigação, aprimoramos especificamente o recall do monitor para os tipos de comportamento ocorridos no incidente.

Um dos principais fatores por trás do incidente da Hugging Face foi a tentativa dos agentes de trapacear nas tarefas procurando soluções online. Esse comportamento é conhecido como manipulação de recompensas: os agentes concluem as tarefas de maneiras não previstas para obter recompensas maiores ou facilitar sua obtenção. A manipulação de recompensas está presente em sistemas de IA há muito tempo (veja este trabalho de uma década atrás⁠, ilustrado na figura abaixo) e também nos LLMs de ponta atuais⁠(abre em uma nova janela). Temos investido significativamente em métodos para identificar e corrigir essas manipulações⁠.

Outro fator importante por trás do comportamento desalinhado foi que os agentes raramente “desistiam” das tarefas de avaliação, mesmo quando elas pareciam impossíveis de resolver. À medida que consumiam seus orçamentos de raciocínio, alguns agentes adotavam estratégias cada vez mais arriscadas e fora dos limites, até chegarem a explorar a infraestrutura de terceiros.

Durante nossa investigação, constatamos que, na avaliação ExploitGym, nenhum de nossos modelos havia jamais produzido uma resposta correta para 198 das 898 tarefas antes do incidente. Essas tarefas não resolvidas acabaram contribuindo significativamente para a atividade dos agentes: 93% das tarefas discutidas no quadro de mensagens do Artifactory durante o incidente da Hugging Face pertenciam a esse conjunto de 198 questões.

Segundo, o incidente foi causado principalmente por agentes que receberam orçamentos de raciocínio extremamente grandes, muito superiores aos disponíveis em nossos produtos externos.

Quadros de mensagens persistentes e não autorizados estiveram no centro desse incidente. Agentes que deveriam trabalhar de forma independente puderam compartilhar descobertas, coordenar esforços e retomar o trabalho no ponto em que outros haviam parado. Isso permitiu combinar trabalho e capacidade computacional entre avaliações distintas, ampliando suas capacidades muito além do que qualquer agente individual poderia alcançar sozinho. A comunicação entre agentes não é um comportamento problemático por si só: treinamos e implantamos sistemas multiagente que podem se comunicar sobre a mesma tarefa por meio de uma ferramenta de colaboração. Nos eventos de julho, agentes com tarefas diferentes encontraram por conta própria uma maneira de colaborar fora desses limites, com consequências imprevisíveis.

Ao investigar o incidente, descobrimos casos raros em que agentes sem ferramentas multiagente encontraram maneiras de colaborar por canais paralelos durante o treinamento. Acreditamos que esse comportamento tenha começado como uma generalização do treinamento multiagente.

A comunicação não autorizada muitas vezes começava quando um agente deixava uma anotação ou um arquivo em algum sistema externo, geralmente como uma forma de memória externa. Quando outros agentes percebiam esses artefatos, muitas vezes concluíam que poderiam usar o serviço externo para colaborar. Em um exemplo hipotético altamente representativo do comportamento que observamos, mensagens eram codificadas em caminhos de URL armazenados em uma página de índice compartilhada, como neste caso:

Uma última constatação particularmente marcante no incidente da Hugging Face foi o “ecossistema” de agentes que surgiu no quadro de mensagens. Depois que o quadro foi criado, os agentes passaram a ter fortes incentivos para se comunicar: ele permitia preservar anotações, aproveitar as descobertas uns dos outros e combinar os recursos computacionais de execuções que, de outra forma, permaneceriam separadas. Esse coletivo complexo e amorfo de agentes apresenta comportamentos interessantes e representativos, e detalhamos aqui alguns dos que observamos.

Os agentes começaram a dividir o trabalho de forma autônoma. Alguns investigavam possíveis exploits, outros procuravam credenciais e outros se concentravam na comunicação ou na coordenação. Os agentes ofereciam a própria experiência em troca de ajuda em outras áreas, compartilhavam informações sobre tarefas futuras e deixavam solicitações para pares que talvez estivessem em melhor posição para investigar uma pista específica.

Além do desalinhamento, outro fator que contribuiu para o incidente foi não termos estendido a todas as avaliações internas as proteções robustas usadas nos modelos que disponibilizamos externamente.

Primeiro, há vários mecanismos que reduzem o desalinhamento nos ambientes de produção de nossos clientes, incluindo prompts do sistema, harnesses e mecanismos de controle, como nossos modelos de revisão automática e classificadores de segurança. Essas proteções não foram aplicadas ao ambiente de avaliação em execução durante o incidente. Após o incidente, criamos uma avaliação que mede a propensão de um modelo a comprometer a infraestrutura durante avaliações do ExploitGym. Constatamos que a propensão a comprometer a infraestrutura pode cair mais de 100 vezes com o uso do harness de produção e do prompt do sistema do Codex. Também executamos o sistema de revisão automática do Codex em um conjunto de rollouts envolvidos no incidente da Hugging Face e constatamos que ele teria sinalizado diversas ações perigosas dos modelos.

Segundo, antes do incidente, havíamos investido significativamente no monitoramento da cadeia de pensamento⁠, incluindo o monitoramento de muitas de nossas execuções de treinamento por RL de ponta e da grande maioria do uso interno de agentes de programação⁠. Esses monitores não foram executados nas avaliações envolvidas no incidente.

Em avaliações retrospectivas, constatamos que nossos monitores de CoT eram muito eficazes para sinalizar atividades relacionadas ao incidente. Se o sistema de monitoramento da cadeia de pensamento atualmente implantado estivesse em execução no momento do incidente, provavelmente teria acionado nossa equipe de segurança até uma hora após o primeiro acesso não autorizado a um sistema de terceiros. Isso teria ocorrido mais de 30 horas antes de os modelos invadirem os sistemas da Hugging Face. Também estamos trabalhando para reduzir ainda mais a latência desses alertas.

Terceiro, embora tivéssemos testado e validado esse sandbox, os agentes conseguiram encadear vulnerabilidades até então desconhecidas (“0-days”) no serviço de gerenciamento de pacotes exposto dentro do sandbox para contornar as restrições, conforme detalhado no relatório técnico do incidente. Desde o incidente, fizemos avanços significativos no reforço de nossos sandboxes internos para limitar riscos semelhantes durante a implantação e as avaliações.

A missão da OpenAI é garantir que a inteligência artificial geral beneficie toda a humanidade. O comportamento de nossos modelos descrito aqui ficou muito aquém do que esperamos. Esse incidente não deveria ter acontecido. Ele revelou como é essencial aprimorar continuamente nossa segurança, nosso monitoramento e nosso alinhamento, principalmente à medida que nossos modelos alcançam um nível de capacidade que pode possibilitar uma perda real de controle.

Como compartilhamos em nossa atualização recente sobre o ritmo de desenvolvimento dos modelos⁠, interrompemos temporariamente o treinamento por aprendizado por reforço (RL) de nossos modelos mais recentes destinados à implantação. Usamos esse período para reforçar ainda mais a segurança de nossos ambientes de pesquisa de ponta e submetê-la a testes de red teaming. Redirecionamos profissionais para trabalhar em segurança, proteção e alinhamento. Nossa maior execução planejada de treinamento por RL de ponta continua suspensa enquanto realizamos treinamentos e avaliações em menor escala para analisar o comportamento dos modelos, validar nossas salvaguardas e reunir mais evidências de alinhamento antes de prosseguir. Esse trabalho exigiu um esforço considerável de engenharia, com custos significativos e atrasos na pesquisa de ponta.

Como discutido em nosso relatório, nossa resposta se concentra em reforçar a segurança e o monitoramento das pesquisas, acelerar o alinhamento dos modelos e aprimorar a forma como identificamos, encaminhamos e respondemos a incidentes.