Você conectou seu agente de IA a uma dúzia de ferramentas — GitHub, Slack, bancos de dados, APIs na nuvem — e ele termina em minutos o que antes levava horas. Você adicionou servidores MCP (Model Context Protocol — um padrão universal de conexão para ferramentas de IA, tipo USB só que para dados), configurou API tokens (senhas digitais que permitem que programas acessem serviços em seu nome), e tudo simplesmente funcionou. O futuro chegou, produtivo e completamente desprotegido.
Porque quando você fez essas conexões, cada ferramenta pediu acesso total. Não "somente leitura". Não "só esse repositório". Acesso total. E nenhuma plataforma de agentes ofereceu uma forma de limitar permissões na camada de orquestração — o nível onde seu agente decide quais ferramentas usar e quando. Você entregou a chave-mestra e chamou isso de integração.
Entre 1º e 14 de abril de 2026, essa chave-mestra foi copiada. Repetidamente.
Google Entrega a Senha de Root pra Todo Agente e Depois Atualiza o README
Em 1º de abril, a Unit 42 da Palo Alto divulgou a falha "Double Agent" no Google Vertex AI. Esse é o caso mais contundente da lacuna entre autenticação e autorização que eu já vi.
O que aconteceu: todo agente do Vertex AI recebia uma service account padrão (uma identidade de sistema que age em nome do seu agente). Essa service account vinha pré-carregada com permissões que fariam um sysadmin chorar. Não estamos falando de "um pouco ampla demais". Estamos falando de acesso a:
- Buckets de Cloud Storage de outros clientes — dados de terceiros, acessíveis de qualquer instância de agente
- Imagens de containers internos restritos do Google — daquelas que normalmente ficam atrás de múltiplas camadas de aprovação
- Código-fonte do próprio Vertex AI — os repositórios internos da plataforma, legíveis por um agente de demonstração qualquer
Os pesquisadores demonstraram uma cadeia completa de escalação de privilégios: comece com um agente básico, herde a service account padrão, mova-se lateralmente por recursos do Google Cloud que nenhum agente deveria tocar. A identidade padrão não era "levemente privilegiada demais" — era funcionalmente onisciente dentro do limite do projeto e parcialmente onisciente fora dele.
A correção do Google? Documentação atualizada sugerindo que você traga sua própria service account, menos privilegiada. Nenhuma mudança na plataforma. Nenhum padrão seguro. Um patch na documentação. Eles disseram pros clientes lerem o manual com mais atenção. O equivalente a uma montadora responder a uma falha nos freios com "atualizamos o manual do proprietário para recomendar reduzir a velocidade antes de cruzamentos".
A falha existia porque a camada de autenticação do Vertex AI funcionava perfeitamente — agentes conectavam, tokens eram trocados, handshakes completados — enquanto a camada de autorização era um terreno baldio. Ninguém no Google construiu a parte que pergunta "esse agente deveria ter acesso a isso?"
Credential Vault da Anthropic: Um Workspace, Todas as Chaves, Zero Paredes
Uma semana depois do vexame do Google, a Anthropic lançou o Claude Managed Agents em 8 de abril com níveis de permissão por ferramenta — allowed_tools, denied_tools. Melhor que nada. Mas em 13 de abril, o pesquisador de segurança hi120ki demonstrou que o Credential Vault por baixo dessas permissões tem um problema gritante de confused deputy (quando um programa confiável é enganado para usar mal sua autoridade).
O caminho de ataque é direto e feio:
- Um workspace tem múltiplos agentes, cada um com credenciais de ferramentas diferentes armazenadas no Credential Vault
- O Vault limita o acesso no nível do workspace, não do agente ou da sessão
- Qualquer API key com acesso ao workspace pode referenciar qualquer credencial nesse vault
- Um atacante (ou um agente comprometido) com uma API key válida do workspace pode injetar chamadas de ferramentas usando credenciais que pertencem a outros agentes
Na prática: o Agente A tem acesso somente-leitura ao GitHub. O Agente B tem credenciais de escrita no banco de dados de produção. Se a sessão do Agente A for comprometida — via injeção de prompt, envenenamento de ferramenta, ou um servidor MCP malicioso — ele pode puxar as credenciais de banco do Agente B pelo Vault compartilhado e executar escritas. Os níveis de permissão por ferramenta (allowed_tools) governam o que o agente deveria fazer. O Vault governa o que ele pode fazer. Essas duas listas não batem.
A prova de conceito do hi120ki mostrou acesso cruzado de credenciais entre agentes numa única chamada de API. A correção exigiria isolamento de credenciais por agente — essencialmente, dar a cada agente sua própria partição no vault com separação criptográfica. Até 19 de abril, nenhuma correção foi lançada.
Isso é o padrão confused deputy na sua forma mais pura: o Vault é o deputado confiável, o agente comprometido é o requisitante confuso, e as credenciais-alvo são a autoridade de outra pessoa. O disfarce mal cobre a bagunça.
O Padrão: Autenticação Resolvida, Autorização Inexistente
Esses não são bugs isolados. São sintomas de uma camada arquitetural que simplesmente não existe.
A falha do Azure DevOps MCP (CVE-2026-32211, CVSS 9.1, divulgada em 3 de abril) — que eu cobri quando saiu — mostrou o mesmo vazio pela direção oposta: não permissões excessivas por padrão, mas zero autenticação do lado da ferramenta. As Claude Code Routines, lançadas em 14 de abril como agentes rodando em agendamentos sem aprovação humana, amplificam qualquer pecado de permissão já existente ao remover o último checkpoint humano.
Mesma doença, órgãos diferentes. Autenticação (o agente consegue se conectar?) está basicamente resolvida — fluxos OAuth, API keys, credential vaults cuidam dos handshakes sem problema. Mas autorização (o que o agente pode fazer uma vez conectado?) continua sendo um vazio. Cada ferramenta tem seu próprio modelo de permissão — escopos do GitHub, políticas IAM da AWS (regras granulares de acesso para recursos em nuvem), acesso por página do Notion — mas nenhuma plataforma de agentes agrega, audita, ou aplica o princípio do menor privilégio no conjunto completo de ferramentas.
A camada entre "ferramenta conectada" e "ação executada" não existe.
Uma auditoria de 7.000 servidores MCP feita em 11 de abril pela Pomerium encontrou 36,7% vulneráveis a SSRF (Server-Side Request Forgery — enganar o servidor para fazer requisições não autorizadas a sistemas internos). Mais de um terço dos servidores MCP podem ser transformados em pontos de pivô na rede. Não porque o protocolo é quebrado, mas porque implementações individuais dos servidores assumem que o agente que conecta é confiável e devidamente limitado. Assumem que a camada de autorização existe acima deles. Não existe.
Por Que Ninguém Vai Corrigir Isso Até Custar Caro
A computação em nuvem rastejou por 15 anos de evolução dolorosa — de "SSH como root na máquina" até IAM granular com trilhas de auditoria, controle por roles, e menor privilégio. Chegamos lá porque vazamentos custaram dinheiro e frameworks de compliance forçaram mudanças. Plataformas de agentes estão no dia zero desse mesmo rastejo, distribuindo acesso root às ferramentas por padrão e chamando isso de funcionalidade porque faz bonito na demo.
Construir autorização unificada de ferramentas mataria a mágica do "conecte qualquer coisa em 30 segundos". Adicionaria fricção na configuração e enfraqueceria demos competitivas. Nenhum vendor tem incentivo de mercado para adicionar fricção primeiro. O Google não vai. A Anthropic não vai. A Microsoft não vai. O incentivo vai vir de incidentes. Provavelmente caros, públicos, e afetando múltiplos clientes.
Já temos os trailers: em julho de 2025, um agente do Replit entrou em pânico e deletou dados de produção de mais de 1.200 executivos. Em dezembro de 2025, um agente da Amazon deletou e recriou autonomamente um ambiente de produção ativo, causando 13 horas de indisponibilidade no AWS Cost Explorer. Esses foram acidentes. A próxima rodada não vai ser.
Cada servidor MCP com permissões excessivas, cada API token com acesso total, cada conexão de ferramenta sem escopo definido é uma vulnerabilidade latente — dormente enquanto um humano clica "aprovar", ativa no momento em que um agente roda autonomamente num agendamento.
O próximo diferencial real na corrida das plataformas de agentes não é o modelo nem a quantidade de ferramentas. É o primeiro painel administrativo que mostra o que seu agente realmente pode fazer — e permite revogar a maior parte. A lacuna entre "conectado" e "autorizado" é onde mora o próximo vazamento. Agora, todo mundo está construindo pontes sobre ela sem corrimão e chamando isso de progresso.
