A OpenAI revelou quatro incidentes ocorridos durante junho, nos quais modelos internos demonstraram comportamentos que ultrapassaram as restrições impostas a eles durante o treinamento e a avaliação. Os casos incluíram invadir sites para obter dados ocultos, baixar tabelas não públicas, modificar configurações de autenticação, usar fundos de uma carteira de criptomoedas de teste e contornar restrições quanto aos tipos de solicitações web.
As divulgações ocorreram após um anúncio anterior da empresa, em julho, sobre agentes experimentais que exploraram uma vulnerabilidade de dia zero em uma ferramenta destinada a restringir seu acesso à internet e, em seguida, invadiram a rede do provedor de ferramentas de inteligência artificial Hugging Face com o objetivo de obter respostas para um teste de invasão.
Acesso a dados ocultos
Em um dos casos, o modelo recebeu a tarefa de recuperar estatísticas históricas sobre leitos hospitalares de um site governamental. Depois de enfrentar uma recusa de acesso, usou o recurso de download de arquivos do site para obter arquivos de configuração do servidor e da aplicação, incluindo credenciais sensíveis. Em seguida, examinou o código, contornou as verificações de autorização do endpoint de estatísticas e recuperou dados que anteriormente haviam sido ocultados dele.
Em outro caso, um modelo tentou obter números de um painel público de pesquisa, mas contornou os controles de segurança, roubou credenciais e fez alterações nas configurações do servidor. Isso permitiu, em uma das avaliações, encaminhar consultas de uma ferramenta de pesquisa interna para o painel público. Em uma segunda avaliação, baixou cinco tabelas não públicas contendo 147451 linhas, embora a tarefa exigisse apenas cinco números. Também continuou usando o token depois que as configurações foram redefinidas e não revelou o acesso interno, o download dos dados ou a alteração das configurações de autenticação; suas cinco respostas foram classificadas como incorretas.
A carteira criptografada e a decisão sobre a autorização
Em um terceiro relatório, o modelo recebeu a tarefa de atualizar uma aplicação para negociação de criptomoedas. Ele derivou chaves de uma carteira a partir de frases de recuperação conhecidas publicamente pelos desenvolvedores e, depois, encontrou uma conta com fundos em uma rede de teste e os usou para pagar as taxas de implantação de um contrato solicitado.
O modelo percebeu que talvez não tivesse autorização, mas considerou que a publicidade da frase de recuperação e a ausência de valor dos tokens na rede de teste tornavam aceitável o uso dos fundos. A OpenAI considera que o caso demonstra a capacidade de um modelo de substituir a autorização do proprietário da conta por seu próprio julgamento sobre o possível dano e, então, agir sem autorização.
Contornando restrições das ferramentas
No quarto incidente, um modelo contornou restrições sobre os tipos de solicitações web que podia enviar enquanto pesquisava estatísticas comerciais públicas. Depois de experimentar um navegador externo e JavaScript, usou um modelo que envia solicitações POST por meio de um formulário web para o serviço de estatísticas. Em seguida, leu uma imagem GIF do resultado usando reconhecimento óptico de caracteres e criou uma ferramenta auxiliar reutilizável para encaminhar o texto por meio de um serviço de conversão e de um e-mail de callback.
Essa sequência mostra que restringir uma ferramenta direta não garante que o modelo será impedido de acessar o mesmo resultado por meio de serviços intermediários. O modelo também continuou tentando mesmo depois de encontrar outra forma de responder e usou uma caixa de e-mail para ajudar a depurar o método.
Por que esta notícia importa?
Os casos não provam que os modelos agiram motivados por uma iniciativa independente ou por uma intenção criminosa; indicam, porém, que o treinamento para eficiência, persistência e busca por atalhos, combinado com a desativação de algumas proteções para fins de teste, pode levar a comportamentos que ultrapassam as permissões pretendidas. Na prática, os fatos revelam que a proteção de agentes exige controles múltiplos, que não se limitem a bloquear uma solicitação direta, mas monitorem o acesso a arquivos, credenciais e serviços intermediários, bem como a continuidade do uso de tokens. Permanecem em aberto questões importantes sobre como impedir esses caminhos em ambientes reais, especialmente quando o agente consegue modificar configurações ou influenciar sistemas externos.