MCP em produção: autorização, identidade, versão e observabilidade

Uma equipe liga o assistente corporativo a um servidor MCP do financeiro. Em uma semana a demonstração funciona: o modelo chama emitir_pagamento e responde bem. Três semanas depois, em produção, chegam três perguntas no mesmo dia. A auditoria quer saber quem autorizou um pagamento de 250 mil reais que o agente iniciou numa sexta à noite. Um time atualizou o SDK e passou a receber erro de versão. E o servidor do financeiro aceitou um token emitido para o servidor de documentos, repassado adiante "para simplificar".

Nenhuma dessas falhas é do protocolo. Elas aparecem quando o MCP deixa de ser um problema de integração e vira um problema de operação. Este ensaio organiza a passagem em quatro pilares (identidade, autorização, versionamento e observabilidade) e defende que quem os costura é uma política aplicada num ponto de passagem.

O texto continua a Série MCP: o ensaio anterior concluiu que protocolo define o possível e política define o permitido; o do roadmap de 2026 mostrou a identidade de agentes subindo nas prioridades. A especificação citada é a revisão 2026-07-28, vigente em 16 de outubro de 2026.

1. Do protótipo à produção, a pergunta muda

No protótipo, a cadeia é curta: modelo, cliente MCP, servidor, função. Se a ferramenta responde, acabou. Em produção, as perguntas são outras: quem iniciou a operação, em nome de quem, com qual token, em qual versão, e se dá para reconstruir o incidente depois.

Srinivasan (2026), a partir de uma implantação empresarial, organiza as falhas de produção em cinco dimensões (contratos do servidor, contexto do usuário, timeouts, erros e observabilidade) e conclui que a integração confiável exige infraestrutura que a especificação ainda não cobre. É um preprint, com propostas ainda por validar. As perguntas cabem em quatro pilares: identidade (quem age), autorização (o que pode fazer, aqui e agora), versionamento (se os dois lados falam a mesma língua) e observabilidade (o que aconteceu e como provar).

2. Identidade: quem age, e em nome de quem

Em MCP, "quem está agindo?" já tem várias respostas. Numa chamada da Maria ao servidor financeiro convivem pelo menos cinco identidades: a pessoa, o cliente OAuth (a aplicação que participa do fluxo de autorização), o servidor MCP (o recurso protegido), o agente (quem decidiu agir) e o workload (o contêiner que de fato fez a requisição).

A especificação nomeia três papéis: o servidor MCP protegido é um resource server do OAuth 2.1, o cliente MCP é um cliente OAuth que faz requisições "em nome de um resource owner", e o servidor de autorização emite os tokens. O agente não aparece, e client_id não é identidade de agente: um mesmo aplicativo pode hospedar vários.

O roadmap do MCP, atualizado em 22 de agosto de 2026, reconhece a lacuna: a autorização "pressupõe uma pessoa com um navegador no momento do consentimento", quando quem chama é cada vez mais um agente agindo por um usuário ausente ou criando subagentes que deveriam ter menos autoridade. A prioridade "Agent Identity and Enterprise-Ready Security" inclui DPoP, federação de identidade de workload, o ID-JAG e a troca de tokens do RFC 8693. Por ora, há duas extensões oficiais e opcionais: OAuth Client Credentials, para máquina a máquina, e Enterprise-Managed Authorization (seção 3).

A pesquisa chegou ao mesmo ponto: o SMCP (Hou et al., 2026a) propõe acrescentar ao MCP identidade unificada, autenticação mútua, propagação do contexto de segurança, política granular e auditoria. Cuidado: clientInfo e serverInfo no _meta são autodeclarados; a especificação diz que não devem embasar decisões de segurança.

3. Autorização: o OAuth recortado para o MCP

No HTTP, a autorização é um recorte de padrões conhecidos: OAuth 2.1 (ainda rascunho no IETF; Hardt, Parecki e Lodderstedt, 2026) e os RFCs 8414, 9728, 8707 e 9207, mais os Client ID Metadata Documents. No stdio, as credenciais vêm do ambiente.

Sem token, o servidor responde 401; o cliente acha os metadados do recurso protegido (RFC 9728), que todo servidor MCP deve publicar, pelo cabeçalho WWW-Authenticate ou pelo endereço .well-known. Deles o cliente descobre o servidor de autorização e segue o fluxo com PKCE e o parâmetro resource.

Quatro regras concentram a segurança. Audiência: o cliente envia resource na autorização e no pedido de token, e o servidor só aceita tokens emitidos para ele; o token do servidor de documentos não abre o financeiro. Sem repasse: para chamar uma API adiante, o servidor usa um token próprio. A especificação é literal: servidores MCP "não devem aceitar nem repassar quaisquer outros tokens". O repasse contorna controles que dependem da audiência e apaga a trilha de quem chamou quem (o confused deputy descrito por Hardy, 1988). PKCE: S256 é obrigatório quando tecnicamente possível, e o cliente deve se recusar a prosseguir se o servidor de autorização não anunciar suporte a PKCE. Emissor, novidade da revisão de julho: se o iss vier na resposta, o cliente deve compará-lo com o emissor registrado antes de usar o código, a defesa contra o ataque de mix-up.

Menor privilégio também é mecânica: se uma operação exige mais escopo, o servidor responde 403 com insufficient_scope, e o cliente refaz a autorização pedindo a união do que tinha com o que falta (o step-up).

No registro do cliente, o Dynamic Client Registration foi depreciado em favor dos Client ID Metadata Documents, em que o client_id é uma URL HTTPS que aponta para os metadados do cliente. Isso dispensa registros prévios, mas faz o servidor de autorização buscar URLs de clientes desconhecidos, o que o guia de segurança trata como risco de SSRF.

Em empresa, a extensão Enterprise-Managed Authorization troca o consentimento pessoa a pessoa pelo provedor de identidade corporativo: o cliente obtém dele um ID-JAG, emitido só depois de avaliada a política, e o troca pelo token de acesso; a revogação acontece num lugar só.

4. Versionamento: a versão viaja em cada requisição

Até a revisão 2025-11-25, versão e capacidades eram negociadas uma vez, no handshake initialize, e presas à sessão. A 2026-07-28 removeu o handshake e as sessões: cada requisição leva no _meta a versão e as capacidades do cliente. No HTTP, a versão também vai no cabeçalho MCP-Protocol-Version, e a revisão passou a exigir Mcp-Method e, nas chamadas a ferramentas, recursos e prompts, Mcp-Name.

O pedido de pagamento da abertura fica assim (exemplo ilustrativo, montado com os campos da especificação):

POST /mcp HTTP/1.1
Host: financeiro.exemplo.com
Accept: application/json, text/event-stream
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: emitir_pagamento
Authorization: Bearer <token emitido para https://financeiro.exemplo.com/mcp>

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "emitir_pagamento",
            "arguments": {"fornecedor": "F-102", "valor": 250000},
            "_meta": {"io.modelcontextprotocol/protocolVersion": "2026-07-28",
                      "io.modelcontextprotocol/clientCapabilities": {},
                      "traceparent": "00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01"}}}

Se o servidor não implementa a versão pedida, deve responder com UnsupportedProtocolVersionError listando as que suporta, e o cliente repete com uma versão em comum ou mostra o erro ao usuário. Todo servidor deve implementar server/discover, que devolve versões, capacidades e identidade; o cliente pode usá-lo, mas não é obrigado. Se só um lado conhece uma extensão, quem a conhece volta ao núcleo ou rejeita a requisição com erro, sem presumir que o outro a entende.

Sem sessão, qualquer instância atende qualquer requisição; o estado que atravessa chamadas vira um identificador passado como argumento, e o servidor deve amarrá-lo ao usuário do token para que não seja sequestrado. Na migração, cliente moderno com servidor legado falha, a menos que um lado implemente as duas eras.

A depreciação ganhou uma política: três estados (ativo, depreciado, removido) e uma janela mínima de doze meses. Roots, Sampling, Logging e o registro dinâmico de clientes, depreciados na 2026-07-28, só podem sair numa revisão lançada a partir de 28 de julho de 2027. E versão do protocolo não é versão da ferramenta: o protocolo continua em 2026-07-28 enquanto emitir_pagamento ganha um campo moeda obrigatório e quebra quem não o envia. Schema de ferramenta pede versionamento e teste de contrato próprios.

5. Observabilidade: rastrear sem sessão

Quando um agente com ferramentas erra, um pagamento sai; observabilidade vira requisito de segurança. Entre a pessoa e o banco há host, agente, cliente, gateway, servidor e API, cada um com seu log. Sem um identificador causal comum, reconstruir uma decisão vira arqueologia.

A revisão 2026-07-28 trouxe isso para a especificação: as chaves traceparent, tracestate e baggage ficam reservadas no _meta para o contexto do OpenTelemetry, nos formatos Trace Context e Baggage do W3C (2021, 2024); é o campo do exemplo acima. A sessão dizia "estas requisições compartilham estado"; o trace diz "estas operações pertencem à mesma cadeia causal". O MCP abriu mão da primeira e mantém a segunda.

As métricas ainda não estão maduras. As convenções semânticas do OpenTelemetry para MCP definem spans e as métricas mcp.client.operation.duration e mcp.server.operation.duration, mas estão em status Development, mudaram-se para um repositório próprio de IA generativa e ainda descrevem initialize e mcp.session.id, que a revisão de julho removeu. Dá para usar, contando com mudanças.

Telemetria também vaza: nessas convenções, argumentos e resultados de ferramentas são opt-in e vêm com o aviso de que podem conter informação sensível. E logs e traces mostram eventos e causalidade, mas não substituem a trilha de auditoria, que responde quem agiu, em nome de quem, sob qual política e com qual resultado.

6. O gateway: onde a política encontra a chamada

O OAuth responde se uma identidade pode acessar um recurso, não se o agente pode pagar 250 mil reais agora. Com valor 50 ou 250000, emitir_pagamento é a mesma ferramenta, com riscos muito diferentes. A decisão precisa olhar argumentos e contexto, como na arquitetura Zero Trust do NIST (SP 800-207): nenhuma confiança implícita pela posição na rede, e acesso concedido por um ponto de decisão de política (PDP) e um ponto de aplicação de política (PEP).

Um gateway MCP é o candidato natural a PEP, e a especificação ajudou: o transporte HTTP espelha campos do corpo em cabeçalhos "para que intermediários (balanceadores de carga, gateways, ferramentas de observabilidade) possam rotear e inspecionar requisições sem interpretar o corpo". O servidor deve rejeitar a requisição cujo cabeçalho não bate com o corpo; do contrário, quem roteia e quem executa teriam duas fontes de verdade.

Mas gateway como PEP é padrão de arquitetura, não papel normativo. O MCP tem um grupo de trabalho de Interceptors, cujo estatuto descreve um "cenário espalhado de sidecars, proxies e gateways" que não interoperam, e uma extensão experimental não oficial. Enquanto isso não vira padrão, o seu gateway deve verificar a audiência do token e aceitar só servidores aprovados (Narajala e Habler, 2026), limitar a taxa por agente, permitir, negar ou pedir aprovação conforme os argumentos e tratar o timeout como orçamento da cadeia. E deve preservar a semântica do erro: timeout pede nova tentativa, insufficient_scope pede step-up, versão não suportada pede renegociação, política negada pede que o agente pare. Srinivasan (2026) põe as duas coisas, orçamento de timeout e semântica de erro, entre as primitivas que faltam ao protocolo.

7. Servidor MCP continua sendo software

A pilha inteira pressupõe que o servidor do outro lado merece confiança. Hasan et al. (2026) analisaram 1.899 servidores MCP de código aberto: 7,2% tinham vulnerabilidades gerais e 5,5% exibiam tool poisoning, o envenenamento específico do MCP. Os autores defendem varredura automática de segurança nos registros de servidores.

Hou et al. (2026b) dividem o ciclo de vida do servidor em quatro fases, catalogam dezesseis cenários de ameaça e propõem salvaguardas para cada fase. Um registro interno com varredura, revisão de política e versão aprovada faz parte da autorização, porque a descrição e o schema da ferramenta são entrada para o modelo, que confia cegamente nas descrições (Guo et al., 2026), e podem mudar depois da aprovação (Narajala e Habler, 2026).

Uma posição, para fechar

Na minha leitura, a 2026-07-28 é a revisão mais voltada à produção que o MCP já teve. Ela fez do servidor remoto um workload HTTP comum, pôs versão e trace em cada requisição, fechou brechas do OAuth e deu à depreciação um calendário. Quem ainda repassa token está fora da especificação; quem depende de sessão está preso a uma revisão que já não é a vigente.

Mas a identidade do agente ainda é prioridade de roadmap, a política sobre argumentos não existe no núcleo (e talvez não deva existir) e a convenção de telemetria segue em desenvolvimento. Essas partes ficam por conta de quem implanta.

Um teste antes de declarar uma implantação pronta: reconstruir cinco incidentes só com o que você registra. Um arquivo apagado indevidamente: quem, em nome de quem, sob qual política, em qual trace? Um token no servidor errado: qual audiência, qual emissor? Falhas após uma atualização: qual versão? Uma ferramenta dez vezes mais lenta: em qual span? Um servidor malicioso: quem aprovou, e quando? Se algum fica sem resposta, o que está em produção ainda é o protótipo.

Referências

1. Model Context Protocol. Specification, revision 2026-07-28; Key Changes; Versioning and Compatibility; Discovery; Streamable HTTP; Authorization; Client Registration; Authorization Security Considerations; Deprecated Features. Model Context Protocol a Series of LF Projects, LLC, 2026. especificação · changelog · versioning · discover · streamable HTTP · authorization · client registration · security considerations · deprecated. Acesso em 16 out. 2026.
2. Model Context Protocol. Security Best Practices (2026-07-28). modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices. Acesso em 16 out. 2026.
3. Model Context Protocol. Extensions Overview; Enterprise-Managed Authorization; OAuth Client Credentials. extensions · enterprise-managed authorization · client credentials. Acesso em 16 out. 2026.
4. Model Context Protocol. Roadmap (atualizado em 22 ago. 2026); Feature Lifecycle and Deprecation Policy (SEP-2596); Interceptors Charter; SEP-414: Document OpenTelemetry Trace Context Propagation Conventions (Cole, A., 2025, status Final). roadmap · feature lifecycle · interceptors · experimental-ext-interceptors · SEP-414. Acesso em 16 out. 2026.
5. OpenTelemetry. Semantic conventions for Model Context Protocol (MCP). Status: Development. github.com/open-telemetry/semantic-conventions-genai (a página opentelemetry.io/docs/specs/semconv/gen-ai/mcp/, semconv 1.44.0, indica a mudança de repositório). Acesso em 16 out. 2026.
6. Kanzhelev, S.; McLean, M.; Reitbauer, A. et al. (eds.). Trace Context. W3C Recommendation, 23 nov. 2021. www.w3.org/TR/trace-context/; Propagation format for distributed context: Baggage. W3C Candidate Recommendation Snapshot, 30 maio 2024. www.w3.org/TR/baggage/. Acesso em 16 out. 2026.
7. Hardt, D.; Parecki, A.; Lodderstedt, T. The OAuth 2.1 Authorization Framework. Internet-Draft draft-ietf-oauth-v2-1-16, IETF, 2026 (a revisão 2026-07-28 do MCP referencia a versão -13). datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/. Acesso em 16 out. 2026.
8. Jones, M. B.; Hunt, P.; Parecki, A. OAuth 2.0 Protected Resource Metadata. RFC 9728, IETF, 2025. doi.org/10.17487/RFC9728
9. Campbell, B.; Bradley, J.; Tschofenig, H. Resource Indicators for OAuth 2.0. RFC 8707, IETF, 2020. doi.org/10.17487/RFC8707
10. Meyer zu Selhausen, K.; Fett, D. OAuth 2.0 Authorization Server Issuer Identification. RFC 9207, IETF, 2022. doi.org/10.17487/RFC9207
11. Jones, M.; Sakimura, N.; Bradley, J. OAuth 2.0 Authorization Server Metadata. RFC 8414, IETF, 2018. doi.org/10.17487/RFC8414
12. Jones, M.; Nadalin, A.; Campbell, B. (ed.); Bradley, J.; Mortimore, C. OAuth 2.0 Token Exchange. RFC 8693, IETF, 2020. doi.org/10.17487/RFC8693
13. Rose, S.; Borchert, O.; Mitchell, S.; Connelly, S. Zero Trust Architecture. NIST Special Publication 800-207, 2020. doi.org/10.6028/NIST.SP.800-207
14. Hardy, N. The Confused Deputy (or why capabilities might have been invented). ACM SIGOPS Operating Systems Review, v. 22, n. 4, p. 36–38, 1988. doi.org/10.1145/54289.871709
15. Srinivasan, V. Bridging Protocol and Production: Design Patterns for Deploying AI Agents with Model Context Protocol. arXiv:2603.13417, 2026. arxiv.org/abs/2603.13417
16. Hou, X.; Wang, S.; Zhang, Y. et al. SMCP: Secure Model Context Protocol. arXiv:2602.01129, 2026a. arxiv.org/abs/2602.01129
17. Hou, X.; Zhao, Y.; Wang, S.; Wang, H. Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions. ACM Transactions on Software Engineering and Methodology, v. 35, n. 10, p. 1–37, 2026b. doi.org/10.1145/3796519 (arXiv:2503.23278)
18. Hasan, M. M.; Li, H.; Fallahzadeh, E. et al. Model Context Protocol (MCP) at First Glance: Studying the Security and Maintainability of MCP Servers. ACM Transactions on Software Engineering and Methodology, 2026. doi.org/10.1145/3814959 (arXiv:2506.13538)
19. Guo, Y.; Liu, P.; Ma, W. et al. MCPXkit: The Unified Toolkit for Analyzing Model Context Protocol Security. IEEE Transactions on Dependable and Secure Computing, v. 23, n. 5, p. 9796–9811, 2026. doi.org/10.1109/TDSC.2026.3695553 (arXiv:2508.12538)
20. Narajala, V. S.; Habler, I. Enterprise-Grade Security for the Model Context Protocol (MCP): Frameworks and Mitigation Strategies. 2026 IEEE 5th International Conference on AI in Cybersecurity (ICAIC), p. 1–8, 2026. doi.org/10.1109/ICAIC67076.2026.11395723 (arXiv:2504.08623)