O MCP agora tem uma forma especificada de um agente se autenticar sem um humano no circuito. A SEP-1046 adiciona o grant OAuth client_credentials ao Model Context Protocol como extensão oficial, com private_key_jwt (client assertions JWT do RFC 7523) como método recomendado de autenticação de cliente e client secrets simples permitidos por compatibilidade. Foi aceita em outubro de 2025 e, ao longo dos últimos meses, chegou aos SDKs de TypeScript, Python e agora Ruby. Se você roda agentes em uma empresa, esta é a peça do quebra-cabeça que você estava esperando, mesmo sem saber o número da SEP.

Uma confissão antes da substância: este post quase não saiu. O espaço de IA agêntica se move rápido o bastante para que escrever sobre ele seja, por si só, um problema de agenda; a SEP-1046 ficou parada nos meus rascunhos enquanto três outras coisas eram publicadas, e só encontrei tempo agora porque a sinopse de Brad Webb sobre padrões de autorização MCP corporativa caiu na minha fila de leitura e deixou o quadro completo o suficiente para valer o seu tempo. Leia o texto dele também. Este aqui é a minha versão mais curta e mais opinativa sobre o que realmente importa para times corporativos.

Como uma issue do GitHub vira uma camada de segurança

Em 24 de julho de 2025, Darin McAdams abriu a issue #1046 no repositório da especificação do MCP. O pedigree importa aqui: McAdams passou quase 26 anos na Amazon, o último trecho como Senior Principal Software Engineer, e escreveu essa proposta em suas semanas finais lá, antes de ir para a empresa de segurança de identidade Defakto Security como Architect. A proposta é curta e cirúrgica: a especificação original de autorização do MCP mencionava o fluxo de client credentials, revisões posteriores o removeram, e a especificação acabou silenciosa sobre o cenário corporativo mais comum de todos, um workload que precisa chamar um servidor MCP quando nenhum usuário final está presente para clicar em uma tela interativa de consentimento.

A proposta foi aceita como SEP-1046 e finalizada em 30 de outubro de 2025, publicada como a extensão MCP io.modelcontextprotocol/oauth-client-credentials em vez de uma mudança na especificação central. Depois vieram as implementações: PrivateKeyJwtProvider no SDK de TypeScript, PrivateKeyJWTOAuthProvider no SDK de Python e, mais recentemente, um commit de Koichi ITO (koic, conhecido pelo RuboCop) adicionando suporte a private_key_jwt ao SDK oficial de Ruby, com direito a um cenário de conformidade. Essa progressão, de proposta a SEP aceita a implementações independentes passando em uma suíte de conformidade compartilhada, é a cara de um protocolo amadurecendo. Dois anos atrás, "autenticação MCP" significava um bearer token em uma variável de ambiente e uma oração.

Por que client credentials importa: agentes não têm navegador

O fluxo authorization code do OAuth, sobre o qual a especificação base do MCP se apoia, pressupõe um humano. Alguém vê uma tela de consentimento, se autentica no provedor de identidade e delega uma fatia da sua autoridade ao cliente. Esse modelo serve para o Claude Desktop conectando ao seu CRM. Não serve para os workloads que as empresas de fato implantam: um agente de reconciliação noturno, um pipeline de CI que consulta um servidor MCP interno, um agente supervisor distribuindo trabalho para agentes especialistas às 3 da manhã. Ninguém está acordado para clicar em "Permitir".

Client credentials é o padrão de service account de qualquer manual de IAM corporativo, aplicado ao MCP. O workload tem identidade própria, registrada com antecedência na sua plataforma de identidade, e se autentica como ele mesmo. Sem sessão de usuário emprestada, sem automação de navegador headless fingindo ser uma pessoa, sem personal access token de longa duração remendado dentro de um gerenciador de segredos. O agente é um principal de primeira classe, com seus próprios entitlements, sua própria trilha de auditoria e seu próprio ciclo de vida. Se o seu time de segurança vem bloqueando adoções de MCP porque "os agentes se autenticam como o Dave", esta é a resposta a dar a eles.

private_key_jwt: o default certo, e seu custo

A SEP-1046 restringe deliberadamente a autenticação de cliente a duas opções. Client secrets via HTTP Basic são permitidos, porque todo provedor de identidade do planeta os suporta hoje. Mas o método recomendado é private_key_jwt: o cliente assina uma assertion JWT de vida curta com uma chave privada e a apresenta no lugar de um secret. Os detalhes de design nas implementações dos SDKs valem a leitura, porque codificam julgamento de segurança de verdade:

  • A assertion carrega iss e sub definidos como o client ID, aud definido como o identificador de issuer do servidor de autorização, um exp de 300 segundos e um jti único. Assertions roubadas expiram em cinco minutos e não podem ser reutilizadas.
  • A chave privada nunca sai do cliente e nunca é escrita no armazenamento de tokens. Não há secret compartilhado parado no banco de dados do servidor de autorização esperando um dump.
  • O client_id é totalmente omitido do corpo da requisição; a identidade viaja dentro da assertion assinada. A requisição de token também carrega o parâmetro resource do RFC 8707, então o token que volta fica vinculado a um servidor MCP específico, em vez de servir contra qualquer coisa que aceite aquele issuer.

O custo é a gestão de chaves. Chaves assimétricas exigem geração, distribuição, rotação e revogação, e a SEP-1046 intencionalmente ainda não especifica como um servidor descobre o JWKS do cliente para validar assertions; isso espera o trabalho de headless JWT do WIMSE e o amadurecimento do draft de Client ID Metadata no IETF. Na prática, isso significa que a maioria dos times vai lançar primeiro com client secrets e migrar para assertions JWT conforme o ferramental da plataforma de identidade acompanhar. Está tudo bem. Escolher hoje a opção compatível com um caminho de upgrade especificado é diferente de não ter caminho nenhum.

Uma omissão deliberada gerou debate na thread da issue: mTLS. Vários comentaristas queriam certificados de cliente do RFC 8705 no escopo, e a resposta contrária explica por que ficaram de fora: em implantações reais, o TLS termina no CDN ou no load balancer, vários saltos antes da camada de aplicação onde o MCP de fato roda, então o servidor nunca vê o certificado do cliente sem ginástica de infraestrutura. Empresas com uma PKI interna funcional ainda podem fazer mTLS entre seus próprios serviços; a especificação apenas se recusa a impor essa premissa a todo o resto.

Os padrões que sobrevivem ao contato com uma empresa

O artigo do Webb enquadra a decisão melhor do que qualquer tabela comparativa de protocolos: comece por onde a autoridade do agente se origina, não por um cardápio de fluxos OAuth. Todo o resto decorre dessa pergunta. Três padrões cobrem quase todos os casos corporativos:

  • Autoridade delegada do usuário para ferramentas interativas: os entitlements do humano fluem para o agente pelo fluxo authorization code. A armadilha aqui é o token pass-through, encaminhar o token do provedor de identidade upstream direto para o servidor MCP. Funciona na demo e, em produção, acopla sua plataforma de agentes a um formato de token e a um modelo de confiança alheios. Troque o token por um de vida curta, emitido para aquele servidor MCP específico, com validação de audience aplicada. O requisito de resource indicator do RFC 8707 na especificação existe exatamente para fazer a lavagem de tokens genéricos falhar.
  • Identidade de máquina para workloads não assistidos: client credentials da SEP-1046, prefira private_key_jwt, um cliente registrado por workload de agente, não um cliente "agents" compartilhado pela plataforma inteira. O raio de dano acompanha a granularidade do registro.
  • Identidade dupla para o meio-termo interessante: um agente agindo em nome de um usuário, mas rodando sem supervisão. O token deve representar tanto o ator (o agente) quanto o sujeito (o usuário), o que o token exchange suporta e a maioria dos servidores de autorização já sabe expressar. É o padrão que mantém respondível na auditoria a pergunta "qual humano responde por esta ação", que é a pergunta que o seu time de compliance vai de fato fazer.

Sobre o registro em si: a SEP-991 tornou os OAuth Client ID Metadata Documents o padrão preferido para clientes e servidores sem relação prévia, uma URL HTTPS como identificador de cliente. Elegante para o ecossistema aberto; para uma empresa fechada, o pré-registro pela plataforma de identidade corporativa continua sendo o default mais forte, porque dá a você posse, allow-listing e controle de ciclo de vida, e remove do seu modelo de ameaças uma classe inteira de preocupações de SSRF via busca de metadados.

SEP-1046 é uma faixa, não a estrada inteira

Passe uma hora no label auth do repositório da spec e o enquadramento de SEP único desmorona: existe um grupo de trabalho de auth permanente com cadência de reuniões, e uma fila de propostas que desenha o próximo passo da autorização MCP corporativa. A SEP-1488 adiciona securitySchemes aos metadados de ferramentas para servidores de auth mista, um servidor expondo ferramentas públicas ao lado de ferramentas protegidas por OAuth. A SEP-1489 padroniza o erro que uma ferramenta retorna para disparar um fluxo OAuth no meio da sessão, ou seja, autorização step-up em termos de agentes. A SEP-2742 quer que servidores remotos declarem seus métodos de autenticação de antemão, para o cliente saber onde está pisando antes de conectar. A assinatura de mensagens HTTP voltou como PR #2752 depois que a SEP-1415 ficou dormente. E o hardening segue chegando entre as SEPs de destaque: validação de issuer RFC 9207 obrigatória contra ataques de mix-up (#1721), Rich Authorization Requests conforme a RFC 9396 (#1670), encaminhamento de refresh tokens para acesso offline (#1735), e um esforço aberto para enxugar a spec de autorização delegando às RFCs OAuth em que ela se apoia (#3054). Se a segurança de agentes na sua empresa é sua, essa fila de issues é o seu roadmap. Leia como você lê o seu próprio backlog.

O que fazer com isso na segunda-feira

Concretamente, para um time de plataforma ou segurança implantando MCP dentro de uma organização:

  • Inventarie toda integração MCP e classifique cada uma: interativa, não assistida ou agindo-em-nome-de. O fluxo decorre da classe, nunca o contrário.
  • Dê a cada agente não assistido seu próprio cliente registrado no provedor de identidade. Comece com client secrets se o seu ferramental exigir, mas coloque private_key_jwt no roadmap agora e verifique se o seu SDK já o suporta. TypeScript, Python e Ruby suportam.
  • Aplique validação de audience em todo servidor MCP que você opera. Um token emitido para um servidor deve falhar em outro. É o controle mais barato de toda a pilha e o mais frequentemente pulado.
  • Proíba token pass-through no code review, do mesmo jeito que você proíbe SQL montado por string. É a injeção de SQL da identidade de agentes: conveniente, onipresente e errada.
  • Mantenha as permissões dos agentes read-only por padrão e coloque um portão em cada caminho que muta estado, a mesma postura que defendi na camada de infraestrutura no post do gateway da série Agents on Call. Autenticação diz quem o agente é; não diz nada sobre o que ele deveria poder fazer.

O ponto maior: todo mês, mais um pedaço de "empresas não podem adotar agentes por causa de X" é resolvido em silêncio em alguma issue do GitHub. Autenticação era o maior X. Um ano atrás, a resposta honesta para "como nossos agentes não assistidos se autenticam em servidores MCP" era dar de ombros. Agora é um número de SEP, dois métodos de autenticação de cliente e testes de conformidade em três SDKs. Estamos todos aprendendo o que dá para construir, e como, um pouco mais a cada semana. Os times que acompanharem essas costuras enquanto elas se fecham vão entregar um ano à frente dos times que esperam por um livro-texto pronto, porque ele não vai existir.

Leia isto a seguir

Identidade é só metade da segurança de agentes. IAM for LLM Apps: Least Privilege When the Caller Is a Model cobre a metade da autorização na AWS. No site irmão, Agent Toolkit for AWS: The Docs Have a New Reader examina o que acontece quando o agente que consome sua infraestrutura é também o que lê o manual, e ercanermis.com tem o mapa completo do que escrevo em cada lugar.

Referências