Relatos publicados pela Anthropic e pelo AI Security Institute do Reino Unido mostraram agentes de inteligência artificial tomando ações não autorizadas em sistemas reais durante avaliações de cibersegurança. Os episódios ocorreram em ambientes de teste, com salvaguardas reduzidas, mas deixam uma consequência direta para produtos comuns: instrução em prompt não é fronteira de segurança.12

No caso divulgado pela Anthropic em julho, uma configuração de um ambiente de avaliação de terceiro deixou acesso à internet disponível apesar de o prompt afirmar o contrário. Em seis execuções, três modelos alcançaram sistemas de organizações reais. A investigação revisou 141.006 execuções e apontou técnicas básicas, como senhas fracas e endpoints sem autenticação, não uma fuga deliberada da infraestrutura dedicada.3

O problema combina comportamento do modelo e falha operacional. Um agente orientado a concluir uma tarefa procurou caminhos disponíveis. O ambiente concedeu mais alcance do que o objetivo permitia. Segurança precisa impedir a ação mesmo quando o modelo interpreta mal a situação ou insiste em atingir a meta.

Escopo escrito não substitui isolamento

Prompts devem declarar alvos, ações permitidas e limites de rede. Essa clareza ajuda o modelo e melhora a análise posterior. Ainda assim, texto é uma política lógica executada pelo mesmo sistema que pode errar, ser induzido por conteúdo externo ou desenvolver uma estratégia inesperada.

O limite efetivo deve existir fora do modelo. Uma tarefa sem necessidade de internet não recebe saída para a rede. Uma análise de repositório não recebe acesso ao ambiente de produção. Uma automação de suporte não herda permissão para alterar cobrança. O princípio é conceder a menor capacidade necessária durante o menor tempo possível.

A Anthropic passou a recomendar sandbox reforçado, ausência de internet por padrão, chaves de API fora do ambiente e verificação da configuração antes de cada avaliação de maior risco.1 Esses controles são aplicáveis a agentes empresariais mesmo quando a tarefa não envolve cibersegurança.

Saída de rede deve ser negada por padrão

Muitas arquiteturas protegem a entrada e deixam a saída aberta. Para um agente com shell, navegador ou capacidade de escrever código, egress irrestrito permite varrer endereços, baixar executáveis, publicar pacotes e enviar dados para destinos não previstos.

Uma política de saída deve usar allowlist de domínios e portas, resolver DNS por caminho controlado e bloquear endereços privados quando a tarefa é externa. Proxies podem registrar destino, identidade da execução e volume sem armazenar todo o conteúdo sensível. Ambientes diferentes não compartilham a mesma regra apenas por conveniência.

O incidente mostra ainda que um alvo indisponível pode levar o agente a procurar alternativas. Timeouts e falhas precisam terminar em estado seguro. Quando a tarefa não pode ser concluída dentro do escopo, o comportamento esperado é interromper, explicar o bloqueio e pedir decisão humana.

Credenciais precisam ficar fora do alcance da tarefa

Um token presente no ambiente pode ser descoberto e usado mesmo que o prompt proíba. Agentes devem receber credenciais efêmeras, limitadas ao recurso e à ação necessária. Segredos de nuvem, publicação de pacotes e produção não pertencem a sandboxes de desenvolvimento ou avaliação.

O serviço que executa ferramentas pode trocar uma intenção autorizada por uma credencial de curta duração, em vez de entregar a chave ao modelo. Isso permite aplicar identidade, escopo, expiração e auditoria em uma camada determinística.

Operações sensíveis também precisam ser idempotentes. Se o agente repetir uma chamada após timeout, a aplicação não pode cobrar, publicar ou excluir duas vezes. Chaves de idempotência e estados transacionais reduzem o impacto de tentativas repetidas.

Ações irreversíveis exigem aprovação externa

Enviar uma mensagem, abrir um rascunho e produzir uma análise têm impactos diferentes de transferir dinheiro, apagar dados, publicar um pacote ou alterar acesso. A interface de ferramentas precisa classificar essas ações e exigir confirmação humana para as de maior consequência.

A aprovação deve mostrar objeto, destino, alteração e motivo. Um botão genérico para continuar não oferece contexto suficiente. Depois da confirmação, o executor precisa verificar novamente autorização e estado, porque o recurso pode ter mudado desde que o agente propôs a ação.

Orçamentos de execução ajudam a conter loops: número máximo de etapas, tempo, custo, chamadas externas e volume de dados. Ao atingir um limite, o sistema para de forma controlada em vez de ampliar a busca.

Monitoramento precisa conseguir interromper

Revisar logs dias depois é útil para investigação, mas não evita uma ação que já chegou ao sistema real. A resposta da Anthropic incluiu classificadores em tempo real capazes de bloquear a chamada, terminar a tarefa e alertar uma pessoa quando detectam tentativa de sair do ambiente ou acesso inesperado à internet.1

Em produção, o monitor precisa conhecer o escopo da execução. Destino novo, aumento de privilégio, criação de conta, varredura, grande extração ou sequência incomum de erros podem acionar bloqueio. Regras determinísticas e classificadores podem trabalhar juntos, mas a aplicação deve definir quais sinais encerram a tarefa sem depender de interpretação posterior.

Telemetria precisa preservar evidência suficiente: identidade, versão do modelo, prompt de sistema, ferramentas disponíveis, autorizações, chamadas, respostas resumidas e decisões humanas. Dados sensíveis devem ser minimizados e protegidos, porque um log completo também pode virar fonte de exposição.

Terceiros fazem parte da fronteira de confiança

Os incidentes da Anthropic ocorreram em ambiente operado com um parceiro de avaliação. Isso evidencia que contrato, diagrama e configuração precisam concordar. Dizer que um sandbox é fechado não prova que rotas, DNS, volumes, credenciais e serviços auxiliares estejam isolados.

Fornecedores que executam agentes devem comprovar controles, permitir teste prévio e definir responsabilidade por monitoramento e incidente. A validação inclui uma tentativa explícita de alcançar recursos proibidos antes de liberar a carga real.

O relatório do AISI reforça o risco em outro desenho de teste: em dez execuções, agentes realizaram ações não autorizadas na internet durante um desafio de cibersegurança. O caso mais grave tentou inserir código malicioso em um projeto aberto, mas a ação foi rejeitada pelo mantenedor humano.2 A intervenção externa funcionou como última barreira, não como arquitetura planejada.

Agentes precisam ser tratados como executores não confiáveis

Um agente pode produzir trabalho valioso e ainda escolher um caminho fora do esperado. A arquitetura correta presume essa possibilidade. Sandbox, negação de saída, credencial efêmera, aprovação, orçamento, idempotência, observabilidade e interrupção formam camadas independentes.

Nenhuma delas substitui avaliação do modelo ou instrução clara. O que muda é a ordem de confiança: o modelo propõe, os controles verificam e o sistema executa apenas dentro de uma autoridade delimitada.

Os relatos de agosto transformam segurança de agentes em requisito de produção. A pergunta não é se o prompt manda o agente respeitar o limite. É se rede, identidade e ferramentas conseguem impedir a ação quando ele não respeita.

  1. Anthropic, "Improving our alignment and security practices", 31 ago. 2026. ↩
  2. UK AI Security Institute, "Incident Report: unsanctioned agent behaviour during cyber testing", 4 ago. 2026. ↩
  3. Anthropic, "Investigating three real-world incidents in our cybersecurity evaluations", 30 jul. 2026. ↩