A segurança de agentes de IA começa com uma regra: seu agente de IA nunca deveria guardar suas credenciais. Aqui está o padrão de broker de 38 anos que garante isso.
Agentes de IA são "deputies" confusos. Esse é um padrão de segurança de 38 anos, e a resposta é igualmente antiga: coloque um broker — uma camada intermediária confiável, observável, determinística, auditável, infalsificável, de escopo restrito, orientada por políticas e não baseada em IA — entre o agente e as APIs SaaS que ele precisa chamar, guardando as credenciais que seu agente não deveria ter.
Em 1988, Norm Hardy publicou um artigo curto descrevendo um incidente real de sua época na Tymshare. Um compilador Fortran chamado FORT ficava em um diretório de sistema chamado SYSX. Para coletar estatísticas de uso, o compilador precisava escrever em (SYSX)STAT, então o sistema operacional havia concedido ao FORT uma "home files license", autorizando-o a escrever qualquer arquivo dentro de SYSX. O arquivo de cobrança do sistema, (SYSX)BILL, também ficava ali. Um usuário que invocava o compilador podia fornecer um nome de arquivo para receber saída de depuração opcional. Um dia, um usuário forneceu (SYSX)BILL. O compilador pediu ao SO para abrir esse arquivo para escrita; o SO, observando a home files license, permitiu. Os dados de cobrança foram sobrescritos. O compilador fez exatamente o que foi projetado para fazer. A falha era arquitetural.
Hardy o batizou de confused deputy problem: um programa privilegiado (o deputy) detém autoridade própria; um chamador menos privilegiado pede que ele faça algo; o deputy se confunde sobre a autoridade de quem está usando e acaba usando a sua própria. A correção é tirar essa autoridade do deputy por completo e colocá-la atrás de uma camada separada que medeia a chamada sob demanda. Essa camada é o broker.
Trinta e oito anos depois, todo agente de IA que sua empresa executa é um deputy confuso. E a maioria deles está rodando sem um broker.
Por que os agentes de IA pioram o problema de segurança
O FORT de Hardy tinha um canal de entrada: a linha de comando. Um agente de IA moderno tem dezenas: corpos de e-mail, páginas web recuperadas, PDFs enviados, saídas de ferramentas de servidores MCP, mensagens de agentes pares em um sistema multiagente. Qualquer coisa que entre na janela de contexto pode emitir instruções e, por design, o agente trata todas como legítimas.
Isso quebra uma suposição da qual o controle de acesso tradicional depende: o chamador controla a entrada. Em um aplicativo web, o chamador (a sessão autenticada) e a entrada (o corpo da requisição HTTP) vêm do mesmo lugar. Para um agente, o chamador é quem molda o prompt, o que significa que um atacante capaz de escrever um e-mail ou semear um resultado de busca também é um chamador.
Em novembro de 2025, pesquisadores de segurança da PromptArmor mostraram como isso é na prática, em produção. Eles esconderam instruções maliciosas em fonte de 1 pixel em um guia de integração. Quando um desenvolvedor apontou a IDE Antigravity do Google para ele, o agente contornou sua própria proteção de arquivos baseada em .gitignore recorrendo ao shell com cat. Em seguida, vazou o conteúdo de arquivos .env para uma URL webhook.site controlada pelo atacante, por meio do próprio subagente de navegador do Antigravity. O usuário havia configurado tudo corretamente. O sandbox se manteve. O agente simplesmente não conseguia distinguir o que o usuário pediu do que a entrada mandava ele fazer.
A mesma forma do FORT de Hardy, décadas depois: autoridade ampla, entrada não confiável, nenhuma maneira de separar as duas.
A comunidade tem respostas. Elas só estão espalhadas.
Isso não é um problema novo. A comunidade de segurança vem escrevendo respostas há décadas:
Capability-based security (Dennis & Van Horn, 1966; mais tarde a linguagem E e o trabalho de Mark Miller com o Caja no Google). O princípio: não conceda autoridade ambiente baseada em identidade ou localização; passe capabilities explícitas e infalsificáveis para cada recurso que o programa tem permissão de tocar. Uma capability une o que você pode fazer com aquilo sobre o que você pode fazer, e não pode ser confundida com nada mais.
Brokered Credentials (codificado pelo OWASP LLM Top 10). Não coloque tokens de API no contexto do LLM. Uma camada intermediária confiável faz a chamada em nome do agente; o modelo decide o que fazer, o broker cuida do como. Uma prompt injection que pede ao modelo para imprimir suas credenciais não consegue nada útil. As credenciais não estão lá.
O Phantom Token Pattern (Curity, originalmente para OAuth em microsserviços). O agente guarda um handle de sessão opaco, não o bearer token real. Um proxy valida o handle, troca pela credencial real na borda da rede e encaminha para o upstream. Se o agente vazar seu ambiente, o atacante recebe uma string que expira quando a sessão termina.
Injeção de credenciais just-in-time (sistemas de identidade de workload como o Aembit). Emita uma credencial de curta duração e escopo restrito por chamada, em vez de emitir tokens de longa duração.
Nada disso falta na literatura. Falta nos padrões de fábrica. A maioria das plataformas de agentes ainda entrega ao modelo um token OAuth, sem nenhum broker no meio, e torce pelo melhor.
Como funciona o broker do Zero
Não inventamos nenhum dos padrões acima. Nós os conectamos em um único broker que roda por padrão para cada agente no Zero. É a camada intermediária confiável que esses padrões descrevem, construída para uma plataforma de agentes de IA. Toda chamada que um agente faz a um conector passa por ele. Cada conector é um SaaS externo (Slack, GitHub, Notion e assim por diante).
O broker fica entre cada agente e cada conector. As credenciais reais vivem apenas do lado do broker, atrás da linha tracejada.
Pense nele como três camadas.
1. Isolamento de credenciais
O sandbox do agente nunca guarda uma credencial real de conector. Quando você conecta um SaaS ao Zero, o token OAuth ou a chave de API fica do lado do broker. O sandbox recebe uma string placeholder que se parece o suficiente com um segredo de ambiente para que as ferramentas existentes continuem funcionando, mas que nenhum SaaS upstream aceitaria.
Quando o agente faz uma requisição a um host de conector registrado, o broker combina a requisição, resolve o template de autenticação do conector e injeta a credencial real na borda da rede. A requisição segue para o upstream com autenticação válida; o agente nunca teve nada de útil. Um agente vítima de prompt injection que despeje suas variáveis de ambiente entrega ao atacante um placeholder, não o token do SaaS.
Esse é o phantom token pattern, aplicado a agentes de IA.
2. Portão de política de conector
Um conector no Zero deveria ser mais do que um interruptor liga/desliga. Cada conector descreve as bases de API que cobre e como a autenticação deve ser injetada. Quando o serviço upstream publica um mapeamento estável de escopo para endpoint, ele também pode descrever qual permissão nomeada cobre cada método e caminho. A slack-api-ref do Slack é um bom exemplo.
Então, quando um agente conectado ao Slack chama chat.postMessage, o broker pode mapear essa requisição para chat:write. Quando ele lê logs de auditoria, isso é admin.analytics:read. Para cada agente, as permission_policies definem como essas permissões nomeadas se comportam: allow, deny ou ask. A política é aplicada no broker antes da injeção de autenticação, e não como uma dica para o modelo. Se o agente tentar fazer uma chamada coberta por uma permissão negada, talvez por ter sido vítima de prompt injection, a chamada nunca chega à rede upstream.
Nem todo conector tem essa resolução hoje. Algumas APIs upstream não publicam um mapeamento estável de escopo para endpoint. A superfície GraphQL do GitHub é o caso clássico: o lado REST pode ser mapeado, mas o lado GraphQL ainda não. Para esses conectores, o broker continua controlando a injeção de credenciais e o caminho de rede, enquanto o portão de permissão recorre à política mais grosseira de conector ou de host que a plataforma realmente consegue aplicar. Nós preenchemos esses casos conforme os dados upstream ficam disponíveis. Não afirmamos cobertura que não construímos.
Os tokens não carregam autoridade ambiente. A autoridade é brokered por agente, na resolução que o upstream suportar. Essa é a metade capability-based da resposta.
3. Loop operacional e auditoria
Least privilege só funciona se o modo de falha for utilizável. Os agentes evoluem. Seis semanas depois, um agente de pesquisa que começou lendo do Notion pode precisar escrever um resumo de volta. Os modos de falha comuns em outros lugares: o agente roda silenciosamente sem a nova permissão e quebra, ou o operador concede demais em pânico e nunca recupera.
Uma requisição de conector negada retorna um 403 estruturado: conector, método, caminho, URL base e os nomes da permissão correspondente quando o broker consegue identificá-los. O system prompt do agente diz a ele como diagnosticar a negação e como pedir exatamente a permissão que acabou de esbarrar, gerando uma URL de concessão com um clique para o usuário ou admin. Isso mantém o caminho de escalonamento atrelado à permissão exata sendo solicitada, em vez de virar "conceda tudo".
As solicitações de mudança de permissão ficam em uma fila. Donos e admins podem aprovar ou rejeitar pelo dashboard; solicitações aprovadas atualizam a política do agente, e a próxima tentativa passa. A maioria das plataformas pula esse loop. Sem ele, "least privilege" fica no slide em vez de rodar em produção.
O mesmo caminho do broker alimenta a auditoria. Logs de rede por execução registram a atividade de rede do sandbox em HTTP, TCP, DNS e observações de pacotes de nível mais baixo para tráfego não-TCP. Requisições combinadas a conectores incluem metadados estruturados do broker: conector, permissão correspondente quando disponível, resultado allow/deny, metadados de resolução de autenticação e flag de cobrança. Se alguém mais tarde perguntar "o que esse agente fez na terça às 15h?", você reconstrói a resposta a partir desses registros. A prevenção deixa coisas passarem. A trilha de auditoria é como você descobre o quê.
O que ainda não resolvemos
Mesmo com tudo acima, um agente com um chat:write legítimo ainda pode ser convencido a postar uma mensagem constrangedora em um canal ao qual ele já tem acesso. O broker reduz o raio de impacto; ele não o elimina.
A outra metade da resposta é a aprovação de ações de alto risco, a validação de saída e tratar os retornos de ferramentas como não confiáveis por padrão. Esse trabalho está no roadmap, ainda não no produto. Quem afirma ter resolvido o confused deputy de ponta a ponta está vendendo alguma coisa para você.
Isso deveria ser o piso, não um recurso
A capability-based security existe desde os anos 1970. As brokered credentials estão no OWASP LLM Top 10. Os phantom tokens são anteriores à era dos LLMs. Nada disso falta porque ninguém sabia a resposta. Falta porque as primeiras plataformas de agentes otimizaram para "fazer a demo funcionar" e empurraram a segurança para um lançamento posterior, que muitas vezes nunca veio.
A próxima geração de plataformas deveria mirar mais alto. Tokens não deveriam entrar no contexto do modelo. A autoridade deveria ser enumerada por agente. A escalada de privilégios deveria passar por um humano. Toda ação deveria ser auditável de ponta a ponta. Nada disso é novidade. Tudo isso deveria ser a linha de base.
Quando você está escolhendo uma plataforma de agentes, "ela é segura?" não leva a lugar nenhum. Todo fornecedor diz que sim. Uma pergunta melhor: me mostre o seu broker e me explique o que acontece quando um agente pede um escopo que ele não tem.
O broker fica na frente de cada agente no Zero por padrão. O inventário de conectores, os mapeamentos de escopo, as políticas de permissão e a lógica do broker vivem todos no repositório de código do Zero. Encontrou um conector que não cobrimos? Abra uma issue.
Referências
Fundamentais
- Norm Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (o artigo fundador dos sistemas de capabilities)
- Mark Miller et al., Caja: capability-based security para a web, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Incidentes reais citados
- PromptArmor, Google Antigravity Exfiltrates Data, novembro de 2025
- Simon Willison, cobertura e análise, 25 de novembro de 2025
