Google ADK e agentes de IA zero trust: segurança antes da automação

Resumo prático

O novo texto do Google Developers sobre o Agent Development Kit é importante porque trata agentes de IA como sistemas de produção, não como simples prompts. A orientação usa o exemplo de um agente de suporte e reembolso para mostrar que ações sensíveis devem ser assinadas, código não confiável precisa rodar em sandbox e entradas e saídas devem passar por políticas testáveis. Para equipes que escolhem ferramentas de IA, a lição é direta: não basta perguntar se o modelo é inteligente; é preciso saber se a plataforma oferece identidade verificável, execução limitada, auditoria e controles que continuam funcionando mesmo quando ocorre prompt injection.

Por que isso importa agora

Agentes de IA estão saindo das demonstrações e entrando em filas de atendimento, painéis internos, IDEs, fluxos financeiros e automações de produto. Quando um assistente apenas escreve um rascunho, uma pessoa pode revisar. Quando um agente aprova reembolso, altera arquivo, chama API privada ou responde com dados de cliente, ele passa a ser um ator de produção. O artigo oficial do Google em https://developers.googleblog.com/build-zero-trust-ai-agents-with-googles-agent-development-kit/ é útil porque transforma segurança de agentes em arquitetura concreta.

Zero trust significa não confiar em uma única barreira. Um prompt de sistema ajuda, mas não impede instruções maliciosas escondidas em tickets, documentos, páginas, nomes de arquivos ou respostas de ferramentas. O modelo pode raciocinar; a plataforma precisa impor limites. Essa separação é essencial quando a automação toca dinheiro, dados, identidade ou código.

Padrões que vale copiar

O primeiro padrão é separar intenção de autoridade. O agente pode decidir que um reembolso parece correto, mas a escrita final deve ser assinada por uma identidade criptográfica e verificada pelo serviço receptor. Assim, a equipe sabe qual agente iniciou a ação, qual fluxo gerou a solicitação e se algo foi alterado no caminho.

O segundo padrão é isolamento. Agentes podem executar trechos de código, transformar arquivos e chamar ferramentas. Isso não justifica permissões amplas no host. Um sandbox reduz o impacto de código gerado de forma errada ou de conteúdo malicioso recebido de terceiros.

O terceiro padrão é uma barreira semântica. Não basta bloquear extensões ou domínios. A política precisa entender se o valor do reembolso excede um limite, se a resposta revela dados privados, se o comando é destrutivo ou se a chamada de ferramenta foge do pedido do usuário. Essas regras devem virar testes de CI, não apenas frases no prompt.

Como avaliar ferramentas de IA

Ao comparar assistentes de programação e automação em https://www.bttc.site/software, inclua evidências de segurança no checklist. Procure identidades de serviço separadas, credenciais com escopo, aprovação humana, execução em sandbox, logs de auditoria, exportação de políticas e documentação clara. Uma demonstração bonita perde valor se todas as chamadas usam o mesmo token pessoal e não deixam trilha confiável.

Equipes pequenas também podem aplicar o princípio. Defina quais repositórios, contas de nuvem, documentos e sistemas financeiros o agente pode acessar. Mantenha ações de alto risco com revisão humana. Guarde logs de decisões e chamadas de ferramentas. Use conteúdos relacionados em https://www.bttc.site/blog para acompanhar a evolução de ferramentas de IA.

Checklist operacional

Liste tudo que o agente pode fazer: ler documentos, buscar código, criar tickets, modificar arquivos, executar comandos, enviar mensagens, aprovar pagamentos ou chamar APIs. Classifique cada ação por reversibilidade e impacto. Ler uma FAQ pública é baixo risco; alterar faturamento, autenticação, configuração de produção ou dados de cliente exige controles fortes.

Depois, atribua identidades estreitas e credenciais temporárias. Não deixe todos os fluxos usarem o token pessoal de um desenvolvedor. Limite rede, arquivos, memória e tempo de execução. Por fim, crie casos de regressão com prompt injection, solicitações de dados sensíveis e comandos destrutivos. O objetivo não é tornar o modelo perfeito, mas fazer o comportamento perigoso falhar de forma segura.

Perguntas frequentes

Um prompt de sistema forte é suficiente?

Não. Ele orienta o modelo, mas não é uma barreira de segurança. Ações sensíveis precisam de credenciais com escopo, assinaturas, sandbox, aprovações e auditoria.

O que copiar da orientação do Google?

Copie a separação entre raciocínio e autoridade operacional. O agente pode propor, mas serviços, sandboxes e políticas devem decidir o que realmente acontece.

Como isso ajuda na escolha de software?

A equipe ganha uma lista objetiva: identidade, logs, limites de permissão, execução segura e testes de política devem pesar tanto quanto qualidade do modelo.

Conclusão

Agentes de IA zero trust não reduzem o valor da automação. Eles tornam a automação segura o bastante para trabalho real. A orientação do Google ADK é valiosa porque transforma segurança em engenharia verificável: assinar escritas, isolar execução, filtrar entradas e saídas e escolher ferramentas que provem seus controles.