Construir um agente de inteligência artificial ficou relativamente fácil. O problema começa quando esse agente deixa de responder perguntas e passa a acessar banco de dados, chamar APIs internas ou executar código. Nesse momento, um prompt bem escrito ajuda, mas não pode ser a última linha de defesa.
O exemplo que tira a conversa do laboratório
Em um artigo publicado pelo Google, o cenário é um agente de atendimento capaz de calcular reembolsos, gravar o resultado no banco e entregar um recibo. Parece um fluxo útil e direto, mas cada etapa abre uma porta diferente: o modelo precisa entender a solicitação, decidir um valor, chamar uma ferramenta, alterar um dado e devolver uma confirmação.
Se alguém conseguir induzir o agente a pagar muito mais do que deveria, expor uma variável de ambiente ou executar uma ação fora do escopo, não estamos diante de uma resposta ruim de chatbot. Estamos diante de uma alteração real em um sistema. É essa mudança de contexto que torna a segurança de agentes diferente da segurança de uma conversa comum.
O que significa zero trust nesse cenário
Zero trust pode ser resumido como uma regra simples: não presuma que nada é confiável apenas porque está dentro da sua aplicação. O modelo não é confiável por padrão. A sessão não é confiável por padrão. A ferramenta não é confiável por padrão. Cada chamada precisa ter identidade, permissão, limite e registro.
Isso não significa impedir toda autonomia. Significa dividir a autonomia em passos controláveis. Um agente pode interpretar um pedido, mas outra camada deve validar o valor. Ele pode preparar uma alteração, mas a gravação pode exigir autorização. Ele pode executar um script, mas em um ambiente isolado, sem acesso livre à rede ou ao sistema de arquivos.
Quatro camadas para proteger um agente
1. Identidade para cada ação
O Google descreve o uso de identidade criptográfica para ligar uma ação ao agente ou serviço que a executou. A ideia é não depender apenas de uma mensagem dizendo “foi o agente de atendimento”. A operação importante precisa carregar uma prova verificável de quem a solicitou e em qual contexto.
O artigo relaciona esse padrão a chaves assimétricas no Cloud KMS, protegidas por HSM. Em um ambiente de demonstração, uma chave HMAC pode reproduzir parte da ideia localmente. Para quem está começando, a lição é mais importante que o produto específico: registre a origem de ações sensíveis e não permita que qualquer componente escreva no banco sem identificação.
2. Sandbox para código gerado
Código produzido por um modelo deve ser tratado como código potencialmente hostil, mesmo quando parece correto. Ele pode conter um erro, entrar em loop, tentar acessar um arquivo indevido ou usar a rede de maneira que o desenvolvedor não previu.
No exemplo apresentado, o isolamento usa gVisor, rede desativada, capacidades removidas, limites de memória e CPU, montagem somente leitura e tempo máximo de execução. Cada medida reduz o raio de explosão: se o código falhar, ele não deveria conseguir levar a falha para todo o servidor.
3. Validação determinística
O modelo pode interpretar linguagem, mas regras críticas precisam ser verificáveis por código. Um gateway determinístico pode bloquear segredos, sinais de jailbreak, valores acima do limite e transações incompatíveis antes que a chamada alcance o banco ou uma API externa.
Isso é diferente de pedir ao próprio modelo para “ter cuidado”. Uma instrução pode ser ignorada, interpretada de outra maneira ou entrar em conflito com informações posteriores. Uma regra de autorização escrita no software precisa ser testável, registrada e aplicada da mesma forma em todas as execuções.
4. Observabilidade e interrupção
Um sistema autônomo precisa deixar rastros suficientes para responder perguntas depois: qual agente chamou a ferramenta, com qual entrada, qual validação foi aplicada, qual saída foi produzida e quem aprovou a ação. Também precisa existir uma forma clara de interromper a execução.
Sem logs úteis, a equipe descobre o problema apenas pelo efeito final. Sem rollback, uma automação que erra pode transformar um incidente pequeno em uma recuperação longa. Segurança de agentes inclui o botão de parar e o caminho para desfazer.
Como imaginar a arquitetura de um primeiro projeto
Para um projeto pequeno, não é preciso começar construindo uma plataforma enorme. Pense em cinco componentes:
- entrada: recebe o pedido e identifica o usuário;
- agente: interpreta a intenção e propõe o próximo passo;
- gateway: valida permissões, formato, valores e dados sensíveis;
- ferramenta: executa uma operação com escopo limitado;
- registro: salva o que aconteceu e permite revisão.
O agente não deveria conversar diretamente com o banco de produção só porque o modelo sabe gerar SQL. Entre a intenção e a alteração deve existir uma camada que conheça as regras do negócio. Para uma ação sensível, o resultado pode ser um pedido de aprovação em vez de uma gravação imediata.
Checklist para quem está começando
Antes de dar ferramentas a um agente, faça perguntas práticas:
- quais dados o agente consegue ler?
- quais sistemas ele consegue alterar?
- qual é o menor conjunto de permissões necessário?
- o que acontece se o modelo interpretar o pedido errado?
- como a equipe percebe uma falha?
- como interromper uma execução presa?
- existe rollback para a ação mais perigosa?
- os testes cobrem tentativas de injeção de prompt e dados inesperados?
Essas perguntas parecem menos impressionantes que uma demonstração de agente conversando com cinco ferramentas, mas são as que determinam se o protótipo pode virar produto.
Onde o prompt entra — e onde ele não entra
O prompt continua importante. Ele define objetivo, formato, contexto e limites que ajudam o modelo a trabalhar. O que muda é a posição dele na arquitetura. O prompt orienta; não autoriza sozinho. O modelo sugere; não deve ganhar automaticamente a chave da sala inteira.
Para quem aprende programação, essa distinção ajuda a organizar o pensamento: linguagem natural é uma entrada, não uma política de segurança. Para quem já desenvolve, ela reforça uma prática conhecida em sistemas críticos: validação, menor privilégio, isolamento, logs e testes continuam necessários mesmo quando uma IA participa do fluxo.
Papo reto: autonomia sem controle é só velocidade para errar
A proposta do Google é interessante porque tira a segurança de agentes do campo das recomendações abstratas. Um agente que calcula reembolso, grava informação e entrega recibo precisa ser tratado como um componente de software com acesso real, não como uma conversa simpática.
O ponto que mais importa é este: não existe um único botão de “segurança” para instalar depois. A proteção precisa aparecer na identidade, na permissão, no ambiente de execução, na validação e na capacidade de desfazer. Quanto mais autonomia o sistema ganha, mais importante fica saber exatamente onde ele pode parar.
O Agent Development Kit pode acelerar o protótipo, mas não elimina arquitetura. O trabalho difícil começa quando o agente deixa o exemplo e passa a tocar dados, dinheiro, código ou decisões de outras pessoas.
Fonte: Google for Developers — Build zero-trust AI agents with Google Agent Development Kit.
