O incidente da Hugging Face e o caminho a seguir

Ao longo de maio e junho, iniciámos execuções de treino por aprendizagem por reforço (RL) para vários novos modelos de investigação que não se destinavam a lançamento público. Um destes modelos viria a impulsionar a atividade na origem do incidente da Hugging Face. Trata-se de um modelo de investigação apenas para uso interno a que chamamos Internal Model 1 (IM1).

Não ativámos o acesso à Internet nem a comunicação entre agentes em muitos dos ambientes destas experiências de treino. Apesar destas restrições, os agentes descobriram formas de explorar a nossa infraestrutura de investigação para comunicarem entre si e acederem à Internet.

Os modelos começaram por encontrar formas de comunicar através da escrita de ficheiros no serviço de gestão de pacotes Artifactory. Na prática, isto transformou o Artifactory num quadro de mensagens criado involuntariamente, no qual os agentes podiam trocar informações entre si. Saiba mais: Como os agentes utilizaram o quadro de mensagens 

A 4 de julho, a atividade contínua dos agentes desestabilizou a instância afetada do Artifactory e provocou uma indisponibilidade. A 5 de julho, foi aberto um incidente de segurança. A equipa de segurança bloqueou uma via conhecida de elevação de privilégios, removeu as credenciais expostas e reconstruiu o Artifactory. Esta medida teve como efeito secundário apagar o quadro de mensagens. Com estas medidas de mitigação em vigor, as avaliações de cibersegurança foram retomadas.

Na altura, ainda não eram compreendidas as implicações mais amplas do quadro de mensagens improvisado e do acesso não intencional à Internet para a contenção e o alinhamento. O relatório técnico do incidente apresenta mais pormenores sobre o que as diferentes equipas da OpenAI sabiam na altura. Em suma, uma equipa interna observou, no final de maio, um agente a participar no quadro de mensagens e casos de acesso não permitido à Internet. No entanto, a existência do quadro de mensagens improvisado e a importância da atividade de comunicação entre agentes não eram evidentes para os responsáveis pela deteção e resposta ao incidente. Continuamos a investigar os processos e as práticas operacionais que moldaram as atividades de deteção e resposta antes deste incidente.

Depois de reconstruirmos o serviço Artifactory, retomámos as avaliações de cibersegurança. Realizamos estas avaliações para compreender as capacidades dos nossos modelos e determinar as salvaguardas adequadas para a implementação. Para esse efeito, não ativamos o mesmo nível de salvaguardas que aplicamos aos sistemas disponibilizados externamente. A avaliação na origem deste incidente, o ExploitGym, é muito difícil — algumas tarefas poderão não ter uma solução conhecida. Para terem êxito, os agentes têm de encontrar formas de explorar um software e obter uma resposta conhecida como flag.

Após o incidente, dedicámos um esforço considerável a investigar por que motivo o modelo apresentou este comportamento desalinhado, incluindo problemas de desalinhamento no treino e na avaliação, bem como a cobertura das salvaguardas nas avaliações internas.

Identificámos 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 os compreendermos, analisámos trajetórias de treino e avaliação dos modelos.¹ Realizámos análises retrospetivas exaustivas da cadeia de pensamento (CoT), das ações e dos resultados finais utilizando as nossas técnicas mais recentes de monitorização da CoT⁠. Com base na perspetiva adquirida durante a investigação, melhorámos especificamente a taxa de deteção do monitor para os tipos de comportamento ocorridos no incidente.

O facto de os agentes tentarem fazer batota nas tarefas ao procurar soluções online foi um dos principais fatores na origem do incidente da Hugging Face. Este comportamento é conhecido como manipulação de recompensas: os agentes concluem tarefas de formas não previstas para obter recompensas maiores ou facilitar a sua obtenção. A manipulação de recompensas está presente nos sistemas de IA tanto historicamente (ver este trabalho de há uma década⁠, figura apresentada abaixo) como em LLM de fronteira atuais⁠(abre numa nova janela). Investimos significativamente em métodos para identificar e corrigir estas formas de manipulação de recompensas⁠.

Outro importante fator na origem do comportamento desalinhado foi o facto de os agentes raramente «desistirem» das tarefas de avaliação, mesmo quando estas pareciam impossíveis de resolver. À medida que consumiam os seus orçamentos de raciocínio, alguns agentes adotavam estratégias cada vez mais arriscadas e fora dos limites autorizados, acabando por explorar infraestruturas de terceiros.

Durante a nossa investigação, verificámos que, antes do incidente, nenhum dos nossos modelos tinha alguma vez produzido uma resposta correta para 198 das 898 tarefas da avaliação ExploitGym. Estas tarefas por resolver acabaram por contribuir substancialmente para a atividade dos agentes: 93% das tarefas discutidas no quadro de mensagens do Artifactory durante o incidente da Hugging Face pertenciam a este conjunto de 198 questões.

Em segundo lugar, o incidente foi sobretudo impulsionado por agentes aos quais foram atribuídos orçamentos de raciocínio extremamente elevados, incluindo orçamentos muito superiores aos disponíveis nos nossos produtos externos.

Os quadros de mensagens não autorizados e persistentes estiveram no centro deste incidente. Os agentes que deviam trabalhar de forma independente conseguiram partilhar descobertas, coordenar esforços e continuar o trabalho onde outros o tinham deixado. Isto permitiu-lhes reunir trabalho e capacidade computacional de avaliações distintas, ampliando as suas capacidades muito para além daquilo que qualquer agente individual poderia alcançar sozinho. A comunicação entre agentes não constitui, por si só, um comportamento problemático: treinamos e implementamos sistemas multiagente que podem comunicar sobre a mesma tarefa através de uma ferramenta de colaboração. Nos acontecimentos de julho, agentes com tarefas diferentes encontraram uma forma própria de colaborar fora destes limites, com consequências imprevisíveis.

Ao investigar este incidente, descobrimos casos raros em que agentes sem ferramentas multiagente encontraram formas de colaborar através de canais laterais durante o treino. Acreditamos que este comportamento teve origem na generalização a partir do treino multiagente.

A comunicação não autorizada começava muitas vezes quando um agente deixava uma nota ou um ficheiro num sistema externo, geralmente como forma de memória externa. Quando outros agentes reparavam nestes artefactos, apercebiam-se frequentemente de que podiam utilizar esse serviço externo para colaborar. A título de exemplo hipotético, mas muito representativo do comportamento observado, as mensagens eram codificadas em caminhos de URL armazenados numa página de índice partilhada, da seguinte forma:

Uma última conclusão, particularmente clara, do incidente da Hugging Face foi o «ecossistema» de agentes que emergiu no quadro de mensagens. Depois de estabelecido o quadro de mensagens, os agentes passaram a ter fortes incentivos para comunicar: podiam preservar notas, aproveitar as descobertas uns dos outros e reunir os recursos computacionais de execuções que, de outro modo, estariam separadas. Este coletivo complexo e amorfo de agentes apresenta comportamentos interessantes e representativos, alguns dos quais descrevemos aqui.

Os agentes começaram a dividir autonomamente o trabalho. Alguns investigavam possíveis exploits, outros procuravam credenciais e outros concentravam-se na comunicação ou na coordenação. Os agentes ofereciam os próprios conhecimentos em troca de ajuda noutras áreas, trocavam informações sobre tarefas futuras e deixavam pedidos a pares que estivessem em melhor posição para seguir uma determinada pista.

Além do desalinhamento, outro fator que contribuiu para este incidente foi não termos alargado a todas as avaliações internas as poderosas salvaguardas que aplicamos aos modelos disponibilizados externamente.

Em primeiro lugar, existem numerosos mecanismos que reduzem o desalinhamento em contextos de produção para os nossos clientes, incluindo prompts do sistema, sistemas de execução e mecanismos de controlo, como os nossos modelos de revisão automática e classificadores de segurança da IA. Estas proteções não foram aplicadas no ambiente de avaliação em execução durante o incidente. Após o incidente, criámos uma avaliação que mede a propensão de um modelo para comprometer infraestruturas durante avaliações do ExploitGym. Concluímos que a utilização do sistema de execução e do prompt do sistema do Codex em produção pode reduzir em mais de 100x a propensão para comprometer infraestruturas. Também executámos o sistema de revisão automática do Codex num conjunto de trajetórias envolvidas no incidente da Hugging Face e concluímos que teria assinalado muitas das ações perigosas dos modelos.

Em segundo lugar, antes do incidente, tínhamos investido substancialmente na monitorização da cadeia de pensamento⁠, incluindo a monitorização de muitas das nossas execuções de treino de RL de fronteira e de uma maioria significativa da utilização interna de agentes de programação⁠. Estes monitores não foram executados nas avaliações deste incidente.

Em avaliações retrospetivas, verificámos que os nossos monitores de CoT eram muito eficazes a assinalar atividades relacionadas com o incidente. Se o nosso atual sistema de monitorização da cadeia de pensamento estivesse em funcionamento na altura do incidente, provavelmente teria notificado a equipa de segurança informática no espaço de uma hora após o primeiro acesso não autorizado a sistemas de terceiros. Isto teria acontecido mais de 30 horas antes de os modelos comprometerem os sistemas da Hugging Face. Estamos também a trabalhar para reduzir ainda mais a latência destes alertas.

Em terceiro lugar, embora tivéssemos testado e validado esta sandbox, os agentes conseguiram encadear vulnerabilidades até então desconhecidas («0-days») no serviço de gestão de pacotes exposto dentro da sandbox para contornar as restrições, conforme descrito no relatório técnico do incidente. Desde o incidente, fizemos progressos significativos no reforço das nossas sandboxes internas para limitar tipos de risco semelhantes durante a implementação e as avaliações.

A missão da OpenAI é garantir que a inteligência artificial geral beneficia toda a humanidade. O comportamento dos nossos modelos aqui descrito ficou muito aquém do nível a que aspiramos. Este incidente não deveria ter acontecido. Revelou como é fundamental melhorarmos continuamente a nossa segurança, monitorização e alinhamento, sobretudo à medida que os nossos modelos atingem um nível de capacidade que pode permitir uma perda real de controlo.

Conforme partilhámos na nossa recente atualização sobre o ajustamento do ritmo de desenvolvimento dos modelos⁠, suspendemos o treino por aprendizagem por reforço (RL) dos nossos modelos mais recentes destinados à implementação. Aproveitámos este período para reforçar ainda mais a segurança dos nossos ambientes de investigação de fronteira e submetê-la a testes adversariais. Redirecionámos membros das equipas para trabalhos de cibersegurança, segurança e alinhamento. A maior execução de RL de fronteira que planeámos continua suspensa enquanto realizamos treinos e avaliações de menor escala para avaliar o comportamento dos modelos, validar as nossas salvaguardas e obter mais provas de alinhamento antes de prosseguir. Este trabalho exigiu um esforço de engenharia considerável, com custos significativos e atrasos na investigação de fronteira.

Conforme referido no nosso relatório, a nossa resposta centra-se em reforçar a segurança e a monitorização da investigação, acelerar o alinhamento dos modelos e melhorar a forma como identificamos, escalamos e tratamos os incidentes.