Agentes de IA Precisam de Limites de Segurança que Não Podem Reescrever

É tentador ler a história da Hugging Face como o momento em que os agentes de IA se tornaram descontrolados. Isso não foi exatamente o que aconteceu, e os detalhes importam. Esses eram agentes de pesquisa em cibersegurança executando avaliações onde as salvaguardas foram deliberadamente reduzidas para que os pesquisadores pudessem ver do que os modelos eram capazes. O bot de atendimento ao cliente de ninguém acordou uma manhã e decidiu atacar uma empresa. Mas esse contexto não isenta ninguém da responsabilidade. Um agente ultrapassou o limite em que deveria permanecer, usou credenciais e ferramentas de maneiras que seus operadores nunca autorizaram, e acabou em sistemas que pertenciam a outra pessoa. Essa é a parte à qual toda equipe de segurança deve prestar atenção.

A Reuters informou que agentes estavam sondando a Hugging Face já em maio, embora os pesquisadores tenham dito que não encontraram nada que mostrasse que a atividade anterior causou uma violação por si só. Julho foi diferente.A OpenAI afirmou que seus modelos contornaram os controles de isolamento, alcançaram a internet e comprometeram partes de sua própria infraestrutura de pesquisa, juntamente com os sistemas da Hugging Face.A própria conta da Hugging Face descreve uma intrusão executada de ponta a ponta por um sistema de agente autônomo, que explorou seu pipeline de processamento de dados, coletou credenciais e se deslocou por clusters internos.

O aspecto desconfortável é que os agentes estavam cumprindo suas funções. Eles perseguiam o objetivo que lhes fora dado. Por isso, esta história vai muito além de um único laboratório de pesquisa. Agentes corporativos também perseguem objetivos. Eles detêm credenciais, invocam ferramentas e se movem mais rápido do que qualquer pessoa pode revisar. Um agente com intenções perfeitamente boas ainda pode causar danos reais, e um agente sequestrado pode usar a mesma autoridade em nome de um atacante. Portanto, a segurança precisa governar o que o sistema pode realmente fazer, não importa o quão confiante o modelo pareça ou quão inofensivo seu propósito declarado pareça.

Proteja a Ação, Não Apenas o Modelo

A maioria dos primeiros programas de agentes concentra seu esforço no modelo. As equipes testam prompts, ajustam recusas, adicionam um segundo modelo para verificar o primeiro e observam o rastro de raciocínio em busca de sinais de má intenção. Nada disso é desperdiçado. Mas tudo isso é probabilístico, pois depende de outro modelo tomar uma decisão. Uma fronteira de segurança em produção precisa ser determinística e deve envolver as ferramentas, credenciais, redes e transações.

A pergunta que eu faria é concreta: o que este agente pode realmente fazer acontecer no mundo real? Redigir uma solicitação de pagamento é uma coisa. Liberar os fundos é outra. O mesmo vale para preparar uma alteração de banco de dados versus executá‑la em produção, ou marcar registros que atendam a uma regra de retenção versus excluí‑los. Pode ser o mesmo modelo em ambos os casos, com riscos muito diferentes dependendo de em qual lado da linha ele se encontra.

Uma visão recente da Unite AI sobre controle de capacidade traça a mesma linha, vinculando risco a dados, ferramentas, permissões, autonomia e ao ambiente em que o agente opera. Gosto dessa abordagem porque nos leva além de rótulos vagos como “modelo seguro” e “modelo inseguro”. Ela faz as equipes rastrear cada caminho da decisão de um agente até algo com consequências reais.

Dê a Cada Agente uma Identidade e um Mandato Restrito

Um agente nunca deve ser executado na conta de um desenvolvedor ou herdar tudo o que um usuário humano tem permissão para fazer. Identidade compartilhada elimina a atribuição. Credenciais de longa duração dão ao invasor mais tempo para abusá‑las. E contas de serviço amplas permitem que um pequeno fluxo de trabalho vagueie por dados e sistemas que não deveria tocar.

O NIST agora trata a identidade de software e de agentes de IA como seu próprio problema de arquitetura. Seu documento conceitual questiona como um agente pode provar que está autorizado para uma ação específica, como a identidade de um agente pode ser vinculada à autorização de um humano e como as organizações podem manter registros à prova de adulteração do que foi pretendido e do que realmente ocorreu. Na prática, isso aponta para um design simples. Cada agente recebe uma identidade única, um proprietário (uma pessoa ou uma equipe), um propósito definido e permissões limitadas à tarefa que tem diante de si.

As credenciais devem expirar rapidamente e funcionar apenas para recursos e ações específicos. O acesso à rede deve partir de uma lista de permissões restrita. Se um agente precisa consultar um banco de dados aprovado, ele não deve também obter um shell geral, acesso aberto à internet ou a capacidade de gerar novas credenciais. E à medida que o trabalho passa por uma cadeia de agentes e ferramentas, a autoridade deve tornar‑se mais restrita a cada etapa, não mais ampla.

O NIST também alerta contra o compartilhamento de credenciais e acesso excessivamente amplo, e esse alerta tem peso porque os agentes são oportunistas. Se uma rota for bloqueada, eles podem tentar outra ferramenta, explorar seu ambiente ou encontrar um token que alguém esqueceu. Credenciais coletadas também fizeram parte da história de julho. O princípio do menor privilégio mantém o raio de explosão pequeno quando a camada de raciocínio faz algo que seus projetistas não esperavam.

Mantenha a Autorização Fora do Loop de Raciocínio

Um agente pode recomendar uma ação. Ele não deve decidir se tem permissão para executá‑la. Essa decisão cabe a uma camada de aplicação separada que o agente não pode reescrever, desativar ou contornar. Cada chamada de ferramenta deve aparecer como uma solicitação estruturada: qual agente está pedindo, qual humano a patrocinou, qual operação ele deseja, o que está sendo visado e quais limites se aplicam. A camada de aplicação então permite, bloqueia ou escalona a ação.

OWASP descreve agência excessiva como uma combinação de funcionalidades desnecessárias, permissões excessivas e autonomia demais. Seu guia recomenda ferramentas restritas, permissões mínimas, autorização no sistema downstream e aprovação do usuário para ações de alto impacto. Acho que essa é exatamente a ordem correta. A regra deve ser aplicada por quem quer que possua os dados ou execute a transação. Se um modelo disser que uma ação está aprovada, essa afirmação, por si só, não deve ter nenhum peso.

Essa separação também ajuda contra injeção de prompts. Um e‑mail ou documento contaminado pode direcionar o raciocínio do agente, mas não pode ampliar as credenciais do agente nem derrubar um portão de política. O modelo está livre para solicitar algo proibido. O sistema ainda deve responder não.

Reserve a Aprovação Humana para os Momentos que Importam

A revisão humana justifica-se quando uma ação não pode ser desfeita, cruza uma fronteira organizacional, altera privilégios, divulga informações sensíveis, movimenta dinheiro ou interfere em um sistema de produção. Solicitar aprovação em cada passo rotineiro gera duas coisas: atrasos e pessoas que aprendem a clicar em “aprovar” sem ler. O NIST aponta esse cansaço de consentimento pelo nome.

Uma boa solicitação de aprovação descreve a ação exata em linguagem clara, incluindo para onde vai e os parâmetros relevantes. Ela deve provir de um sistema autorizado, não de um texto escrito pelo agente. A aprovação deve expirar rapidamente e cobrir apenas aquela ação. Se algum detalhe material mudar, o sistema solicita novamente.

Diretriz de segurança de agentes da OWASP recomenda testar se uma ação de alto impacto pode ser executada sem uma aprovação válida, não expirada e vinculada a parâmetros. Essa frase vale a pena lembrar. “OK para continuar” é uma aprovação fraca que pode ser concedida por outro agente ou ator malicioso. “Transferir este valor para esta conta” ou “implantar esta mudança neste ambiente” são algo que o sistema pode realmente verificar no momento da execução, e que o usuário compreende totalmente.

A garantia de identidade humana ao vivo importa neste ponto de controle. Uma notificação push prova apenas que alguém ou algo clicou em um botão. Projetos mais robustos exigem que uma pessoa cadastrada use autenticação de chave pública resistente a phishing, respaldada por um método biométrico local.Os padrões FIDO vinculam credenciais de chave pública ao serviço online legítimo e mantêm os dados biométricos no dispositivo isolado do usuário. Quando bem usado, a autenticação suportada por hardware fornece evidência muito melhor de que a pessoa correta estava realmente presente. Ela não substitui a vinculação da transação, uma exibição confiável ou a aplicação de políticas, porém. É preciso que todos esses elementos funcionem em conjunto.

Monitore o Comportamento e Preserve Evidências

Não se pode contar apenas com o prompt inicial para explicar o que ocorreu ao longo de uma execução prolongada do agente. As equipes de segurança precisam de telemetria sobre chamadas de ferramentas, atividade de rede, uso de credenciais, decisões de política, aprovações, recusas e mudanças de escopo. O monitoramento deve comparar o que o agente realmente fez com o limite declarado para aquela execução. Se um agente foi designado para analisar código e começa a buscar credenciais externas ou sondar um serviço não relacionado, isso deve disparar um alerta.

Os registros precisam de contexto suficiente para reconstruir a cadeia de ações sem expor segredos em texto plano. Cada entrada deve capturar a versão do agente, seu proprietário, a pessoa ou sistema que iniciou a operação, a ferramenta usada, a ação solicitada, o resultado da política e qualquer autorização humana. Registros assinados ou de outra forma resistentes a adulteração tornam a revisão pós‑ação muito mais credível, especialmente quando vários agentes e serviços estiveram envolvidos.

Todo esse processo tem que rodar na velocidade da máquina. Ninguém monitorando um painel vai interromper milhares de chamadas que terminam em segundos. Controles automatizados devem impor limites de taxa, detectar sequências incomuns e suspender credenciais no instante em que o comportamento ultrapassa um limiar definido. Assim, os investigadores humanos recebem um incidente contido para analisar, em vez de uma perseguição sem fim.

Projete o Caminho de Interrupção Antes do Lançamento

Todo deployment de agente precisa de um meio de interrompê‑lo que realmente remova a capacidade. Pedir ao agente que pare não conta. Os operadores devem poder revogar suas credenciais, cortar seu caminho de rede, encerrar seu runtime e impedir que ações enfileiradas sejam reiniciadas. Para fluxos de trabalho de alta consequência, se o serviço de aprovação ou política falhar, o sistema deve falhar em modo fechado.

Então teste esse caminho sob pressão. Desative o serviço de aprovação. Dê ao agente instruções conflitantes. Gire uma credencial no meio de uma execução. Simule uma ferramenta comprometida e um aprovador que nunca responde. Confirme que a ação é bloqueada e que você fica com um registro útil. E refaça esses testes sempre que o modelo, o prompt, o conector, o sistema de memória ou o conjunto de permissões mudar.

O Objetivo é Autonomia Responsável

Nada disso é um argumento contra agentes, e o incidente da Hugging Face não deveria assustar ninguém em relação aos úteis. O que deveria fazer é eliminar a ideia de que um prompt de segurança mais boas intenções resultam em uma implantação confiável. Dê aos agentes espaço para analisar, preparar o trabalho e lidar com tarefas reversíveis. Mantenha sua autoridade para causar consequências reais estreita, visível e imposta por algo que não seja o próprio agente.

Antes de um agente entrar em produção, os líderes devem ser capazes de responder a um conjunto de perguntas simples. Que sistemas ele pode alcançar? Que credenciais ele pode usar? O que ele pode fazer sem revisão? O que desencadeia a escalada? Como o aprovador vê a ação exata que está sendo aprovada? Que evidências ficarão registradas? E como a segurança pode interromper a execução imediatamente?

Se as respostas forem vagas, o agente tem mais autoridade do que a organização percebe. A arquitetura que se mantém ao longo do tempo combina salvaguardas de modelo com identidade, privilégio mínimo, aplicação externa de políticas, aprovação humana seletiva, telemetria completa e um mecanismo de parada que realmente funciona. Parte de uma suposição honesta: agentes capazes vão nos surpreender de vez em quando. Nossas fronteiras de segurança não deveriam.

No final, pense em um agente de IA como um estagiário com acesso (potencialmente) root que não tem medo do RH.

Quais proteções e barreiras eles teriam?

Proceda de acordo.