Pesquisadores do Google e mais de 50 colaboradores acadêmicos e da indústria publicaram, em 5 de outubro de 2026, um relatório que organiza os problemas ainda em aberto de privacidade e segurança para agentes de IA. A tese central é simples, mas muda a forma de projetar esses sistemas: permissões estáticas e confirmações pontuais não bastam quando um agente interpreta linguagem natural, usa ferramentas e toma ações em contextos distintos. O relatório propõe usar a ideia de integridade contextual para que ações sejam avaliadas conforme a situação, as pessoas envolvidas e as expectativas sociais.
O documento não anuncia um produto nem apresenta uma solução pronta. Seu valor está em transformar riscos conhecidos — como injeção de prompt, delegação excessiva e vazamento de dados — em uma agenda de engenharia, avaliação e governança. Para empresas brasileiras que já testam agentes com acesso a e-mail, sistemas internos ou fluxos financeiros, a pergunta prática deixa de ser apenas “o modelo responde bem?” e passa a ser “ele sabe quando não deve agir?”.
O que o relatório do Google propõe
O texto, publicado pelo Google Research, nasce do workshop Google Contextual Agent Privacy and Security (CAPS), realizado em Nova York no fim de 2025. Entre os autores há pesquisadores do Google e especialistas de universidades e outras organizações. O ponto de partida é a teoria da integridade contextual, associada à pesquisadora Helen Nissenbaum: privacidade não é simplesmente esconder dados; é permitir que uma informação circule de modo apropriado ao contexto.
Aplicada a agentes, essa ideia exige que um mesmo dado ou uma mesma ação receba tratamento diferente conforme o cenário. Um assistente que lê uma agenda para sugerir horários pode precisar acessar compromissos; isso não implica que deva enviar detalhes dessas reuniões a um fornecedor, usar o conteúdo para redigir uma mensagem externa ou reaproveitá-lo em uma tarefa delegada. A autorização útil não é apenas “acesso à agenda: sim ou não”, mas uma regra que relaciona finalidade, destinatário, escopo, duração e consequência da ação.

Por que agentes ampliam riscos que já existiam nos chatbots
Um chatbot convencional normalmente recebe uma pergunta e devolve texto. Um agente combina um modelo de linguagem com memória, ferramentas, permissões e um ciclo de planejamento: ele pode buscar documentos, chamar uma API, criar arquivos, alterar registros ou repassar uma subtarefa. Essa combinação aumenta sua utilidade, mas também altera a superfície de ataque.
O relatório separa três dificuldades. A primeira é a ambiguidade de interfaces não estruturadas. Texto, imagens e páginas da web podem carregar instruções maliciosas ou conflitantes; por isso, filtros tradicionais que esperam comandos rigidamente definidos não resolvem por completo ataques como injeção de prompt. A segunda é o fluxo de controle probabilístico: o plano do modelo não é uma sequência fixa de código, então cobrir todos os caminhos com testes convencionais é difícil. A terceira é a autonomia com delegação. À medida que uma tarefa fica mais longa e passa por subagentes, a pessoa responsável perde visibilidade e pode cair na chamada fadiga de confirmações.
Não se trata de concluir que agentes sejam inevitavelmente inseguros. Trata-se de reconhecer que a segurança precisa acompanhar a capacidade de agir. Um pedido de confirmação para cada passo reduz o risco de uma ação isolada, mas pode levar o usuário a aprovar avisos sem analisá-los; já uma aprovação ampla demais deixa o agente livre para executar consequências que o usuário não previu.
Integridade contextual: políticas que entendem finalidade e consequência
A proposta dos autores é deslocar parte do controle para políticas dinâmicas e contextualizadas. Em vez de uma lista fixa de permissões, o sistema deveria avaliar a ação proposta contra expectativas comportamentais: quem iniciou a tarefa, qual informação está sendo usada, para qual finalidade, quem receberá o resultado e qual é o impacto da decisão.

Na prática, isso sugere uma arquitetura em que o agente não chama uma ferramenta externa diretamente. Antes, uma camada de política recebe a ação proposta, a compara com limites técnicos e regras de negócio e decide se permite, pede esclarecimento, reduz o escopo ou bloqueia a operação. Essa camada deve ser auditável: registrar o que foi solicitado, qual contexto foi considerado e por que uma ação foi autorizada ou recusada.
Para operações no Brasil, esse desenho conversa diretamente com princípios da LGPD, como finalidade, necessidade e segurança. O relatório não é uma interpretação jurídica da lei brasileira, mas sua ênfase em limitar o fluxo de dados ao contexto necessário oferece uma referência técnica útil para times que precisam demonstrar controles sobre dados pessoais. Implementar um agente para consultar pedidos, por exemplo, não justifica entregar toda a base de clientes a cada chamada de ferramenta.
O que muda para equipes que estão colocando agentes em produção
O primeiro passo não é escolher um modelo maior; é mapear as ações possíveis. Uma equipe deve inventariar quais ferramentas o agente pode usar, quais dados cada uma expõe, que ações têm efeito irreversível e quem é o responsável humano por cada domínio. Acesso de leitura, criação de rascunho, publicação e pagamento não devem ser tratados como a mesma permissão.
- Separe observar de executar: permita que o agente consulte dados antes de conceder autonomia para enviar, alterar ou apagar algo.
- Use credenciais de menor privilégio: tokens específicos por ferramenta e por ambiente reduzem o alcance de uma falha ou de uma instrução maliciosa.
- Defina limites transacionais: valor, volume, destinatários, horário e ambiente podem ser regras verificáveis antes de uma ação externa.
- Preserve evidências: logs devem registrar contexto, chamada de ferramenta, resultado e intervenção humana, com proteção adequada para não criar outro repositório de dados sensíveis.
- Teste jornadas completas: não basta medir respostas do modelo. Simule documentos hostis, instruções conflitantes, falhas de API, delegação entre agentes e tentativas de burlar aprovações.
Esses controles não eliminam a necessidade de revisão humana. Eles tornam a revisão mais útil: em vez de uma sequência de alertas genéricos, a pessoa recebe uma decisão contextualizada, como “o agente quer compartilhar estes três campos com este fornecedor para concluir esta etapa; a política permite apenas dados de faturamento”.
A avaliação precisa acompanhar tarefas longas e múltiplos agentes
O relatório também pede novas formas de avaliação. Benchmarks de perguntas e respostas não medem bem um agente que trabalha por horas, encontra conteúdo externo, delega tarefas e interage com outros agentes. Os autores sugerem ambientes dinâmicos, semelhantes a um “Agent Gym”, para simular interações em cascata e observar privacidade, segurança e comportamento ao longo do tempo.

Há uma limitação importante: o texto é uma agenda de pesquisa, não uma especificação pronta nem uma prova de que modelos já conseguem compreender normas sociais de maneira confiável. O próprio Google afirma que são necessários avanços em sistemas, modelos, interfaces, avaliação e governança do ecossistema. Organizações não devem transformar a expressão “integridade contextual” em um selo automático de segurança; políticas precisam continuar explícitas, testáveis e sujeitas a auditoria.
Análise do NoticIA: o controle de ferramentas vira o centro do produto
Na análise do NoticIA, a contribuição mais útil do relatório é deslocar o debate da personalidade do assistente para o desenho das fronteiras de execução. Em muitas provas de conceito, o modelo recebe uma chave ampla e uma instrução vaga para “resolver” uma tarefa. Isso pode produzir uma demonstração impressionante, mas também concentra interpretação, planejamento e autorização na parte menos determinística do sistema.
O caminho mais robusto é o oposto: deixar o modelo propor e explicar, mas reservar à infraestrutura determinística a validação de identidade, escopo, limites e efeitos. O avanço de agentes capazes de coordenar tarefas longas torna essa separação mais urgente para empresas, órgãos públicos e produtos que lidam com dados de consumidores. O diferencial não será apenas um agente que consegue fazer mais; será um sistema que consegue provar por que fez exatamente aquilo — e por que se recusou a fazer o restante.
Fontes e leitura complementar
- Google Research — anúncio do relatório e contexto do CAPS Workshop.
- Google Research — página do relatório e lista de autores.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.



