Você conectou seu agente de IA ao Slack, GitHub e Jira. A plataforma mostrou um diálogo educadinho: "Permitir acesso ao Slack?" Você clicou sim. Se sentiu responsável. Se sentiu no controle.

Você não estava. O agente acabou de mandar uma DM pro seu CEO com um rascunho de bug report que era pra ir no #engineering. A tela de permissão nunca perguntou sobre destinatários, canais, ou o que "acesso ao Slack" realmente significa quando é uma máquina segurando as chaves.

Três plataformas, um padrão, zero profundidade

Duas semanas atrás, a discussão era sobre plataformas de agentes sem nenhuma autorização decente — agentes com acesso root e ninguém construindo sudo. Essa conversa já ficou velha. As três grandes plataformas já lançaram sua resposta: workflows de aprovação de ferramenta, aqueles prompts de "Tem certeza?" que aparecem antes de um agente de IA (um programa que age em seu nome, não só conversa) fazer algo consequente. A lacuna de autorização não foi preenchida. Foi coberta com papel de parede.

O ADK do Google adicionou confirmações de ação no Cloud Next (22–24 de abril). Os Managed Agents da Anthropic, lançados em 8 de abril, incluíram políticas de permissão por ferramenta desde o primeiro dia. O Agents SDK da OpenAI lançou callbacks needs_approval na atualização de 15 de abril. Três empresas, convergindo na mesma ideia — como três arquitetos projetando independentemente o mesmo telhado furado.

O padrão é idêntico nas três: você aprova ou nega acesso no nível da ferramenta. "Permitir Slack" ou "Negar Slack." Binário. Liga ou desliga. Um segurança conferindo documento na entrada do prédio enquanto todas as portas dos apartamentos lá dentro ficam escancaradas.

Onde o perigo real mora

O raio de explosão de uma chamada de ferramenta ruim — o estrago que ela realmente faz — mora nos parâmetros: em qual canal do Slack a mensagem vai parar, em qual branch do Git alguém faz force-push, qual query SQL roda no seu banco de produção, em qual projeto do Jira o agente despeja tickets gerados automaticamente.

Pra ser justo, o Google ADK e a OpenAI passam os parâmetros da chamada para callbacks escritos pelo desenvolvedor. Você pode escrever código como return amount > 1000 para bloquear operações caras. Mas aqui está a distinção crucial: a plataforma te dá um gancho, não uma rede de segurança. Você escreve as regras sozinho, em Python puro, para cada ferramenta, cada parâmetro, cada caso extremo. Nenhum motor de políticas declarativas. Nenhuma allowlist embutida. Nenhum toggle de "só postar em #engineering e #random" num dashboard.

A implementação da Anthropic é ainda mais simples — suas políticas de permissão operam puramente por nomes de ferramentas. O evento user.tool_confirmation aceita exatamente duas respostas: "allow" ou "deny". Sem campo para restrições de argumentos. Sem lógica condicional. O agente ou pode usar o Slack ou não pode.

Como escreveu o pesquisador de segurança Simon Willison em setembro de 2024: "Uma vez que um agente LLM ingeriu input não confiável, ele deve ser restringido de forma que seja impossível para aquele input disparar qualquer ação consequente." Gates no nível de ferramenta não conseguem isso. Eles restringem quais ações existem, não o que essas ações fazem.

Esse filme a gente já viu

O padrão é um Ctrl+C/Ctrl+V das permissões de celular lá de 2008. O Android 1.0 concedia acesso genérico à "câmera" — sem distinção entre um app de selfie e um scanner de documentos fotografando silenciosamente sua mesa. O Google levou sete anos e o Android 6.0 Marshmallow (2015) para lançar permissões com escopo em tempo de execução — controles contextuais sobre como um app usa a câmera, não apenas se ele pode.

As plataformas de agentes estão no estágio Android 1.0 hoje. A janela de permissão existe. Parece segurança. Não é.

A Microsoft falou o que todo mundo pensa mas não diz

Em 22 de abril, o blog de desenvolvedores da Microsoft publicou uma admissão direta: "Seguir instruções sozinho não deve ser tratado como um limite de segurança." Os próprios testes de red team deles — conduzidos como parte do Agent Governance Toolkit que eles abriram o código no início do mês — revelaram uma taxa de violação de política de 26,67% usando guardrails baseados apenas em prompt. Uma em cada quatro chamadas perigosas passa direto se você confia no LLM para se policiar sozinho.

O AGT é a coisa mais próxima de uma solução real: uma camada de middleware que fica entre seu agente e suas ferramentas, aplicando regras de política declarativas escritas em YAML, OPA ou Cedar. Ele realmente inspeciona parâmetros. Ele realmente bloqueia com base nos valores dos argumentos. Mas é um middleware que você mesmo instala — não é nativo de nenhuma plataforma de agentes. Fita isolante boa, mas fita isolante.

O preço de fazer direito

Gating no nível de parâmetros é genuinamente difícil. Requer compreensão semântica — saber que #geral é um canal público enquanto #remuneracao-diretoria não é. Adiciona latência a cada chamada de ferramenta em sistemas que já lutam contra limites de janela de contexto (quanto texto a IA consegue "ver" de uma vez). E, pior de tudo, cria fadiga de aprovação: quanto mais granulares os gates, mais rápido os usuários se treinam para clicar em "aprovar tudo" sem ler — exatamente o comportamento que transforma permissões em teatro.

O que você deveria fazer de verdade

Até as plataformas lançarem gates com reconhecimento de parâmetros como recurso nativo, você tem duas opções honestas. Uma: construir middleware que verifica os argumentos das chamadas de ferramenta contra allowlists — canais seguros, branches seguros, padrões de query seguros. Duas: aceitar que clicar em "Permitir Slack" significa "permitir que o agente faça qualquer coisa que a API do Slack suporta" e se planejar de acordo.

A janela de permissão na sua plataforma de agentes é um placebo. Ela controla quais portas o agente pode abrir, mas não o que o agente faz dentro do cômodo. Três plataformas lançaram a mesma fechadura em abril de 2026, e nenhuma delas incluiu a tranca.