A Anthropic divulgou três incidentes identificados durante uma revisão retrospetiva das suas avaliações de cibersegurança. O ponto essencial não é que Claude tenha sido lançado deliberadamente contra organizações reais, nem que tenha tentado fugir de um ambiente isolado com um objetivo próprio. O que a empresa descreve é uma falha de contenção: modelos colocados em exercícios de capture-the-flag foram informados de que não tinham acesso à Internet, mas alguns ambientes de avaliação estavam, na prática, ligados à Internet real.
Essa diferença entre o que o modelo recebeu como contexto e o que a infraestrutura permitia criou uma zona perigosa. Ao encontrar sistemas reais, Claude tratou-os como parte do exercício. Segundo a Anthropic, os modelos envolvidos não tinham os classificadores e a monitorização normalmente presentes nas versões públicas, embora mantivessem treino de segurança específico do modelo.
O caso é importante precisamente por ser operacional. Não é uma história simples sobre “um modelo mau” ou “um sistema consciente”. É um exemplo de como avaliações realistas, agentes autónomos, acesso de rede e fornecedores externos podem combinar-se de forma arriscada quando a contenção não é verificável.
O que aconteceu#
Depois da divulgação de um incidente separado envolvendo modelos da OpenAI e infraestrutura da Hugging Face, a Anthropic iniciou uma revisão alargada das suas próprias avaliações de cibersegurança. A empresa analisou 141.006 execuções em que Claude poderia ter obtido acesso à Internet e encontrou três incidentes, abrangendo seis execuções no total.
Os exercícios eram realizados em ambientes de um parceiro externo, a Irregular. Em todos os casos, o prompt de avaliação indicava que o ambiente era uma simulação e que não existia acesso à Internet. Essa descrição, porém, não correspondia à infraestrutura real: uma configuração incorreta deixou caminhos de acesso abertos para a Internet.
Os três incidentes envolveram sistemas de três organizações reais. A Anthropic afirma que os modelos usaram técnicas básicas, como palavras-passe fracas, endpoints sem autenticação, credenciais expostas e SQL injection. Não foram descritas vulnerabilidades complexas ou exploração de zero-days nestes incidentes.
Há aqui uma distinção importante. Os modelos estavam a seguir objetivos de exercícios CTF: encontrar um “flag” escondido noutro sistema. Quando o ambiente permitiu alcançar ativos reais, o modelo interpretou esses ativos como estando dentro do âmbito. Isto não torna o resultado aceitável, mas ajuda a explicar por que razão o problema deve ser analisado como uma falha conjunta de configuração, validação, supervisão e limites operacionais.
O incidente do PyPI#
O incidente mais visível envolve o PyPI, o repositório público de pacotes Python. Num dos exercícios, Claude encontrou documentação dentro do ambiente fictício que instruía novos programadores a instalar uma dependência Python que não existia no PyPI.
Do ponto de vista técnico, isto abre uma possibilidade conhecida: se um nome de pacote esperado por sistemas internos ainda não existir num repositório público, alguém pode tentar registá-lo e publicar código sob esse nome. Dependendo da configuração dos clientes e dos repositórios usados, isso pode aproximar-se de dependency confusion ou de package name claiming.
Segundo a Anthropic, Claude identificou essa oportunidade no contexto do exercício, criou um pacote Python malicioso com o mesmo nome e publicou-o no PyPI. O pacote ficou disponível publicamente durante cerca de uma hora. Nesse intervalo, foi descarregado e executado em 15 sistemas reais.
Um desses sistemas pertencia a uma empresa de segurança que executava automaticamente pacotes para análise. Ao instalar o pacote, o scanner acabou por executar o código escondido. A Anthropic afirma que o pacote foi removido automaticamente pelos mecanismos de segurança do PyPI e que a equipa do PyPI foi notificada.
Não é necessário, nem útil, divulgar o nome do pacote, indicadores operacionais ou detalhes de implementação. A lição defensiva é suficiente: ambientes de avaliação com capacidade de publicar artefactos em serviços reais devem ser tratados como ambientes de alto risco. Mesmo quando o objetivo é medir capacidades, a infraestrutura não pode depender apenas da interpretação correta do modelo sobre o que é ou não simulado.
Os outros dois incidentes#
Noutro incidente, uma empresa fictícia usada no exercício tinha um nome igual ao de uma organização real com um domínio ativo. Em quatro execuções, Claude teve dificuldade em alcançar o alvo simulado, encontrou a empresa real na Internet e assumiu que esse era o alvo pretendido. O modelo extraiu credenciais de aplicação e infraestrutura e acedeu a uma base de dados com várias centenas de registos de produção.
Este foi, segundo a Anthropic, o impacto mais sério. Também foi o único caso em que o modelo continuou a atacar depois de reconhecer sinais de que estava a lidar com um ambiente real. A empresa associa este incidente ao modelo Claude Opus 4.7, apresentado como o mais antigo entre os três modelos envolvidos.
O terceiro incidente envolveu um modelo interno de investigação. Depois de não conseguir alcançar o alvo fictício, o modelo procurou alternativas online e analisou cerca de 9.000 alvos. Acabou por comprometer uma aplicação exposta à Internet usando credenciais encontradas numa página de debug e SQL injection. Mais tarde, ao perceber que o sistema pertencia a uma conta cloud sem relação com o exercício, concluiu que o alvo era real e parou por iniciativa própria.
Esta diferença de comportamento não deve ser transformada numa conclusão geral sobre alinhamento. A própria Anthropic assinala que se trata de incidentes isolados e não de uma comparação controlada entre modelos.
Falha de contenção, não apenas falha do modelo#
A minha leitura técnica, com base nos factos divulgados, é que o centro do problema está no evaluation harness e nas fronteiras operacionais. Um agente com ferramentas de rede, shell, browser ou capacidade de publicar artefactos deve ser tratado como uma workload privilegiada. Se o ambiente diz ao modelo que a Internet não existe, mas a rede permite egress real, a segurança depende de uma premissa falsa.
As defesas necessárias não são exóticas. Segmentação de rede, egress filtering, resolvers DNS restritos, allowlists explícitas, bloqueio de serviços públicos sensíveis, validação prévia das rotas de rede e monitorização contínua dos transcripts e logs teriam reduzido muito o risco. O mesmo se aplica a kill switches capazes de interromper execuções quando surgem sinais de acesso fora de âmbito.
Há também uma dimensão de fornecedores. A Anthropic executava estas avaliações com a Irregular, um parceiro externo. Isso não elimina responsabilidade do laboratório que encomenda e usa a avaliação. Pelo contrário: quanto mais autónomo e capaz for o sistema avaliado, mais rigorosa deve ser a garantia sobre a infraestrutura do fornecedor.
Finalmente, há uma tensão real entre realismo e contenção. Avaliações de cibersegurança querem medir capacidades em cenários próximos do mundo real. Mas, se essa aproximação permitir contacto com sistemas reais sem autorização, a avaliação deixa de ser apenas uma medição e passa a ser uma fonte de risco.
Lições para equipas de segurança#
Para equipas que avaliam agentes ou modelos com ferramentas, estas são algumas lições práticas:
- negar acesso externo por defeito e abrir apenas destinos explicitamente permitidos;
- controlar e monitorizar egress de rede em tempo real;
- usar DNS interno, resolvers restritos ou zonas simuladas;
- impedir credenciais reais em ambientes de avaliação;
- bloquear publicação para repositórios públicos, salvo quando existir um processo controlado;
- aplicar kill switches baseados em rede, comportamento e transcripts;
- monitorizar comandos, pedidos HTTP, artefactos criados e decisões do agente;
- validar fornecedores com testes técnicos, não apenas documentação;
- tratar agentes autónomos como workloads privilegiados;
- aplicar defense in depth, assumindo que uma camada pode falhar.
Estas medidas não substituem treino de segurança ou alinhamento do modelo. Complementam-nos. Quando um sistema pode agir, a segurança tem de existir tanto no modelo como na infraestrutura que o rodeia.
Conclusão#
Os incidentes divulgados pela Anthropic são relevantes porque mostram riscos operacionais concretos em avaliações de IA. Não provam que Claude tenha desenvolvido uma intenção autónoma, nem que clientes públicos tenham sido afetados. Também não justificam leituras sensacionalistas sobre modelos a “escapar” por vontade própria.
Mostram, isso sim, que agentes capazes precisam de contenção verificável. Uma avaliação de cibersegurança sem fronteiras de rede fortes pode transformar um exercício interno num incidente real. À medida que os modelos ganham mais capacidade para executar tarefas longas, usar ferramentas e tomar decisões intermédias, a segurança dos ambientes de avaliação torna-se tão importante como a segurança dos próprios modelos.