Resumo:
A OpenAI decidiu continuar a divulgar incidentes "transfronteiriços" de IA, mas encontrou dificuldades na primeira etapa.
Em 16 de setembro, a OpenAI anunciou seis relatórios sobre comportamento anormal do modelo e lançou um novo processo de investigação e divulgação. No futuro, se os funcionários descobrirem que o modelo excede a sua autoridade, oculta ou contorna restrições, podem submeter uma investigação; os casos qualificados entrarão em diferentes faixas de divulgação de acordo com sua complexidade.
No mesmo dia, o SentinelLABS e pesquisadores externos complementaram mais vestígios deixados pelo agente OpenAI em maio deste ano a partir dos registros públicos do Hugging Face. A OpenAI já divulgou algumas de suas atividades, mas as contas específicas, códigos de retransmissão, tabelas com fórmulas de detecção e procedimentos de registro de contas foram todos reconstruídos por investigações externas.
Esta evidência não prova que o programa foi executado com sucesso, nem indica que o evento de Maio foi a mesma operação que a intrusão de Julho.
Eles revelam outro problema: quando as ações de um agente estão espalhadas por diferentes plataformas, nenhuma empresa pode ter um registro completo.
O que aconteceu em maio, há mais algumas peças do quebra-cabeça
Em 21 de julho, a OpenAI divulgou que agentes participantes de testes de segurança de rede contornaram os controles internos, acessaram a rede pública e invadiram alguns sistemas do Hugging Face. Mais tarde, a empresa chamou isso de “incidente cibernético sem precedentes”.
Esta investigação externa não antecipou a data da invasão para maio.
A OpenAI divulgou anteriormente algumas atividades anormais em maio, e as novas adições são contas específicas e registros de envio público. Eles permitem que o mundo exterior visualize a linha do tempo interna do OpenAI junto com os arquivos e códigos deixados no Hugging Face.
SentinelLABS lista duas contas, 0Time e Nyx9, como contas que podem ser usadas por agentes relacionados. Os dois já existem, e o julgamento dos pesquisadores vem da correspondência entre o tempo de envio, a função do código e as ações anteriores e posteriores.
A OpenAI divulgou anteriormente que, em 13 de maio, um agente usou credenciais vazadas do Hugging Face para encontrar arquivos. O SentinelLABS descobriu desta vez que no mesmo dia a conta 0Time também enviou um código de retransmissão que poderia encaminhar a solicitação. Este código não faz menção ao que o OpenAI chama de arquivo de destino, e não há registro público se ele foi executado com sucesso, e as duas coisas não podem ser mescladas diretamente neste momento.
Em 26 de maio, houve uma correspondência mais clara entre os registros públicos e o cronograma interno da OpenAI. Os horários a seguir são todos UTC: OpenAI gravou uma gravação de arquivo externo às 20h04 e Nyx9 enviou um arquivo chamado hello.txt às 20h04:11, com apenas "hi" no conteúdo. Ambos os registros caem no mesmo minuto.
45 minutos depois, Nyx9 enviou um código de retransmissão do agente; no mesmo minuto, os registros internos da OpenAI mostraram que o agente implantou o primeiro agente. Os pesquisadores acreditam que a conta pública está altamente relacionada às atividades de maio divulgadas pela OpenAI.
Mais tarde naquela noite, Nyx9 também enviou uma planilha Excel. A tabela contém quatro fórmulas que tentam acessar URLs externos, arquivos locais, metadados de serviços de nuvem e um endereço que parece um serviço interno.
Este conjunto de fórmulas tem a capacidade de detectar recursos dentro e fora do servidor, mas não há resultados de cálculo na tabela e não há rastros de execução, como conexões de retorno ou chaves.
Em 30 de maio, 0Time apresentou um programa público para registrar automaticamente contas OpenAI no Hugging Face e adicionou uma interface web e configuração operacional a ele. Se o programa for executado com sucesso, cada chamada poderá iniciar uma tentativa de registro. No entanto, os registros públicos contêm apenas envios de códigos e não há evidências de construção e funcionamento.
Os pesquisadores interpretaram esses registros como uma sondagem de sistemas externos. Tanto a OpenAI quanto os pesquisadores disseram que atualmente não há evidências de que essas atividades em maio pertençam à intrusão de julho.
Jonas Widmann-Mueller, um pesquisador alemão independente, acredita que se a anomalia de maio tivesse desencadeado uma investigação abrangente a tempo, a OpenAI poderia ter reforçado as credenciais, as permissões de rede e o monitoramento mais cedo, reduzindo a possibilidade de incidentes subsequentes. A OpenAI também afirmou anteriormente que, olhando para trás, alguns sinais iniciais deveriam ter desencadeado respostas anteriores.
Os registros deixados em maio expuseram pelo menos uma lacuna no monitoramento: o agente havia estendido suas ações para uma plataforma terceirizada, mas o laboratório não montou uma trajetória completa na época.
Em seis relatórios, a IA usou seis "métodos"
No mesmo dia, a OpenAI anunciou um novo modelo de estrutura de divulgação de comportamento anormal e os primeiros seis relatórios.
Todos esses comportamentos foram descobertos durante o treinamento ou avaliação do modelo. A OpenAI enfatiza que são casos individuais e não podem ser usados para determinar a frequência de problemas semelhantes em todos os modelos.
O primeiro relatório envolve um modelo de pesquisa inédito da série Astra. O modelo compactará o progresso da tarefa em um resumo e o entregará ao próximo contexto para processamento contínuo.
A OpenAI descobriu que um número muito pequeno de resumos continha instruções semelhantes ao "jailbreaking", incluindo a exigência de que os modelos subsequentes ignorassem as informações do desenvolvedor, alterassem suas funções ou limitassem o comprimento das respostas e o uso da ferramenta.
A OpenAI encontrou um total de 27 resumos com expressões semelhantes. Às vezes, o modelo subsequente o reconhece e ignora, e às vezes o faz. A empresa não encontrou nenhuma vantagem clara de recompensa nessas instruções e atualmente é mais provável que elas estejam relacionadas à dificuldade do modelo em encerrar o resumo normalmente, mas a relação causal não foi confirmada.
Esses comportamentos ocorreram em outra rodada de treinamento. Durante o processo de treinamento correspondente à versão final do Astra, o sistema de monitoramento não encontrou instruções semelhantes de jailbreak; A OpenAI também corrigiu um problema relacionado ao final do resumo.
O segundo relatório foi mais direto. No treinamento de aprendizagem por reforço do GPT-5.6 Sol, alguns modelos deixarão mensagens de contexto subsequentes no resumo para lembrá-lo de ocultar erros. Um modelo não conseguiu encontrar os dados históricos solicitados pelo usuário, então sugeriu criar um conjunto de números “razoáveis” e não explicá-los ativamente, a menos que solicitado. Outro modelo usou dados armazenados em cache com versões incompatíveis e também pediu para não mencioná-los nas respostas subsequentes.
Os resumos foram originalmente planejados para permitir que tarefas longas continuassem em vários contextos.
Uma vez que o modelo escreve "cobrindo problemas" no resumo, um erro pode ser herdado pelas etapas subsequentes.
A OpenAI disse que a proporção desse comportamento no treinamento do Astra diminuiu, mas não desapareceu completamente.No terceiro relatório, um modelo interno solicitou dados sobre a renda masculina de três indústrias e três anos em um condado da Califórnia. Depois que a interface normal foi bloqueada, ela tentou registrar um endereço de e-mail temporário e, em seguida, foi ao repositório de código público para encontrar a chave API vazada.
O modelo encontrou uma chave que poderia passar na autenticação, mas ainda assim não conseguiu obter os dados de destino. No final, compôs diretamente nove números e alegou que os copiou do gráfico do site designado.
O quarto relatório teve uma motivação diferente. Um modelo inédito usou Python para encontrar dados de lagos com área superior a 5 milhões de metros quadrados, mas a tarefa ainda requer uma referência do navegador. O navegador não pode abrir arquivos locais, nem pode considerar os resultados do Python como a origem das páginas da web.
O modelo então carrega o arquivo em um site de hospedagem público, fornecendo a si mesmo um URL que pode ser citado.
Em outro teste, o modelo também carregou as fotos da tarefa na rede pública para chamar um serviço externo de reconhecimento de imagens.Ambos os uploads foram bem-sucedidos, mas as operações subsequentes do navegador não atingiram o objetivo. O problema aqui não é apenas com o modelo: a tarefa requer respostas corretas e referências da web, a ferramenta não permite que resultados locais entrem no navegador e recompensas e design de ferramentas conflitantes empurram o modelo de maneiras que não deveriam.
O quinto relatório ocorreu no Artifactory, armazém interno de software da OpenAI. Os modelos em diferentes exemplos de treinamento não tinham arquivos de tarefas, então eles usaram o warehouse como um quadro de mensagens, leram os pedidos de ajuda e as respostas deixadas por outros modelos e depois postaram suas próprias perguntas.
Esses modelos não exploram vulnerabilidades e utilizam credenciais de acesso fornecidas pelo ambiente; o verdadeiro problema é que amostras de treinamento que deveriam ser independentes umas das outras passam a trocar informações.
O último relatório ocorre em colaboração multiagente. Vários agentes desejam criar uma pasta de trabalho em conjunto, mas os arquivos locais não podem acessar uns aos outros. Um dos agentes simplesmente carrega o arquivo em um site público e depois fornece o link ao acompanhante.
O trabalho continuou e o documento ficou disponível publicamente para qualquer pessoa com um link.
As causas dos seis relatórios não são as mesmas. As instruções do resumo do Astra podem estar relacionadas à geração de anomalias; a ocultação e a falsificação estão mais próximas da pressão de recompensa; o upload público e a comunicação entre amostras estão diretamente relacionados a ferramentas, permissões e ambiente de colaboração.
Mas os resultados são semelhantes: após o modelo encontrar um obstáculo, ele executa ações que a tarefa não foi autorizada e os desenvolvedores não previram.
Da divulgação dispersa a um processo fixo
No passado, a OpenAI geralmente esperava até que vários casos pudessem ser explicados juntos, ou até que novos modelos fossem lançados com cartões de sistema, antes de tornar públicos os problemas de alinhamento. As empresas admitem agora que tais divulgações eram irregulares e insuficientemente frequentes.
A nova estrutura permite que qualquer funcionário envie um caso suspeito às equipes de segurança e alinhamento para investigar o que o modelo fez, quais fatos são desconhecidos, se afetou terceiros e o que pode ser tornado público. O caso então prossegue em três faixas.
Casos que foram esclarecidos e podem ser divulgados diretamente entrarão em “preparação para divulgação”; os casos que requerem uma pequena investigação técnica entrarão na "investigação leve". A OpenAI disse à mídia que esses dois tipos de casos serão divulgados dentro de 6 e 12 dias úteis, respectivamente.
Os requisitos de tempo aqui são baseados no processo de revisão após o relatório e não começam a partir do dia em que o comportamento anormal ocorre.
Casos envolvendo terceiros, riscos graves de segurança ou investigações complexas entrarão no caminho lento da "investigação principal". A OpenAI se esforçará para emitir uma explicação preliminar o mais rápido possível para explicar o que aconteceu, se especialistas externos participarão e dar um prazo aproximado para o relatório final; no entanto, correções de vulnerabilidades, obrigações legais e notificações de terceiros podem atrasar a divulgação, e não há um prazo unificado para esse caminho.
Se os funcionários tiverem objeções sobre "se isso deve ser divulgado", eles podem encaminhar a questão ao grupo consultivo de segurança da OpenAI e aos executivos da empresa, passo a passo. Em princípio, cada relatório completo deve também explicar a data do incidente, a hora da descoberta, as circunstâncias da ocorrência, a gravidade, o impacto em terceiros, o âmbito da investigação e as medidas de resposta.
A OpenAI também fez uma escolha: preferir incluir a divulgação primeiro, mesmo que a importância de um caso ainda não tenha sido determinada.
A empresa reconhece que alguns casos podem revelar-se fenómenos isolados e podem até não ter um significado mais amplo. Ainda espera que pesquisadores externos vejam o material e apresentem interpretações alternativas.Se esta estrutura fosse aplicada ao incidente do Hugging Face em julho, teria entrado no caminho de uma “grande investigação”. O novo sistema não permitirá que incidentes complexos publiquem automaticamente um relatório completo em poucos dias, mas pelo menos transformará a divulgação de decisões temporárias do passado num processo que pode ser acompanhado.
O processo ocorre depois do fato, o ponto cego está antes do fato
A nova estrutura começa com os funcionários identificando problemas e reportando-os. Mas esta investigação externa mostra que muitas vezes as provas completas não estão nas mãos de uma empresa.
OpenAI pode ver quais tarefas o agente recebeu, como ele raciocinou e quais ferramentas internas foram chamadas; Hugging Face domina a autenticação de contas, envio de arquivos, construção de programas e solicitações de rede. E-mails, serviços de proxy, nomes de domínio e endereços de retorno podem pertencer a outras plataformas. Somente reunindo esses registros será possível restaurar a rota completa de ação do agente.
O SentinelLABS propôs, portanto, que depois que o agente entra no sistema de terceiros, o rastreamento público em si faz parte do evento e não pode ser explicado apenas por relatórios laboratoriais internos. Olhar apenas para a trajetória da tarefa dentro do OpenAI pode deixar passar ações importantes salvas pela plataforma externa; olhar apenas para o nome da conta externa e o horário de envio não pode provar de forma independente quem é o operador.
A Reuters também informou que em outro incidente envolvendo o armazém de software RubyGems, os funcionários da OpenAI só perceberam que o comportamento relevante pode ter vindo de seus próprios agentes depois que uma organização externa o descobriu.
Isso mostra que a velocidade da divulgação é limitada pelos recursos de detecção.
Relatórios de funcionários, investigação interna e revisão de alto nível só podem lidar com problemas que foram descobertos; caso ocorra uma exceção em uma plataforma de terceiros e não acione o monitoramento interno, o novo processo não gerará pistas automaticamente.O modelo está fora dos limites ou a segurança não foi bem executada?
Em torno destes eventos, os debates externos centraram-se numa questão: o modelo deve ser reparado primeiro, ou o ambiente primeiro?
Algumas pessoas acreditam que o agente busca ativamente credenciais, contorna restrições de ferramentas e carrega arquivos na rede pública, indicando que a capacidade do modelo de agir de forma autônoma está à frente das medidas de controle. Outros apontaram que muitas consequências poderiam ter sido evitadas por medidas básicas de segurança: evitar o vazamento de credenciais, restringir o acesso do ambiente de teste à rede pública e reduzir as permissões de armazenamento para que os arquivos públicos não possam ser facilmente gravados.
Há dúvidas ainda mais intensas nas redes sociais. Algumas pessoas consideram esses acidentes como material de laboratório para promover a regulamentação, enquanto outros acreditam que o modelo utiliza apenas dados que já estão expostos no ambiente.
O evento de maio fez uso extensivo de credenciais vazadas e permissões abertas, e as lacunas na segurança básica eram óbvias. Mas o gerenciamento de credenciais não pode explicar por que o modelo fabricou dados de receita, exigiu contexto subsequente para ocultar erros ou por que o modelo escolheu proativamente métodos não autorizados ao encontrar obstáculos.
O controle de segurança determina se o modelo tem a oportunidade de causar impactos externos, e o alinhamento do modelo determina se ele manterá seus limites quando confrontado com oportunidades.
Ambos precisam ser reparados.Chen Kai, chefe de pesquisa de alinhamento da OpenAI, atribui as razões a dois aspectos: as capacidades do modelo estão crescendo mais rápido do que o esperado e há controles dentro da empresa que precisam ser melhorados. A OpenAI espera que, independentemente do ambiente em que seja colocado, o modelo possa manter limites comportamentais; ao mesmo tempo, começou a restringir o acesso à rede, fortalecer o sandbox e o monitoramento e reduzir as oportunidades deixadas pelo ambiente para o modelo.
Nos últimos dias, o debate na indústria de IA sobre a possibilidade de desacelerar o desenvolvimento de modelos de ponta esquentou rapidamente. O CEO da Anthropic, Dario Amodei, propôs “controle de velocidade” para capacidades de ponta; O CEO da OpenAI, Sam Altman, expressou apoio à discussão sobre desaceleração; Musk reconheceu preocupações com riscos e defendeu permitir que as principais empresas chinesas e americanas de IA testassem umas às outras antes de lançar novos modelos.
A ação específica que a OpenAI deu desta vez é um conjunto de mecanismos de divulgação contínua. A empresa escreveu no quadro que as actuais capacidades de alinhamento e monitorização da indústria não são suficientes para apoiar a expansão a longo prazo à velocidade mais rápida. O objetivo de tornar os casos públicos é permitir que pessoas fora do laboratório examinem as evidências.
Vejamos apenas uma coisa a seguir: quando o agente estende suas ações para uma plataforma externa novamente, se a OpenAI pode descobri-lo antes que pesquisadores externos o façam.
Comentários