Seus agentes têm um problema de credencial espalhada

Conecte um agente à sua agenda, à sua caixa de entrada, ao seu CRM e à sua ferramenta de cobrança, e você acabou de entregar a ele quatro conjuntos de chaves pra segurar. Conecte três agentes às mesmas quatro ferramentas, e você está segurando doze. Cada uma é um token que pode ser roubado, um escopo mais amplo do que precisa ser, e um schema que o modelo tem que ler antes de fazer uma única coisa útil. A demo funcionou. A conta não fechou.

Essa é a parte que ninguém tira print. O agente que marca a reunião leva os aplausos. A pilha de credenciais que ele teve que carregar pra chegar lá é a fatura que chega depois, e ela chega na forma de um vazamento, de uma chamada de ferramenta errada, ou de uma janela de contexto sem espaço sobrando pra pensar.

Essa é a tese, e o resto deste texto é o mecanismo. Parafusar uma dúzia de tool servers num chatbot não te dá uma empresa de IA, te dá uma dúzia de vazamentos de credencial e um imposto de contexto. Um SO é dono das conexões pra o agente não precisar ser.

A versão ingênua: dê a cada agente as próprias chaves

A primeira coisa que todo mundo constrói é a coisa óbvia. Você quer que o seu agente leia a agenda, então você dá um token de agenda pra ele. Quer que ele envie e-mail, então você dá um token de e-mail. CRM, cobrança, docs, chat, cada um é ligado, cada um é uma conexão que o agente segura direto. Parece progresso, porque cada ferramenta nova deixa o agente visivelmente mais capaz.

Aí você adiciona um segundo agente. E um terceiro. Vendas, ops, financeiro, cada um precisa da sua própria fatia das mesmas ferramentas. Ninguém decidiu construir uma malha; ela só cresceu, uma ligação razoável de cada vez.

A imagem é o problema. Três agentes e quatro ferramentas não são três mais quatro relações. É uma grade, cada agente vezes cada ferramenta que ele toca, e a grade é feita de segredos. O emaranhado é a arquitetura, e a arquitetura vaza.

Por que ela falha, parte um: as credenciais fogem do seu controle

Um token guardado num lugar só é uma coisa que você consegue vigiar. Um token copiado pra dentro de todo agente que precisa dele é uma coisa que você perdeu de vista.

Isso não é um modo de falha hipotético. O relatório State of Secrets Sprawl da GitGuardian contou 28.649.024 novos segredos expostos em commits públicos do GitHub ao longo de 2025, um salto de 34% sobre o ano anterior, o maior da história do relatório (Help Net Security, Snyk). Os agentes que a gente está construindo não reduzem esse número; eles o multiplicam. Por uma contagem do setor, a empresa média hoje roda algo entre 82 e 144 identidades não humanas pra cada identidade humana (Token Security). Cada uma dessas identidades de máquina é uma credencial pra emitir, escopar, rotacionar e, quando vaza, revogar.

Agora rode a rotação adiante. Um token de agenda expira. No modelo parafusado, você não rotaciona uma credencial, você a persegue por todo agente que a copiou, e reza pra ter encontrado todos. Esquece um, e um agente quebra em silêncio em produção. Esquece um do outro jeito, deixa um token morto ativo, e você deixou uma porta aberta.

O emaranhado é a arquitetura, e a arquitetura vaza. O mecanismo é simples: um segredo duplicado N vezes tem N lugares de onde escapar e N lugares pra esquecer.

Por que ela falha, parte dois: o imposto de contexto

O segundo custo é mais silencioso, e ele aparece dentro do próprio modelo.

Toda ferramenta que um agente pode chamar tem que ser descrita pra ele primeiro, o nome da ferramenta, os parâmetros dela, o que ela retorna. Parafuse ferramentas demais e essas descrições sozinhas conseguem engolir a conversa antes de ela começar. O próprio tool server do GitHub consome cerca de 17.600 tokens de definições por requisição, e conectar só uns poucos servers já te empurra pra além de 30.000 tokens de metadados antes de o agente fazer qualquer trabalho (StackOne). Ligue um punhado e você pode ver três servers comerem 143.000 de uma janela de 200.000 tokens, 72% da memória de trabalho do agente gasta antes de ele ler uma única palavra sua.

Isso não é só desperdício. É uma queda mensurável na capacidade do agente de acertar.

Os pesquisadores por trás do projeto RAG-MCP mediram o que acontece com a seleção de ferramentas conforme o cardápio cresce: diante de um conjunto inchado de ferramentas, a acurácia base ficou em meros 13,62%, menos de uma em sete, e buscar só as ferramentas relevantes sob demanda mais que triplicou isso, pra 43,13% (RAG-MCP, arXiv:2505.03275). Enterre a resposta certa numa lista mais longa e o agente escolhe a ferramenta errada cerca de seis vezes em sete, não porque ele ficou mais burro, mas porque você a enterrou. A regra de bolso que se firmou a partir disso é direta: mantenha um agente em no máximo 10 a 15 ferramentas por vez.

Então o modelo parafusado falha duas vezes. Ele vaza as chaves, e tributa o raciocínio. Adicione uma ferramenta pra deixar o agente mais esperto, e passado um certo ponto você o deixa ao mesmo tempo mais vazante e menos preciso.

A versão SO: seja dono da conexão uma vez, empreste-a sob escopo

Aqui está o movimento. O agente não devia segurar as chaves. O sistema operacional devia, e emprestar cada ferramenta, com escopo, só pelo tempo que o trabalho durar.

Pense em como o seu notebook já faz isso. O seu código não carrega o driver da sua impressora específica; o SO é dono dessa conexão e o seu programa só diz “imprimir”. A aplicação nunca segura os segredos do hardware, e nunca precisa, a camada de permissões fica no meio, concedendo acesso por requisição e revogando no instante em que o trabalho termina. Um SO de empresa trata toda integração do mesmo jeito. A conexão com a agenda, a caixa de entrada, o CRM, a ferramenta de cobrança é de propriedade de um único lugar. Um agente não tem o token do CRM; ele pede ao SO pra fazer a coisa do CRM, e o SO decide, sob o escopo daquele agente, pra aquela ação só, se empresta o acesso.

Veja no que cada falha se transforma quando você tira a conexão do agente.

A rotação deixa de ser uma caçada. A credencial mora num lugar só, então é rotacionada num lugar só. Expire-a, troque-a, e todo agente continua trabalhando pela mesma porta da frente, sem saber de nada. Não há cópia pra perseguir porque nunca houve cópia.

O raio de explosão encolhe pra um escopo. Um agente vazado deixa de ser um cofre vazado. Ele pode fazer aquilo pra que foi escopado e nada mais, porque ele nunca segurou a chave subjacente, ele segurou uma concessão estreita e revogável. É essa a direção pra onde o campo inteiro está indo: acesso com escopo e delegado como padrão, respaldado por cofre, com uma identidade distinta por agente em vez de um segredo compartilhado passado de mão em mão (1Password, GitGuardian).

O imposto de contexto é quitado. Quando o SO é dono das ferramentas, o agente não precisa de todo schema carregado por via das dúvidas. Ele pede a ferramenta que precisa, quando precisa, e o resto fica fora da janela, deixando espaço pra o modelo de fato raciocinar. A correção pro inchaço em que o setor não para de aterrissar tem sempre o mesmo formato: não despeje toda definição no contexto de antemão; busque sob demanda (Anthropic, The New Stack).

A trilha de auditoria vira um registro único. Quando toda chamada de ferramenta passa por uma única camada de permissões, você tem um único lugar que sabe qual agente tocou qual sistema, quando, e sob qual concessão. No emaranhado, esse registro estava espalhado por uma dúzia de servers, se é que existia. Um SO que é dono das conexões é dono da resposta pra “quem fez o quê” por construção.

Mesmos agentes. Mesmas ferramentas. Postura oposta. A capacidade não mudou, o lugar onde as chaves moram mudou. No modelo parafusado o emaranhado é a arquitetura, e a arquitetura vaza; aqui a conexão é a arquitetura, e a arquitetura segura.

A virada: integrações são infraestrutura, não funcionalidades

É tentador tratar “conectar uma ferramenta” como uma funcionalidade que você adiciona a um agente. Não é. É infraestrutura que você constrói uma vez, embaixo de todos eles, e a diferença entre esses dois enquadramentos é a diferença entre uma demo e uma empresa que você consegue tocar.

Os times que vencerem os próximos anos não serão os que tiverem mais integrações de ferramentas parafusadas nos mais agentes. Contar integrações é contar credenciais que você tem que vigiar e schemas que você tem que pagar. Os times que vencerem serão aqueles em que um agente consegue estender a mão pra qualquer ferramenta da empresa e nunca precisa segurar a chave dela, onde adicionar o décimo agente não significa emitir o quadragésimo segredo, e adicionar a vigésima ferramenta não rouba a capacidade do agente de pensar.

Isso não é um checkbox de segurança. É o que te deixa de fato escalar o número de agentes fazendo trabalho de verdade, porque o custo de cada novo deixa de ser composto. Você para de ser a pessoa que rastreia pra onde foram todas as chaves. O sistema operacional já sabe, porque foi ele quem as segurou esse tempo todo.

---

O emaranhado é a arquitetura, e a arquitetura vaza, até a conexão sair do agente e ir pra plataforma embaixo dele. A gente está construindo isso na Apollo Space, um sistema operacional nativo em IA para empresas, onde as conexões moram na plataforma e os agentes só fazem o trabalho, porque um SO é dono das conexões pra o agente não precisar ser. Se o seu roadmap de IA começou a parecer uma planilha de tokens pra rotacionar, isso não é um problema de integração. É um sistema operacional faltando.