Suas ferramentas MCP estavam funcionando. Slack, GitHub, Jira, banco de dados — tudo conectado via MCP, o padrão universal de plugs para ferramentas de IA. Você colou as chaves de API num JSON de configuração, rodou localmente e se sentiu um mago. Tudo conversava com tudo.
Aí seu time de segurança apareceu. Onde estão essas credenciais armazenadas? Como é feita a rotação? Quem mais pode lê-las? A resposta para as três: ninguém sabe. E aquele pânico silencioso que você sentiu? Multiplique por cada empresa tentando levar agentes de IA do demo para produção.
Em abril de 2026, as três grandes plataformas de IA lançaram suas soluções de credenciais para MCP — e nenhuma delas concorda em como isso deveria funcionar.
Um Protocolo, Três Cofres
Em 9 de abril, a Anthropic lançou os Managed Agents com o Credential Vault — um proxy criptografado que busca seus segredos para que o código do seu agente nunca toque nas credenciais reais. OAuth com auto-refresh, bearer tokens estáticos, o pacote completo. Limitado a 20 credenciais por vault, porque aparentemente segurança enterprise vem com cartão de fidelidade.
Em 15 de abril, a OpenAI atualizou seu Agents SDK. A proposta: passe um bearer token no header, cuide do refresh você mesmo. Precisa de OAuth? Construa. Mas aí vem a comédia: os ChatGPT Apps exigem OAuth 2.1 — bearer tokens barrados na porta. Uma empresa lançando um SDK que diz "tokens tão de boa" e um produto que diz "de jeito nenhum". A OpenAI está tendo uma discussão pública consigo mesma sobre autenticação, e os devs que se virem pra escolher um lado.
Em 17 de abril, o Google lançou o ADK 1.0 — apresentado depois no Cloud Next em 22 de abril. Cinco tipos de credenciais incluindo service accounts, Application Default Credentials e um fluxo OAuth com pausa e retomada. Funciona lindamente — se você já jurou fidelidade ao GCP. Para o resto do mundo, é uma reescrita completa de auth com sotaque do Google.
Três abordagens inteligentes. Três sistemas incompatíveis. O MCP deveria ser o USB da IA. Acontece que cada porta precisa de um carregador diferente.
A Spec Que Ninguém Segue
A especificação do MCP (versão 2026-03-15) exige OAuth 2.1 com resource indicators — tokens com escopo adequado, segurança adequada, tudo certinho. No papel, o problema está resolvido.
Na prática, o ecossistema não recebeu o memorando. Como cobrimos na análise de supply chain da semana passada, servidores MCP têm um problema fundamental de higiene — a maioria dos servidores da comunidade ainda depende de chaves de API estáticas jogadas em arquivos de configuração. A auditoria da AgentSeal de 10 de abril em 1.808 servidores encontrou dois terços repletos de vulnerabilidades, de bypass de autenticação a injeção de comandos. Nada disso melhorou em duas semanas.
Mas o ângulo específico de autenticação importa mais aqui: dos parceiros de lançamento das três plataformas, quase nenhum implementa OAuth 2.1 conforme a spec real. O Credential Vault da Anthropic estreou com Notion, Asana e Sentry — três integrações gerenciadas de centenas de servidores que os desenvolvedores realmente usam. A documentação do ADK do Google mostra cinco padrões de auth mas usa API keys nos exemplos padrão. O SDK da OpenAI chuta a bola pra frente — "traga sua própria auth" significa que a maioria dos devs traz o caminho de menor resistência: um token estático colado de um dashboard.
Por que a lacuna? OAuth 2.1 exige infraestrutura server-side. Um dev solo mantendo um conector MCP open-source nos fins de semana não tem um token endpoint, um servidor de redirect, nem um fluxo de refresh. Como um mantenedor frustrado colocou nos fóruns da comunidade: "Eu simplesmente odeio que os clients não suportem todos OAuth ou API key, então tenho que dar suporte aos dois!" A spec exige o que a força de trabalho do ecossistema não consegue entregar.
O Custo Real: Escreva Uma Vez, Fique Preso Em Todo Lugar
O modelo de auth de cada plataforma faz sentido internamente. A Anthropic faz papel de mãe coruja — trancando o armário de remédios pra criançada não se envenenar. O Google aproveita sua stack de identidade na nuvem — eficiente se você já mora na casa do GCP. A OpenAI maximiza a liberdade do desenvolvedor — que é um jeito diplomático de dizer que não quiseram construir infraestrutura de auth e chamaram isso de feature.
O custo coletivo é lock-in na camada de credenciais. Uma ferramenta conectada ao Credential Vault da Anthropic não funciona no Google ADK sem reescrever a auth. Uma ferramenta que depende de service accounts do GCP é inútil no SDK da OpenAI. O MCP prometia "escreva uma vez, conecte em qualquer lugar". A autenticação transformou isso em "escreva uma vez, depois reescreva a autenticação para cada plataforma". Mesma ferramenta, três contas de imposto de integração.
O relatório de segurança MCP do Futurum Group resumiu bem: "A pergunta que as empresas estão realmente fazendo não é se o MCP funciona. É se conseguem governar o que ele faz."
Seu Time de Segurança Ainda Está Esperando
Lembra deles? Ainda parados na sua porta. Só que agora, em vez de uma resposta desconfortável, você deve três — cada uma te prendendo à teologia de uma plataforma diferente sobre como credenciais devem funcionar.
Se você está avaliando ferramentas MCP para produção, checar funcionalidade não basta. Aquele conector do Slack rodando suave no Managed Agents do Claude? Coloque no orçamento uma reescrita completa de auth para o Google ADK. Seu time escolheu o SDK da OpenAI pela "flexibilidade"? Divirta-se construindo OAuth do zero enquanto os ChatGPT Apps se recusam a usar o que você construiu.
O MCP tem um protocolo e três religiões de credenciais. O protocolo funciona. A parte "universal" estilhaçou na camada de autenticação — exatamente onde demos viram deployments. Quem tornar auth baseada em padrões algo sem atrito para quem constrói servidores MCP, e não só para quem consome, captura o mercado de produção. Agora, ninguém fez isso. Puxe mais cadeiras pro seu time de segurança — essa reunião vai ser longa.





