Em resumo: o Google ampliou o Secure AI Framework para tratar dos riscos de agentes capazes de consultar dados, escolher ferramentas e executar ações. O SAIF 2.0 organiza o problema em componentes, riscos e controles, com ênfase em controlador humano definido, permissões limitadas e observabilidade. A atualização ajuda equipes a formular perguntas melhores, mas não certifica um produto, não elimina prompt injection e não comprova que um agente é seguro. Um mapa de risco só produz proteção quando vira arquitetura, teste, registro e decisão operacional.
O que aconteceu
O Google apresentou o Secure AI Framework 2.0, ou SAIF 2.0, como uma extensão de seu modelo de segurança para sistemas com agentes. A mudança acrescentou um mapa específico para componentes e riscos agentivos, controles voltados a identidade, autorização, supervisão e registro, além de uma autoavaliação para equipes que precisam identificar lacunas antes de colocar ações autônomas em produção.
O anúncio reuniu outras iniciativas de segurança, como um programa dedicado de recompensa por vulnerabilidades em IA e o agente CodeMender. Esta matéria, porém, separa esses produtos do ponto central: SAIF 2.0 é uma estrutura de orientação. Ele descreve como pensar sobre o risco, mas não atesta que uma implementação concreta aplicou os controles corretamente.
Quando isso aconteceu
O anúncio do SAIF 2.0 foi publicado em 6 de outubro de 2025. A primeira versão do Secure AI Framework havia sido apresentada em 8 de junho de 2023, quando o Google organizou seis elementos para proteger sistemas de IA, incluindo fundações seguras, detecção e resposta, automação de defesas, harmonização de controles, adaptação contínua e contextualização do risco no processo de negócio.
As páginas atuais do SAIF evoluíram depois do anúncio original. Hoje o material reúne mapa de riscos, componentes de dados, infraestrutura, modelo e aplicação, controles e um foco específico em agentes. Por isso, a data histórica precisa ser preservada sem congelar a documentação. A notícia é de 2025, enquanto a orientação pública continua sendo atualizada.
Por que isso ainda importa
Um chatbot que somente responde texto já pode revelar dados ou produzir conteúdo inseguro. Um agente amplia o problema porque recebe memória, ferramentas, credenciais e permissão para mudar sistemas. A mesma resposta errada que antes terminava em uma tela pode virar um e-mail enviado, um arquivo compartilhado, um registro apagado ou uma alteração aplicada ao ambiente.
O valor duradouro do SAIF 2.0 está em deslocar a conversa da inteligência aparente do modelo para o caminho completo da ação. Essa perspectiva complementa o cuidado prático de validar um patch de IA antes de aplicá-lo: o modelo pode propor, mas identidade, permissão, revisão e evidência ainda precisam limitar o que chega ao mundo real.
Do SAIF original à versão 2.0
O SAIF de 2023 adaptou práticas conhecidas de segurança de software, como proteção da cadeia de suprimentos, inventário, controle de acesso, monitoramento e resposta a incidentes, para riscos associados a modelos e dados. O documento já mencionava roubo de modelo, envenenamento de dados, prompt injection e extração de informação confidencial.
A versão 2.0 não descarta essa base. Ela acrescenta uma visão própria para agentes, pois o risco deixa de estar somente no modelo. Entram no escopo a aplicação que coleta contexto, o núcleo que planeja, a memória, as ferramentas, o conteúdo recuperado, modelos auxiliares e a etapa que renderiza a resposta. Cada ligação pode introduzir confiança indevida.
Três princípios para agentes
No anúncio, o Google resume sua orientação em três princípios: agentes devem ter controladores humanos bem definidos, seus poderes precisam ser cuidadosamente limitados e suas ações e planos devem ser observáveis. Os três funcionam juntos. Controle humano sem informação vira aprovação cega. Observabilidade sem limite de permissão apenas documenta um dano maior. Permissão mínima sem responsável definido pode deixar alertas sem decisão.
Esses princípios são direção de projeto, não uma configuração universal. Um agente que agenda reunião, outro que movimenta dinheiro e outro que corrige código exigem identidades, confirmações, logs e testes diferentes. A equipe precisa transformar cada princípio em requisitos verificáveis para sua tarefa, seus dados e o impacto máximo aceitável.
Controlador humano não é aprovação decorativa
Definir um controlador significa dizer quem pode iniciar, interromper, autorizar e revisar a ação do agente. Também significa impedir que dados externos assumam esse papel. Um documento recuperado, uma página aberta ou uma mensagem recebida pode conter texto que parece ordem, mas não deve competir com a instrução do usuário autorizado.
A aprovação humana só protege quando a pessoa vê informação suficiente para decidir. Botões genéricos de confirmar não ajudam se escondem destinatário, recurso afetado, dados transmitidos ou possibilidade de reversão. A interface precisa mostrar a ação exata, a identidade usada, o destino e a consequência. Para operações críticas, a autorização deve ocorrer perto do momento de execução.
Poderes limitados começam pela identidade
Um agente não deveria herdar automaticamente toda a sessão, todas as credenciais ou todos os privilégios de uma pessoa. O material do SAIF recomenda identidade própria e credenciais com escopo ajustado ao que a tarefa realmente requer. Assim, mesmo que o raciocínio seja manipulado, o sistema encontra uma barreira determinística fora do modelo.
O limite precisa existir em mais de uma dimensão: quais ferramentas podem ser chamadas, quais recursos podem ser lidos, quais mudanças podem ser feitas, durante quanto tempo e para qual finalidade. Uma credencial temporária, restrita a uma pasta e sem permissão de exclusão, reduz o raio de impacto melhor do que uma frase pedindo ao modelo que tenha cuidado.
Observabilidade precisa registrar ação útil
O SAIF inclui observabilidade do agente como controle. Na prática, o registro deve permitir reconstruir o que aconteceu sem depender da memória do usuário ou de um resumo produzido pelo próprio modelo. Isso pede horário, identidade, ferramenta, parâmetros relevantes, recurso atingido, resultado, decisão humana e política aplicada.
Registrar tudo sem critério cria outro risco. Prompts, respostas e saídas de ferramentas podem conter dados pessoais, segredos e documentos internos. Logs precisam de minimização, controle de acesso, prazo de retenção e proteção contra alteração. A trilha de auditoria deve servir à investigação sem virar um novo repositório de informações sensíveis.
O mapa separa percepção, raciocínio e orquestração
O mapa de agentes divide o fluxo em componentes. A aplicação recebe instruções explícitas e contexto passivo. A camada de percepção prepara essas entradas. O núcleo de raciocínio cria um plano. A orquestração conecta memória, ferramentas, conteúdo recuperado e modelos auxiliares. Por fim, a resposta é renderizada para uma pessoa ou outro sistema.
Essa separação evita atribuir tudo ao modelo. Uma falha pode nascer antes do raciocínio, quando um conteúdo não confiável é tratado como comando. Pode surgir depois, quando uma ferramenta aceita parâmetros excessivos. Também pode aparecer na interface, se uma saída dinâmica for renderizada como código ativo. Corrigir somente o prompt deixa essas fronteiras intactas.
Memória amplia persistência do ataque
A memória permite continuidade, mas também pode transformar uma entrada maliciosa em influência duradoura. Se um agente armazena como fato uma instrução escondida em documento ou conversa, tarefas futuras podem ser desviadas mesmo depois que a fonte original desaparece. Isolamento entre usuários e proveniência do dado passam a ser requisitos de segurança.
Uma arquitetura prudente distingue memória de preferência, histórico operacional, conhecimento recuperado e segredo. Cada classe deve ter regra de escrita, leitura, revisão e expiração. O sistema também precisa permitir que a pessoa veja e remova itens persistidos. Memória opaca aumenta conveniência no curto prazo, mas dificulta explicar por que o agente agiu.
Ferramentas aumentam o raio de impacto
Ferramentas convertem texto em capacidade. Uma API pode ler uma caixa postal, publicar conteúdo, iniciar pagamento ou alterar infraestrutura. Descrições enganosas, parâmetros ambíguos e respostas manipuladas podem induzir o agente a escolher um caminho que parece correto. O SAIF trata esse ponto como parte da orquestração, não como detalhe de integração.
Controles úteis incluem lista explícita de ferramentas, esquemas rígidos, validação de parâmetros, políticas fora do modelo e confirmação para ações irreversíveis. Uma ferramenta deve rejeitar o que excede seu contrato mesmo quando o modelo insiste. Quanto maior a consequência, menor deve ser a liberdade de construir comandos ou destinos arbitrários.
RAG também pode carregar instrução maliciosa
Conteúdo recuperado por busca ou RAG ajuda a fundamentar respostas, mas continua sendo dado. Página, PDF, ticket ou mensagem podem conter instruções destinadas a capturar o agente. A camada de percepção precisa preservar a distinção entre a pergunta autorizada e o material consultado, inclusive quando ambos chegam em linguagem natural.
Não existe filtro perfeito para prompt injection indireta. Por isso, a defesa precisa combinar separação de contexto, origem identificada, redução de privilégios, bloqueio de saídas perigosas e confirmação humana. Mesmo que uma instrução maliciosa atravesse o modelo, ela não deveria conseguir escolher livremente uma credencial, um destinatário e uma ação com alto impacto.
Renderização é fronteira de segurança
O fim do fluxo também merece controle. Agentes frequentemente produzem Markdown, HTML, links, arquivos ou comandos. Se a aplicação renderiza esse material sem sanitização, uma saída manipulada pode executar conteúdo ativo, exfiltrar dados por URL ou enganar a pessoa com uma interface que parece confiável.
A defesa depende do tipo de saída. Texto pode exigir escape. Links podem precisar de validação e indicação do domínio. Arquivos devem passar por verificação. Comandos precisam aparecer como proposta, não como execução automática. O componente que exibe a resposta não deve pressupor que o modelo entregou conteúdo seguro apenas porque a solicitação inicial era legítima.
Ações indevidas e vazamento de dados
O material para agentes destaca duas famílias de risco. A primeira é a ação indevida, quando o sistema executa algo desalinhado da intenção do usuário por erro, ambiguidade ou manipulação. A segunda é a exposição de dados sensíveis, que cresce quando o agente acessa e-mails, arquivos, código, histórico ou credenciais.
As categorias se cruzam. Um agente pode compartilhar um documento com o destinatário errado e produzir ao mesmo tempo uma ação indevida e um vazamento. Por isso, o controle não deve procurar apenas conteúdo proibido na resposta. Ele precisa avaliar contexto, identidade, destino, ferramenta, dados envolvidos e possibilidade de desfazer a operação.
O papel da confirmação humana
A autoavaliação do SAIF pergunta se há mecanismos de pessoa no circuito ou supervisão sobre o circuito para ações que envolvem sistemas críticos e dados sensíveis. Essa distinção é útil. Algumas tarefas exigem autorização antes de cada mudança. Outras podem operar dentro de limites estreitos e parar quando um alerta ou exceção aparece.
Supervisão não transfere responsabilidade para o usuário. A aplicação deve escolher pontos de parada proporcionais ao risco, apresentar evidência clara e tornar simples negar ou revisar. Se o agente gera dezenas de confirmações triviais, a pessoa aprende a clicar sem ler. O desenho precisa reservar atenção humana para decisões relevantes.
O questionário não é certificação
O Google descreve a autoavaliação como recurso informativo para iniciar conversas e orientar pesquisa adicional. A própria página afirma que ela não substitui aconselhamento profissional. As perguntas cobrem identidade, autorização, observabilidade, controle do usuário, segurança do modelo, guardrails nas ferramentas, filtragem de entrada e saída e testes.
Responder sim não demonstra eficácia. Uma organização pode ter logs que não permitem investigação, um processo de aprovação que mostra pouco contexto ou testes que cobrem somente ataques diretos. O valor da ferramenta está em revelar assuntos que precisam de evidência. Usá-la como selo público seria ir além do que a fonte afirma.
Controles determinísticos ainda importam
Modelos são probabilísticos e podem interpretar de maneira diferente entradas parecidas. Limites de acesso, validação de esquema, política de rede, separação de função e transação atômica não dependem da boa vontade do modelo. Eles restringem o espaço de erro mesmo quando o raciocínio falha.
Isso não elimina a utilidade de classificadores e modelos críticos. Eles podem detectar padrões difíceis e aumentar cobertura. Porém, devem complementar barreiras verificáveis. Para mudanças relevantes, a pergunta não é apenas se o agente acredita que a ação é segura. É se o sistema permite somente ações autorizadas, dentro de escopo e com evidência suficiente.
Testes precisam cobrir prompt injection indireta
A autoavaliação pergunta se o agente foi testado contra prompt injection. Um programa real precisa ir além de frases óbvias na caixa de conversa. Deve incluir instruções escondidas em páginas, documentos, mensagens, nomes de arquivo, metadados e respostas de ferramentas. Também precisa avaliar cadeias longas, nas quais a consequência só aparece depois de várias etapas.
O teste deve observar prevenção, detecção e recuperação. É importante saber se o agente recusou a instrução, se a ferramenta bloqueou o parâmetro, se o alerta chegou à equipe e se dados ou estado podem ser restaurados. Resultado favorável em uma bateria não garante segurança futura, mas cria uma linha de base que pode ser repetida após mudanças.
O que uma equipe pode aplicar agora
O primeiro passo é inventariar agentes, proprietários, modelos, ferramentas, dados e credenciais. Depois, classificar ações por consequência e reversibilidade. Operações de leitura limitada podem ter fluxo diferente de envio externo, exclusão, publicação ou alteração financeira. Cada classe precisa de política, identidade, log, teste e ponto de interrupção claros.
Em seguida, a equipe pode ensaiar cenários de abuso e erro, confirmar que nenhuma ferramenta aceita mais do que deveria e revisar o que aparece para a pessoa antes da execução. O registro deve permitir comparar plano e ação final. Para artefatos técnicos gerados por IA, vale manter a disciplina de revisão descrita no guia sobre compartilhar estrutura sem expor segredos.
O que SAIF 2.0 não comprova
O framework não prova que produtos do Google ou de terceiros implementam todos os controles. A própria documentação pública avisa que o conteúdo serve para informação e avanço do setor, não como descrição das implementações técnicas atuais do Google. Também não oferece garantia de ausência de vulnerabilidade ou conformidade automática com norma.
Ele tampouco resolve escolhas de risco específicas de setor. Saúde, finanças, infraestrutura e administração pública podem exigir segregação, retenção, auditoria e autorização adicionais. SAIF 2.0 funciona melhor como linguagem comum e roteiro de investigação. A validação continua dependente de arquitetura concreta, testes independentes e resposta a incidentes.
Fato confirmado e análise editorial
Fato confirmado: em 6 de outubro de 2025, o Google anunciou o SAIF 2.0 com orientação adicional para agentes, um mapa de risco específico e controles ligados a permissão, supervisão e observabilidade. As páginas oficiais descrevem componentes agentivos, ações indevidas, exposição de dados e uma autoavaliação informativa.
Análise editorial: a principal contribuição é retirar segurança de agentes do campo de uma instrução genérica e distribuí-la por identidades, ferramentas, memória, conteúdo, renderização e decisão humana. O limite é igualmente importante: uma taxonomia organizada não mede, sozinha, se os controles resistem a ataques no produto real.
Fontes primárias
- Google: How we’re securing the AI frontier, anúncio publicado em 6 de outubro de 2025.
- Google SAIF: Secure AI Framework e mapa de riscos, documentação pública consultada em 18 de setembro de 2026.
- Google SAIF: Focus on Agents, componentes, riscos e controles para agentes.
- Google SAIF: Agent Risk Self Assessment, questionário e limitações de uso.
- Google SAIF: controles de segurança para sistemas de IA.