OAuth na Camada MCP: Como Resolvemos a Gestão de Tokens Empresariais para Agentes de IA

Uma análise detalhada da arquitetura de autenticação dentro do Gateway MCP da TrueFoundry — três planos, dois fluxos OAuth, um cofre de credenciais — contada pela perspectiva de um cliente que o está implementando em produção.

Uma manhã de segunda-feira na Northwind. Às 8h47 de uma segunda-feira, o engenheiro de plantão da Northwind Logistics — uma plataforma de cadeia de suprimentos fictícia, mas infelizmente plausível, com 50 engenheiros — recebe um alerta no Slack. Seu assistente de IA interno, Cargo Copilot, está retornando erros 401 para cada chamada de ferramenta Jira e GitHub. A causa raiz é o laptop de um desenvolvedor, perdido no aeroporto durante o fim de semana. A TI revogou a sessão SSO do laptop. Mas o laptop também continha tokens OAuth para GitHub, Slack, Jira e um serviço de análise interno, cada um copiado nas configurações do editor e nos dotfiles do desenvolvedor. A segurança não pode dizer com confiança quais escopos foram expostos, em quais outras máquinas esses tokens também foram espelhados (porque os desenvolvedores se ajudam) ou como revogá-los todos sem atrapalhar a manhã de todos.

O incidente da Northwind não é incomum. É assim que o gerenciamento de credenciais se parece na maioria das empresas seis meses após a adoção entusiástica do MCP. O restante desta publicação é a história arquitetônica de como a Northwind — e outros clientes da TrueFoundry — param de reproduzir este incidente.

1. O Problema da Proliferação de Credenciais: Como 50 Desenvolvedores × 8 Servidores MCP Realmente Se Parecem

A Northwind tem aproximadamente cinquenta engenheiros usando ativamente IDEs compatíveis com MCP em relação a oito servidores — GitHub, Slack, Google Workspace, Jira, um serviço de análise interno, uma API de Logística interna, Zendesk e um serviço proprietário de planejamento de rotas. Isso representa quatrocentas conexões ativas pela aritmética óbvia e, na prática, substancialmente mais posicionamentos de credenciais quando se contam entradas de chaveiro, configurações de editor, arquivos de ambiente de shell, variáveis de CI e as cópias que as pessoas fazem ao integrar um colega de equipe.

O raio de impacto de uma estação de trabalho comprometida não é um token. É um token multiplicado pelos escopos anexados a esse provedor, a vida útil do token (muitas vezes 90 dias ou mais para tokens de acesso pessoal), o número de máquinas que o espelharam e a ausência de revogação centralizada. Se um token OAuth do Slack permite a leitura do histórico do canal e um token GitHub co-localizado permite a leitura do repositório, uma única exfiltração se torna um incidente entre sistemas antes que a equipe de segurança tenha a chance de responder. As credenciais MCP locais também são operacionalmente invisíveis: nenhum rastro de auditoria unificado, nenhuma rotação forçada, nenhuma verificação de política antes da execução de uma ferramenta, nenhuma maneira rápida de responder quem pode chamar o quê.

O padrão de gateway preenche a lacuna. Os desenvolvedores se autenticam uma vez no gateway, e o gateway gerencia a autenticação downstream de acordo com o modelo configurado de cada servidor — que é exatamente o design descrito em Visão geral do Gateway MCP da TrueFoundry e nas documentos de Autenticação e Segurança. O benefício não é apenas a consolidação. É que a autenticação se torna uma propriedade da infraestrutura, e não uma propriedade de cada laptop na empresa.

2. A Arquitetura de Autenticação de Três Planos: Entrada, Controle de Acesso e Saída

A primeira decisão de design é separar três planos que as configurações de desenvolvedores locais rotineiramente confundem. Os documentos de Autenticação e Segurança da TrueFoundry descrevem isso como um sistema de três partes: autenticação de entrada, controle de acesso, e autenticação de saída. A documentação é explícita ao afirmar que as camadas de entrada e saída são independentes, o que é a grande vantagem arquitetural.

• Autenticação de entrada. Quem está chamando o gateway? O TrueFoundry suporta quatro métodos: Chave de API TrueFoundry (PAT), Token de Conta Virtual, Token de Provedor de Identidade (um JWT Okta/Auth0/Azure AD validado através de um Provedor de Identidade) e OAuth TrueFoundry (usado por IDEs como Cursor e VS Code).
• Controle de acesso. O que a identidade resolvida pode fazer? Cada servidor MCP tem Colaboradores — usuários, equipes ou contas virtuais — com permissões baseadas em função. O escopo no nível da ferramenta é alcançado combinando ferramentas de vários servidores MCP em um Servidor MCP Virtual, que expõe apenas um subconjunto selecionado.
• Autenticação de saída. Como o gateway alcança cada servidor downstream? Sete métodos são suportados: OAuth2 (Código de Autorização), OAuth2 (Credenciais de Cliente), Chave de API (Compartilhada), Chave de API (Individual), Sem Autenticação, Passthrough de Token e Encaminhamento de Token via x-tfy-mcp-headers.

‍

O princípio de design é simples: a credencial usada para alcançar o gateway nunca é a credencial que alcança a ferramenta downstream. A rotação de entrada não afeta nenhum estado OAuth do provedor. Um servidor MCP do GitHub pode usar OAuth por usuário enquanto o serviço de análise interno usa Credenciais de Cliente — no mesmo agente, no mesmo fluxo de solicitação. O gateway é tanto o ponto de aplicação de políticas quanto o intermediário de credenciais.

3. 2LO vs 3LO: Escolhendo o Tipo de Concessão OAuth Correto para Cada Servidor MCP

Na abreviação empresarial, 2LO e 3LO referem-se a dois tipos de concessão de RFC 6749 (OAuth 2.0), mapeado para a forma como os utilizadores finais participam.

OAuth de Duas Pernas (2LO) utiliza o Credenciais de Cliente concessão. O gateway detém um client_id e client_secret, envia grant_type=client_credentials para o endpoint de token do provedor, recebe um de curta duração access_token, e utiliza esse token em cada requisição para o servidor MCP. Sem navegador, sem consentimento do utilizador. É a escolha certa para integrações servidor-a-servidor: APIs de análise internas, microsserviços de backend, serviços de dados internos.

OAuth de Três Pernas (3LO) utiliza o Código de Autorização concessão. Cada utilizador final é redirecionado para o provedor (GitHub, Slack, Google) para autorizar o acesso aos seus recursos específicos. O gateway armazena um por utilizador refresh_token, mantém um mapeamento encriptado de user_id → {access_token, expires_at, refresh_token, scopes, provider_metadata}, e rotaciona o token de acesso automaticamente.

Como a Northwind escolheu

Os oito servidores MCP da Northwind dividiram-se aproximadamente ao meio. GitHub, Slack, Jira, Google Workspace e Zendesk são todas ferramentas por usuário — o valor de "executar isto como Alice" supera a sobrecarga operacional de um token por usuário. Esses usam 3LO. O serviço interno de análise, a API de Logística e o serviço de planejamento de rotas expõem dados de toda a empresa; OAuth por usuário não faz sentido, e uma única concessão de Credenciais de Cliente compartilhada é mais simples e fácil de auditar. Esses usam 2LO.

Como é o modelo de configuração

Nota sobre esta visualização de configuração

A TrueFoundry registra servidores MCP através da UI (Configurações → Servidores MCP → Adicionar Servidor MCP) em vez de através de um arquivo YAML gerenciado pelo cliente, embora a configuração também possa ser aplicada declarativamente via tfy apply. O YAML abaixo mostra o modelo de configuração por servidor — os mesmos campos que você preenche na UI — usando o esquema verificado da TrueFoundry (provider-account/mcp-server-group com aninhado integrations).

# Northwind's backend-group MCP Server Group: two MCP servers, one per OAuth flow.
# Schema matches TrueFoundry's provider-account / integrations pattern (tfy apply).

name: backend-group
type: provider-account/mcp-server-group
collaborators:
  - subject: team:platform-engineering
    role_id: mcp-server-manager
  - subject: team:site-reliability
    role_id: mcp-server-manager
  - subject: virtualaccount:cargo-copilot-runtime
    role_id: mcp-server-manager

integrations:

  # ---- 3LO (Authorization Code): per-user OAuth on GitHub ----
  - name: github
    type: integration/mcp-server/remote
    description: GitHub MCP server using per-user OAuth Authorization Code flow.
    url: https://github-mcp.example.com/mcp
    transport: streamable-http
    authorized_subjects:
      - team:platform-engineering
      - team:site-reliability
      - virtualaccount:cargo-copilot-runtime
    auth_data:
      type: oauth2
      grant_type: authorization_code
      authorization_url: https://github.com/login/oauth/authorize
      token_url: https://github.com/login/oauth/access_token
      client_id: tfy-secret://northwind:github-oauth:client_id
      client_secret: tfy-secret://northwind:github-oauth:client_secret
      scopes:
        - repo
        - read:org
      jwt_source: access_token
      code_challenge_methods_supported:
        - S256

  # ---- 2LO (Client Credentials): shared service identity ----
  - name: internal-analytics
    type: integration/mcp-server/remote
    description: Internal analytics MCP server using OAuth2 Client Credentials.
    url: https://analytics-mcp.internal.example.com/mcp
    transport: streamable-http
    authorized_subjects:
      - team:platform-engineering
      - team:site-reliability
    auth_data:
      type: oauth2
      grant_type: client_credentials
      token_url: https://northwind.okta.com/oauth2/default/v1/token
      client_id: tfy-secret://northwind:analytics-oauth:client_id
      client_secret: tfy-secret://northwind:analytics-oauth:client_secret
      scopes:
        - analytics:read
      jwt_source: access_token

O comando para aplicar o YAML acima é:

tfy apply -f backend-group.yaml --dry-run --show-diff

Três coisas a observar. Primeiro, tfy-secret:// é o esquema de referência FQN canônico que a TrueFoundry usa para segredos armazenados em um grupo de segredos da TrueFoundry, com o formato separado por dois pontos tfy-secret://<tenant>:<secret-group>:<secret-key> documentado no Guia de Variáveis de Ambiente e Segredos. O valor reside no seu gerenciador de segredos (AWS SSM, GCP Secret Manager, HashiCorp Vault, Azure Key Vault); a TrueFoundry resolve o FQN em tempo de execução, portanto, o arquivo acima é seguro em um repositório Git. Segundo, sujeitos_autorizados é a lista RBAC por servidor — uma mistura de equipes e contas virtuais — o que torna possível para o mesmo servidor MCP atender desenvolvedores humanos (cujos PATs se resolvem em associação a equipes) e tarefas agendadas de contas de serviço (cujos Tokens de Conta Virtual mapeiam para virtualaccount: sujeitos) sem desvio de configuração. Terceiro, a entrada 3LO define code_challenge_methods_supported: [S256] — PKCE é recomendado para todo cliente de Código de Autorização hoje e obrigatório na especificação MCP mais recente de 2025-11-25.

No lado do cliente, o agente nunca enumera modos de autenticação. Ele disca uma URL de gateway, apresenta uma credencial de entrada, e o gateway injeta a credencial de saída correta por servidor:

from fastmcp import Client
from fastmcp.client.transports import StreamableHttpTransport

# Real URL pattern from the TrueFoundry docs.
transport = StreamableHttpTransport(
    url="https://llm-gateway.truefoundry.com/mcp-server/backend-group/github/server",
    headers={"Authorization": f"Bearer {user_token}"},
)

async with Client(transport) as client:
    result = await client.call_tool(
        "search_issues",
        {"query": "repo:northwind/logistics-core is:open label:critical"},
    )

4. Gerenciamento do Ciclo de Vida do Token: Atualização Proativa e Acesso Concorrente

A correção do OAuth não se trata apenas de obter tokens. Trata-se de operá-los com segurança sob carga concorrente. O design ingênuo atualiza quando o provedor retorna 401, ou quando agora ≥ expires_at. Esse design funciona em demonstrações e falha na primeira segunda-feira em que encontra a realidade.

Reencene o incidente Northwind com atualização ingênua: às 8h47 de segunda-feira, cinquenta engenheiros ficam online, cada trabalhador descobre independentemente o mesmo token GitHub expirado, cinquenta chamadas paralelas POST /token atingem o GitHub do mesmo gateway, e o GitHub limita a taxa de todas elas. O Cargo Copilot retorna 401s para todos até que a fila seja esvaziada.

O padrão que se sustenta em produção tem dois ingredientes: atualizar proativamente a 80% do TTL, e serializar a atualização por (usuário, servidor) com um bloqueio distribuído.

def get_token(user_id, server_id):
    token = cache.get(user_id, server_id)
    if now() < token.issued_at + 0.8 * token.expires_in:
        return token

    # Crossed the 80% threshold. Serialize refresh so 50 workers
    # do not all hit the provider token endpoint at once.
    with distributed_lock(user_id, server_id):
        token = cache.get(user_id, server_id)   # re-read under lock
        if now() < token.issued_at + 0.8 * token.expires_in:
            return token   # someone else already refreshed

        new = provider.refresh(token.refresh_token)
        vault.put_atomic(user_id, server_id, new)   # access + refresh together
        cache.set(user_id, server_id, new)
        return new

Atualizar a 80% do TTL deixa margem para desvio de relógio, novas tentativas, endpoints de token de provedor lentos e requisições já em andamento. O bloqueio por (usuário, servidor) evita uma manada trovejante contra o provedor. A leitura com verificação dupla dentro do bloqueio não é cosmética: ela permite que a primeira requisição realize a atualização enquanto as demais reutilizam o token recém-escrito.

Duas sutilezas importam em escala. Primeiro, para integrações de Credenciais de Cliente, a chave de cache é (server_id, provider_account); para integrações de Código de Autorização, a chave deve incluir user_id. Segundo, provedores que rotacionam tokens de atualização a cada atualização — Google e Microsoft o fazem, dependendo da configuração — exigem que a escrita seja atômica. Se o novo access_token está comprometido antes do novo refresh_token, uma falha deixa o usuário bloqueado com um refresh token antigo invalidado e uma reautenticação forçada.

5. O Fluxo de Autenticação Dupla: Um Diagrama de Sequência Completo

Com os planos separados e o caminho de atualização definido, uma requisição MCP de ponta a ponta através do gateway tem uma forma precisa. Rastreie uma chamada do Cargo Copilot — "summarize the open critical-severity issues in repo northwind/logistics-core" — do agente ao GitHub e vice-versa:

‍

Três propriedades deste fluxo merecem destaque. O agente nunca recebe o token de acesso do GitHub; apenas o gateway o detém. O servidor MCP nunca vê a credencial TrueFoundry de entrada da Northwind, a menos que o Token Passthrough seja explicitamente configurado (mais sobre isso na §7). E a equipe de segurança da Northwind obtém um único caminho de requisição governado com identidade, autorização e auditoria registrados em um só lugar — a mesma propriedade que lhes permitiria responder à pergunta de segunda-feira de manhã, "quais escopos estavam naquele laptop?", em menos de um minuto.

A especificação de autorização MCP reforça uma parte deste cenário: tokens de acesso bearer devem ser enviados no cabeçalho de requisição Authorization e nunca em uma string de consulta URI. Essa norma é importante precisamente porque mantém os tokens fora dos logs de acesso, histórico do navegador e rastreamentos de proxy.

6. Integração do Cofre de Credenciais: Por que Segredos Brutos Nunca Tocam a Memória da Aplicação

Um gateway de produção não deve tratar os refresh tokens OAuth como linhas de aplicação comuns. Segredos de cliente e refresh tokens são chaves de longa duração para o reino — vazar um refresh token do Slack é, para a maioria dos propósitos, equivalente a vazar o workspace do Slack.

O padrão padrão é a criptografia de envelope. O gateway gera uma chave de criptografia de dados (DEK) aleatória para cada registro de token, criptografa o segredo OAuth com essa DEK, criptografa a DEK com uma chave mestra no KMS ou em um gerenciador de segredos, e armazena a DEK criptografada junto com o texto cifrado. Na leitura, o gateway pede ao cofre para descriptografar apenas a DEK, então descriptografa o token em um caminho de código de escopo restrito que evita o registro ou a serialização de texto simples.

Em implantações mais rigorosas, a própria troca de tokens pode ser empurrada para um sidecar ou uma operação de trânsito de cofre, para que o código da aplicação nunca receba material client_secret bruto. Mesmo com a criptografia de envelope padrão, o raio de explosão muda substancialmente: um dump de banco de dados sozinho é insuficiente (as DEKs não são armazenadas descriptografadas), e um dump de memória de um worker de requisição geral é muito menos provável de conter material de credencial amplo (apenas as chaves recentemente solicitadas são descriptografadas, e apenas pela duração da requisição).

A implantação da Northwind usa o AWS KMS como armazenamento de chave mestra e o armazenamento de segredos TrueFoundry para o material criptografado. O gateway nunca lê um client_secret de provedor diretamente; ele lê um FQN de segredo TrueFoundry, busca o texto cifrado e pede ao KMS para desembrulhar. O trabalho específico da implantação que resta — política de rotação de chaves KMS, retenção de auditoria, runbooks operacionais — é responsabilidade de cada empresa que executa o gateway, e merece uma revisão dedicada.

7. Token Passthrough vs. Token Forwarding: Casos Limite e Quando Usar Cada Um

Dois padrões soam semelhantes e têm implicações de segurança muito diferentes. Vale a pena distingui-los cuidadosamente porque o uso indevido de qualquer um deles anula a maior parte do valor do gateway.

O Token Passthrough é apropriado para servidores MCP internos que validam o mesmo token de identidade corporativa que o gateway já validou na entrada. A API de Logística da Northwind é um exemplo: o gateway e a API confiam no tenant Okta da empresa, então passar o JWT do Okta mantém a identidade do chamador intacta de ponta a ponta. O risco é a confusão de público do token: um token emitido para o gateway não deve ser automaticamente válido para todos os servidores MCP. RFC 8707 (Resource Indicators) existe precisamente para vincular tokens a um recurso pretendido, e a especificação de autorização MCP agora exige que os clientes incluam um recurso parâmetro e que os servidores validem que os tokens apresentados foram emitidos para eles.

O Encaminhamento de Token funciona de forma diferente. Da TrueFoundry x-tfy-mcp-headers cabeçalho transporta um JSON serializado indexado pelo identificador do servidor MCP remoto em <group>/<server> formato. Aqui está o formato na íntegra da documentação do Servidor MCP Virtual:

import json
from fastmcp import Client
from fastmcp.client.transports import StreamableHttpTransport

extra_headers = json.dumps({
    # Custom auth for the backend-group/sentry MCP server backing this
    # virtual server. Overrides whatever outbound auth was configured.
    "backend-group/sentry": {"Authorization": "Bearer your-sentry-token"},
})

transport = StreamableHttpTransport(
    url="https://llm-gateway.truefoundry.com/mcp-server/backend-group/restricted-sentry/server",
    headers={
        "Authorization": f"Bearer {tfy_token}",   # inbound auth (gateway)
        "x-tfy-mcp-headers": extra_headers,        # outbound override
    },
)

Trate o Encaminhamento de Token como uma saída de emergência, não como um padrão. O valor do gateway reside precisamente na gestão de tokens que ele ignora.

8. Benchmarks de Latência: O Que a Gestão de Tokens Adiciona a Cada Chamada de Ferramenta

Um gateway adiciona trabalho antes da chamada MCP a jusante: validação de autenticação de entrada, pesquisa de política, pesquisa de token e, ocasionalmente, uma atualização. Numa implementação saudável, o caminho comum é um acerto de cache — os metadados do token são válidos, a referência do token encriptado está pronta na memória.

Envelopes de cenário

Combinando os custos dos componentes acima, o gateway adiciona aproximadamente:

Duas conclusões. Primeiro, o caminho comum é um acerto de cache, e em milissegundos de um dígito, é impercetível face à chamada LLM circundante (tipicamente centenas de milissegundos a segundos) e ao servidor MCP a jusante (tipicamente dezenas a centenas de milissegundos). Segundo, o caminho de cache-miss-mais-atualização é raro, mas caro o suficiente para ser relevante quando se acumula sob carga — que é exatamente por isso que o §4 especifica a atualização proativa a 80% do TTL com um bloqueio por (utilizador, servidor). Com a atualização proativa, os utilizadores reais quase nunca veem a latência de atualização no caminho da requisição; o gateway já pré-buscou um novo token.

Cada equipa deve ainda instrumentar cabeçalhos de tempo de servidor, duração do endpoint de token, tempo de espera de bloqueio, tempo de desencriptação do vault e latência MCP a jusante separadamente. O objetivo é provar que a gestão de tokens não é o custo dominante na chamada de ferramenta de ponta a ponta do agente — os envelopes acima sugerem que quase nunca é, mas deve verificar com a sua própria combinação de fornecedores.

A correção operacional para o caso de cache-miss é a atualização em segundo plano. Quando o gateway vê um token ultrapassar o limiar de 80%, ele atualiza no caminho da requisição uma vez, e depois agenda atualizações subsequentes antes que os utilizadores percebam. Para integrações de Credenciais de Cliente partilhadas de alto volume, isto quase elimina a latência de atualização visível para o utilizador. Para integrações de Código de Autorização por utilizador, o sistema pode priorizar utilizadores ativos e servidores MCP frequentemente utilizados.

Antes vs. depois: postura de segurança na Northwind

9. Perguntas Frequentes

O OAuth na camada MCP é obrigatório?

Não. A especificação de autorização MCP torna a autorização opcional, mas as implementações baseadas em HTTP que a suportam devem estar em conformidade com a especificação. Na prática, empresas com um parque de ferramentas não trivial devem centralizar a autenticação muito antes de considerarem isso estritamente obrigatório.

Todo servidor MCP deve usar 3LO?

Não. Use o Código de Autorização (3LO) quando o agente atua nos recursos de um usuário humano — Slack, GitHub, Gmail, ferramentas de CRM. Use Credenciais de Cliente (2LO) quando o servidor downstream autentica a aplicação ou gateway como ele próprio. Misturar ambos em um único Servidor MCP Virtual é normal e esperado.

Um gateway elimina as permissões do lado do provedor?

Não. Ele as complementa. Slack, GitHub, Google e APIs internas ainda impõem seus próprios escopos e permissões de recursos. O gateway adiciona uma camada de política mais abrangente e rápida por cima — nível de servidor, nível de ferramenta, nível de equipe — e uma trilha de auditoria uniforme em todos eles. [SEGSEGMENT 9] OAuth 2.0 ou OAuth 2.1?

O gateway TrueFoundry suporta os fluxos de concessão OAuth 2.0 que os provedores do mundo real suportam hoje: Código de Autorização (com PKCE), Credenciais de Cliente e tokens de atualização. A própria especificação de autorização MCP visa o OAuth 2.1, que é em grande parte o OAuth 2.0 mais as melhores práticas de segurança que já são consideradas obrigatórias em implantações modernas (PKCE em todo lugar, sem concessão implícita, sem concessão de senha). Para fins práticos, os dois são convergentes; seguimos as diretrizes do OAuth 2.1 onde ele aprimora o comportamento.

E a respeito da especificação MCP mais recente de 25/11/2025?

A revisão de novembro de 2025 adiciona PKCE obrigatório para todos os clientes, formaliza os Documentos de Metadados de ID de Cliente (CIMD) como o método preferencial de registro de cliente e introduz a autorização por etapas para consentimento incremental de escopo. Isso aprimora a segurança sem invalidar a arquitetura apresentada nesta publicação. Estamos acompanhando-os e implementando o suporte à medida que amadurecem no ecossistema.

Onde o TrueFoundry se encaixa?

O Gateway MCP TrueFoundry é uma implementação em produção desta arquitetura: um registro centralizado de servidores, autenticação de entrada configurável, controle de acesso, múltiplos modos de autenticação de saída e gerenciamento do ciclo de vida do token. Esta publicação descreve o design; a

documentação de Autenticação e Segurança é a referência operacional. Para os padrões de implementação abordados aqui, consulte também a documentação sobre Sobrescritas de Autenticação e Servidor MCP Virtual .

Dê o próximo passo

Se você é um líder de plataforma, segurança ou infraestrutura de IA que executa MCP em uma escala considerável, a ação de maior impacto é inventariar cada servidor MCP em uso ativo, mapear cada um para o modelo de autenticação de entrada, política e saída correto, e decidir onde a centralização realmente compensa. O mapeamento da Northwind levou duas tardes; a migração em si levou um único sprint. Teremos prazer em discutir esse exercício com sua equipe.

Leia a arquitetura: Autenticação e segurança do TrueFoundry MCP Gateway. Ou agende uma revisão de arquitetura de segurança empresarial com nossa equipe.

Leitura adicional

Todas as citações desta publicação estão vinculadas no texto. As referências abaixo reúnem os mesmos URLs para facilitar a impressão e como seguro contra links quebrados.

• Visão geral do TrueFoundry MCP Gateway. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-overview
• Autenticação e segurança do TrueFoundry MCP Gateway. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-gateway-auth-security
• Overrides de Autenticação TrueFoundry. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-server-auth-overrides
• Servidor MCP Virtual TrueFoundry. https://www.truefoundry.com/docs/ai-gateway/mcp/virtual-mcp-server
• TrueFoundry usando o MCP Gateway em seu agente. https://www.truefoundry.com/docs/ai-gateway/mcp/use-mcp-gateway-in-agent
• Provedores de Identidade TrueFoundry. https://www.truefoundry.com/docs/platform/identity-providers
• Gerenciador de Segredos TrueFoundry no AI Gateway. https://www.truefoundry.com/docs/ai-gateway/secret-manager-in-ai-gateway
• Variáveis de Ambiente e Segredos TrueFoundry (formato FQN tfy-secret://). https://www.truefoundry.com/docs/environment-variables-and-secrets
• TrueFoundry Usando tfy apply (padrão YAML de provider-account / integrações). https://docs.truefoundry.com/docs/using-tfy-apply
• Limites de Concorrência Okta (orientação sobre tempo de resposta da API). https://developer.okta.com/docs/reference/rl2-concurrency/
• WorkOS: RS256 vs HS256 (benchmarks de verificação JWT). https://workos.com/blog/rs256-vs-hs256-jwt-signing-algorithms
• Documentação do AWS KMS (orientação sobre latência de descriptografia). https://aws.amazon.com/kms/faqs/
• Especificação de autorização do Protocolo de Contexto de Modelo, 18-06-2025. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
• RFC 6749: A Estrutura de Autorização OAuth 2.0. https://datatracker.ietf.org/doc/html/rfc6749
• RFC 8707: Indicadores de Recurso para OAuth 2.0. https://datatracker.ietf.org/doc/rfc8707/
• RFC 9728: Metadados de Recurso Protegido OAuth 2.0. https://datatracker.ietf.org/doc/html/rfc9728/

Nota: A Northwind Logistics é uma empresa fictícia utilizada para contextualizar o design numa implementação concreta. O modelo de configuração mostrado em §3 é ilustrativo; os servidores MCP de produção são registados através da UI do TrueFoundry ou aplicados via tfy apply.

‍