Na semana passada, um agente de IA invadiu um ambiente de produção ao qual não deveria ter acesso. Ele identificou uma vulnerabilidade de dia zero, combinou-a com credenciais roubadas, elevou seus próprios privilégios e se deslocou lateralmente pela infraestrutura pertencente a uma empresa que não está sob o controle de seu operador. Nenhum invasor o comandou. Nenhum ser humano aprovou a ação. Ele estava buscando atingir uma pontuação de benchmark.
Esse foi o incidente OpenAI e Hugging Face divulgado nesta semana. Durante uma avaliação interna do GPT-5.6 Sol e de um modelo pré-lançamento ainda mais avançado, a OpenAI desativou algumas medidas de proteção contra recusa cibernética para permitir testes menos restritos.
O modelo foi muito além do esperado. Ele explorou uma vulnerabilidade zero-day em um proxy de registro de pacotes para escapar de sua sandbox, encontrou um caminho para a internet aberta, deduziu que o Hugging Face provavelmente hospedava o gabarito do benchmark no qual estava sendo testado e combinou credenciais roubadas com uma exploração de execução remota de código para roubá-lo diretamente dos sistemas de produção do Hugging Face. A Hugging Face detectou e conteve a intrusão usando sua própria equipe de segurança e seus próprios modelos antes mesmo que a OpenAI entrasse em contato. A OpenAI só detectou a fuga e as ações depois de questionar como o modelo havia obtido uma pontuação tão boa no benchmark em que estava sendo testado.
A OpenAI classificou o caso como “um incidente cibernético sem precedentes”. É mais do que isso. É um prenúncio do que está por vir.
Ignore a vulnerabilidade de dia zero por enquanto: ela será corrigida. O que deve preocupar todo CISO é o que o incidente revela sobre como os agentes acumulam acesso e como podem tomar medidas imprevistas para atingir um objetivo. Esse agente nunca pediu permissão a ninguém para acessar a infraestrutura da Hugging Face. Quando foi solicitado que ele testasse suas capacidades, ele determinou que a melhor maneira de fazer isso era encontrando um caminho por meio de uma cadeia de vulnerabilidades e credenciais herdadas. Ninguém concedeu esse acesso. Ninguém pediu ao agente para lançar um ataque. Ninguém estava monitorando em tempo real, até que as próprias defesas da Hugging Face identificaram a invasão.
Esse incidente estava tão distante dos princípios do Zero Trust quanto se poderia imaginar. É também a parte que se aplica diretamente aos ambientes corporativos que utilizam agentes atualmente. A maioria das organizações que implantam copilotos, pipelines autônomos e fluxos de trabalho baseados em agentes não consegue responder a perguntas básicas sobre eles: quantos agentes estão em execução, o que cada um deles pode realmente acessar, quem é o responsável por eles, a quais sistemas e dados eles têm acesso e se suas permissões já foram revisadas. Ao contrário dos usuários humanos, que trabalham apenas com um número limitado de permissões por vez, um agente pode testar todos os seus recursos de acesso, com rapidez e em grande escala, praticamente de forma simultânea. Os agentes também herdam permissões, as encadeiam e agem, muitas vezes mais rápido do que um ser humano poderia perceber, muito menos aprovar.
A gestão tradicional de identidade e acesso (IAM) foi criada para definir a que os usuários têm acesso, como devem se autenticar e o que constitui um risco.
O IAM pressupõe que uma pessoa solicite acesso, um gerente o aprove e um ciclo de revisão detecte qualquer desvio. Nenhuma dessas etapas se encaixa perfeitamente em um agente capaz de herdar credenciais dos serviços que chama e realizar milhares de ações autônomas em um fim de semana, que foi basicamente o que aconteceu neste caso: a Hugging Face reconstruiu posteriormente mais de 17,000 eventos registrados decorrentes desse único incidente.
Isso não chega nem perto do Zero Trust. E para preencher essa lacuna, é preciso mais do que um melhor alinhamento de modelos (embora a OpenAI esteja certa ao afirmar que isso também é necessário). É preciso tratar cada agente como uma identidade separada, com um inventário real, controles de acesso reais e responsabilização real — a mesma disciplina que as equipes de segurança já aplicam a contas humanas e de serviços, aplicada de forma consistente às contas não humanas.
Três recursos podem ajudar sua equipe de segurança a enfrentar esse desafio:
- As equipes de segurança precisam de visibilidade contínua sobre todos os agentes que operam em seu ambiente, incluindo aqueles que ninguém registrou.
- Eles precisam de controles de tempo de execução que determinem o que cada agente pode realmente fazer, com a intervenção humana em qualquer situação de consequências significativas.
- Eles precisam de uma estrutura de governança que certifique o acesso de forma contínua e corrija a situação no momento em que o comportamento de um agente parecer inadequado, e não apenas no próximo ciclo de auditoria.
Não há nada de extraordinário nessa lista de funções. Um agente que não esteja em seu inventário não pode ser gerenciado adequadamente. Um acesso que não seja controlado em tempo de execução não é confiável. E um sistema sem trilha de auditoria não pode ser certificado.
O incidente da Hugging Face será interpretado, em primeiro lugar, como uma história sobre a capacidade do modelo. É também uma história sobre identidade e uma falha bastante óbvia do modelo Zero Trust: uma identidade não gerenciada encontrou uma porta que ninguém sabia que estava aberta e conseguiu passar por ela.
Atualmente, toda empresa que utiliza agentes possui alguma versão dessa “porta”. A pergunta que vale a pena fazer após esse incidente não é se seus modelos estão seguros. É se você seria capaz de apresentar uma lista completa de todos os agentes com acesso aos seus sistemas neste momento, comprovar de onde vieram suas permissões e indicar quem está responsável por revisá-las.
Se a resposta for não, é por aí que se deve começar.
