Como proteger uma IA agêntica: um mapa prático baseado no SAIF do Google

Por anos, o risco de segurança de um assistente de IA cabia em uma pergunta simples: o que ele pode dizer? Um chatbot tradicional só devolve texto, e o pior cenário costumava ser uma resposta errada, enviesada ou vazada. Com a chegada dos agentes, a pergunta muda de natureza, porque o agente age. Chama APIs, escreve em bases de conhecimento, dispara fluxos, lê dados sensíveis e aciona outros sistemas. O risco deixa de ser o que ele diz e passa a ser o que ele executa.

É exatamente essa virada que o Secure AI Framework (SAIF) do Google ajuda a organizar. O SAIF é um framework conceitual aberto para proteger sistemas de IA de ponta a ponta: dos dados ao modelo, da infraestrutura à aplicação. Sua versão mais recente, o SAIF 2.0, dá um passo explícito em direção ao novo terreno: a segurança de agentes de IA. Este artigo é uma síntese prática desse material, traduzida para quem precisa colocar agentes em produção com responsabilidade.

Ações indevidas (Rogue Actions) são ações não pretendidas executadas por um agente baseado em modelo, sejam elas acidentais ou maliciosas.Google · Secure AI Framework (SAIF)

Por que um agente é diferente de um chatbot

A diferença é simples de enunciar e profunda nas consequências: um chatbot prevê texto; um agente toma ações no mundo. Essa capacidade de agir transforma a superfície de ataque. O SAIF nomeia esse risco específico de agentes como Rogue Actions (RA), ações indevidas executadas pelo agente, acidentais ou maliciosas. Agora está em jogo uma transação enviada, um registro apagado, um e-mail disparado, um acesso concedido.

O efeito colateral é que riscos clássicos da IA, antes contornáveis, ganham um gume muito mais afiado quando há um agente capaz de executar:

• Injeção de prompt (Prompt Injection, PIJ): antes podia, no máximo, forçar uma resposta indesejada. Com um agente, uma instrução escondida em um documento ou página pode sequestrar ações reais: fazer o agente chamar a ferramenta errada com os argumentos do atacante.
• Saída de modelo insegura (Insecure Model Output): a saída do modelo deixa de ser só texto na tela e passa a alimentar sistemas que a executam (uma consulta, um comando, uma chamada de função). Conteúdo não validado vira ação.
• Divulgação de dados sensíveis (Sensitive Data Disclosure): agora inclui dados vazados por meio da consulta ao próprio modelo ou agente, extraídos via perguntas habilidosas, não apenas por uma falha de acesso convencional.

O mapa do SAIF: quatro áreas

O SAIF organiza o sistema de IA em quatro áreas que precisam ser protegidas em conjunto. Uma cadeia só é tão forte quanto seu elo mais fraco. Pensar em cada uma evita o erro comum de blindar o modelo e esquecer tudo ao redor dele.

• Dados (Data): as fontes que alimentam e treinam o sistema, sua proveniência e seu tratamento.
• Infraestrutura (Infrastructure): a plataforma de treino, serviço e armazenamento sobre a qual o sistema roda.
• Modelo (Model): o próprio modelo, seu uso, suas entradas e saídas.
• Aplicação (Application): a camada que expõe o sistema, incluindo, no SAIF 2.0, o agente em si.

A espinha dorsal: os três controles de agente

Se há uma ideia para levar deste artigo, é esta: autonomia segura é autonomia limitada. O SAIF 2.0 condensa isso em três controles que, juntos, cercam cada ação consequente de um agente. Eles são complementares: nenhum sozinho basta.

1. Controle do usuário sobre o agente (Agent User Control)

O princípio é o humano no circuito (human-in-the-loop): garantir aprovação do usuário para qualquer ação executada por agentes ou plugins que altere dados do usuário ou aja em seu nome. Em vez de o agente escrever direto, ele propõe, e a pessoa confirma. Ações de baixo risco podem fluir; ações consequentes passam por um portão explícito de aprovação.

2. Permissões do agente (Agent Permissions)

Aqui vale o princípio do menor privilégio, mas com uma nuance agêntica: o acesso a ferramentas deve ser contextual e dinâmico. O agente só deve enxergar as ferramentas e os dados estritamente necessários para a tarefa do momento, e não um conjunto fixo e amplo de poderes “por garantia”. Quanto menor o raio de ação concedido, menor o estrago possível de uma ação indevida.

3. Observabilidade do agente (Agent Observability)

De nada adianta limitar se ninguém consegue ver o que aconteceu. As ações do agente, seu uso de ferramentas e seu raciocínio precisam ser transparentes e auditáveis por meio de registro (logging). Observabilidade é o que transforma um incidente em uma investigação possível, e o que permite distinguir um erro honesto de um ataque.

Governança: o que sustenta os controles

Controles técnicos só se sustentam dentro de governança. O SAIF aponta a Governança de Risco (inventariar, medir e monitorar o risco residual, ou seja, aquilo que sobra depois das mitigações) e a Governança de Produto, que insere decisões de segurança no ciclo de vida. No nível das bordas, validação e sanitização de entradas e saídas seguem sendo a higiene básica: nada que entra ou sai do agente deve ser tratado como confiável por padrão.

Onde a Charla se encaixa

A Charla não reivindica nenhuma certificação aqui: o que descrevemos é alinhamento de engenharia com um framework do setor. Ainda assim, vale mapear mecanismos reais da plataforma aos três controles de agente do SAIF, porque a arquitetura foi pensada na mesma direção: autonomia com freios.

• Controle do usuário → A Charla adota uma postura de propor-e-aprovar: mudanças em conhecimento, wiki ou identidade visual entram como propostas revisáveis, nunca como escritas silenciosas; a aprovação humana funciona como portão da recuperação de informação.
• Permissões → Isolamento por assistente (cada Charla tem sua própria base de conhecimento e lista de acesso, com a recuperação filtrada por assistente antes da ordenação), RBAC hierárquico com permissões escopadas, allowlists de ferramentas com negação por padrão, credenciais MCP seladas (AES-256-GCM sob uma chave do Secret Manager) e proteção de egresso que bloqueia requisições a redes internas (proteção contra SSRF).
• Observabilidade → Um log de auditoria somente-acréscimo (o papel de banco de dados não pode fazer UPDATE nem DELETE nele) que registra cada ação privilegiada e cada chamada de ferramenta, somado a logs, traces e métricas estruturados e correlacionados por id de requisição. O streaming nunca expõe a cadeia de raciocínio bruta.

Esse desenho não é exaustivo nem um selo de conformidade: é uma escolha consciente de arquitetura. Cada uma dessas peças existe para que uma ação consequente do agente só aconteça dentro de limites: com permissão, com o devido aval humano e deixando um rastro auditável.

Proteger uma IA agêntica, no fim, é dar a ela uma autonomia limitada. Toda ação que importa passa por três perguntas: ela tem permissão? Foi aprovada por quem deve aprovar? Ficou registrada? O SAIF dá o vocabulário; a engenharia dá os freios. E é nesse encontro entre framework e prática que um agente deixa de ser um risco e passa a ser uma ferramenta confiável.