Autenticação MCP Explicada: Identidade Inbound, Credenciais Outbound e Delegação

O token que identifica um solicitante para um gateway e a credencial usada para alcançar um serviço downstream resolvem problemas diferentes. Sistemas MCP seguros preservam essa distinção.

Autenticação não é um único salto

Uma requisição MCP pode cruzar vários limites de confiança antes que um sistema de negócios a veja. Uma pessoa ou serviço se autentica em uma aplicação. Um agente pode atuar como um principal de software separado. O cliente se autentica no MCP Gateway. O gateway decide se aquele solicitante pode usar um servidor ou ferramenta. Em seguida, o gateway se autentica no servidor MCP downstream, que pode chamar outro serviço autoritativo.

Usar a palavra “token” para cada credencial faz com que esses limites desapareçam. A credencial inbound responde quem está chamando o gateway. A política de acesso responde quais recursos do gateway essa identidade pode usar. A autenticação outbound determina de quem são as credenciais e permissões que o servidor downstream recebe. Essas respostas podem ser intencionalmente diferentes.

A documentação do TrueFoundry separa a arquitetura em autenticação inbound, controle de acesso e autenticação outbound. Essa separação é o ponto de partida correto para raciocinar sobre delegação, atribuição e o risco do agente confuso (confused deputy).

O gateway é intencionalmente dividido em três verificações. A autenticação inbound bem-sucedida identifica um solicitante, mas a política de acesso ainda seleciona as ferramentas permitidas e a autenticação outbound ainda determina o principal visto pelo servidor MCP.

A autenticação inbound resolve o solicitante do gateway

O TrueFoundry documenta vários métodos inbound: um personal access token para usuários com contas TrueFoundry, um token de conta virtual para chamadores serviço a serviço, um token de provedor de identidade para clientes ou serviços que usam o emissor JWT de uma organização e TrueFoundry OAuth para clientes IDE compatíveis.

Após validar a credencial, o gateway resolve uma identidade do TrueFoundry e aplica controle de acesso aos servidores MCP e ferramentas individuais. A identidade relevante pode ser um usuário, equipe ou conta virtual. A Identidade de Agente (Agent Identity), documentada em versão beta, adiciona um ator de agente registrado separado para chamadas originadas por agentes. Isso é diferente de uma conta virtual, que representa um serviço ou aplicação sem um humano por trás.

A resolução de identidade deve validar o emissor, a audiência, a assinatura, os limites de tempo e o mapeamento de claims usado para selecionar o sujeito. Um token assinado validamente para a audiência errada não é autoridade para o gateway. Os mapeamentos devem ser específicos o suficiente para que dois serviços não resolvam acidentalmente para a mesma identidade de agente.

A autenticação outbound seleciona o principal downstream

O gateway pode se autenticar em um servidor MCP usando código de autorização OAuth por usuário, credenciais de cliente OAuth em nível de aplicação, a configuração documentada de token-exchange/OBO do Okta, chaves de API compartilhadas ou individuais, nenhuma autenticação para serviços públicos, passthrough de token, encaminhamento de token ou AWS SigV4 para endpoints AWS suportados.

Esses modos codificam diferentes autoridades. O OAuth por usuário permite que cada pessoa autorize sua própria conta de terceiros. As credenciais de cliente representam a aplicação e geralmente expõem permissões de serviço compartilhadas. A troca de token (token exchange) ou OBO solicita a um sistema de identidade que emita um token downstream derivado da identidade do solicitante e direcionado a outra audiência. Uma chave de API compartilhada colapsa todos os solicitantes em um único principal upstream, mesmo se o gateway preservar a atribuição interna.

Escolher a integração mais fácil pode alterar silenciosamente o modelo de autorização. Se um servidor MCP do Gmail usa uma única credencial de serviço compartilhada, o upstream não vê a autoridade da caixa de correio pessoal de cada funcionário. Se um servidor MCP interno valida o token IdP da organização diretamente, o passthrough pode preservar o sujeito—mas apenas se o emissor, a audiência e os escopos forem aceitos deliberadamente.

O diagrama agrupa os modos pela semântica de autoridade em vez de rótulos de protocolo. Fluxos por usuário e OBO podem preservar o contexto do sujeito, enquanto credenciais de cliente e chaves compartilhadas representam a autoridade da aplicação, a menos que o serviço downstream aplique controles adicionais conscientes do sujeito.

Passthrough e encaminhamento não são sinônimos

Na terminologia documentada do TrueFoundry, o passthrough de token encaminha o mesmo token usado para a autenticação inbound para o servidor MCP. O servidor deve ser capaz de validar esse token do TrueFoundry ou do provedor de identidade. O encaminhamento de token carrega credenciais separadas e específicas do servidor fornecidas pelo cliente em cabeçalhos dedicados. A credencial outbound não é o bearer token inbound.

Essa distinção importa para auditoria (logging), redação, revogação e modelagem de ameaças. O passthrough preserva uma credencial através do limite do gateway e, portanto, requer a confiança correta na audiência downstream. O encaminhamento introduz outro segredo que o cliente deve obter e proteger. Nenhum dos dois prova automaticamente que uma API de negócios final viu a relação pretendida entre humano e agente.

A troca de token OAuth e o OBO fornecem um padrão diferente: o gateway ou a camada de identidade obtém um novo token específico de audiência representando autoridade delegada. Isso pode reduzir o reuso de bearer tokens e permitir que os sistemas downstream apliquem escopos projetados para seus recursos. As garantias exatas dependem do provedor de identidade, das claims, da validação e da aplicação downstream.

Modele os principais, não apenas os cabeçalhos

Previna o agente confuso (confused deputy)

Um gateway se torna um agente confuso quando possui ampla autoridade downstream e a utiliza para um solicitante que carece de permissão equivalente. A autenticação inbound pode ser perfeitamente válida enquanto a ação composta ainda é superautorizada. O gateway deve unir a identidade do solicitante, a identidade do agente, o servidor e a ferramenta solicitados, o modo de credencial outbound e o escopo downstream.

Para credenciais compartilhadas, o servidor MCP ou a aplicação subjacente deve receber contexto confiável suficiente para reaplicar a autorização consciente do sujeito, ou a ferramenta deve expor apenas recursos seguros para todos os solicitantes permitidos. Não confie no modelo para filtrar resultados após uma consulta ampla. Para credenciais por usuário, verifique se a autorização está vinculada ao sujeito pretendido e não pode ser substituída por outro usuário por meio de sobreposições (overrides).

Cada salto também deve preservar um identificador de correlação de auditoria sem copiar bearer tokens para os logs. Registre o modo de credencial, a identidade resolvida, o emissor, a audiência, a classe de escopo, a versão da política e os metadados da resposta downstream. Valores secretos pertencem a cofres protegidos, não a transcrições ou rastros (traces).

A cadeia carrega tanto um sujeito humano quanto um ator de software através da decisão do gateway. O modo outbound pode preservar, trocar ou colapsar esse contexto de identidade; o sistema downstream ainda executa a autorização final de recurso e ação.

Um exemplo prático: acesso ao CRM de suporte ao cliente

Um agente de suporte recebe uma solicitação de um funcionário autenticado. A aplicação envia o token do provedor de identidade do funcionário para o MCP Gateway e apresenta separadamente a identidade do agente registrada. A política do gateway permite que esse par usuário-agente chame a ferramenta de busca do CRM.

Assuma que a implantação use a configuração Okta OBO documentada do TrueFoundry. O gateway troca o token do usuário inbound por um token com audiência do CRM e escopo de leitura de casos. O CRM valida o novo token e aplica sua própria autorização em nível de linha. O agente pode recuperar os casos permitidos do funcionário, mas não pode modificá-los. Uma ferramenta de atualização separada exige um escopo downstream mais restrito e aprovação.

Se a implantação usar uma chave de API compartilhada, a arquitetura deve compensar. O serviço voltado ao CRM recebe um atributo de sujeito resolvido e confiável do gateway, valida-o e filtra os registros no lado do servidor. Se o serviço não puder impor o contexto do sujeito, a chave compartilhada é inadequada para dados com autorização específica do usuário.

Escolha a autenticação outbound pela semântica de autoridade

• Use autorização por usuário quando o recurso upstream for de propriedade ou permissão de cada pessoa.
• Use credenciais de cliente para recursos genuinamente de propriedade da aplicação, não como um atalho para contornar a autorização do usuário.
• Use troca de token ou OBO quando o downstream precisar de um token de usuário delegado e específico para a audiência.
• Use passthrough apenas quando o downstream confiar deliberadamente e validar o token inbound.
• Use encaminhamento quando o servidor MCP tiver um esquema de credencial separado e aceite o ônus resultante de manipulação de segredos no cliente.
• Trate servidores sem autenticação como capacidades públicas; não coloque dados sensíveis ou mutações atrás deles.

Testes de falha para a cadeia de autenticação

• Reproduza (replay) um token válido com a audiência, emissor, tenant ou sujeito mapeado errados.
• Mantenha o usuário constante e altere a identidade do agente; verifique se o alcance efetivo da ferramenta muda conforme o projetado.
• Mantenha o agente constante e altere o usuário; verifique se os dados downstream seguem o sujeito humano onde exigido.
• Substitua uma credencial individual por meio do override de autenticação de outro usuário.
• Revogue uma concessão do gateway e uma concessão OAuth upstream independentemente; verifique seus diferentes efeitos.
• Chame o servidor MCP fora do gateway; verifique se a política de rede e do servidor previnem uma violação quando exigido.
• Inspecione logs, traces, erros e o contexto do modelo para verificar se há vazamento de bearer tokens ou segredos encaminhados.

O ciclo de vida da credencial faz parte do caminho dos dados

O design de autenticação continua depois que um token é aceito. As credenciais expiram, renovam (refresh), rotacionam e são revogadas em diferentes sistemas. A documentação do TrueFoundry observa, por exemplo, que sua ação “Revocar todos os tokens” exclui credenciais armazenadas do AI Gateway, mas não revoga concessões no provedor OAuth upstream. Os operadores precisam de procedimentos separados para a credencial do gateway, a sessão do provedor de identidade, a autorização upstream e qualquer token downstream em cache.

Defina qual componente renova cada credencial, qual sujeito o token renovado representa e o que acontece quando a renovação falha no meio de uma tarefa do agente. Um fluxo de autorização pausado não deve recorrer silenciosamente a uma credencial de aplicação com acesso mais amplo. Quando o usuário reconecta uma conta, a nova concessão deve ser correlacionada com o sujeito e o servidor pretendidos antes que o agente continue.

A rotação cria outro limite de teste. Chaves de API compartilhadas podem precisar de um período de chave dupla; tokens OAuth por usuário podem ser invalidados independentemente; tokens OBO podem ser mantidos em cache até a expiração, enquanto o token inbound deve permanecer atualizado para re-troca. Armazene identificadores de modo de credencial e família de token em metadados operacionais protegidos para que os encarregados da resposta possam encontrar chamadas afetadas sem expor segredos.

A revogação deve ser verificada de fora para dentro. Remova o colaborador do gateway, revogue a concessão upstream, desative a conta downstream e teste cada efeito separadamente. Um procedimento completo de incidente sabe qual ação interrompe novas chamadas ao gateway, qual invalida o acesso direto e qual apenas exclui uma cópia local.

A manipulação de tokens também deve estar ausente do contexto visível ao modelo. Agentes podem raciocinar sobre rótulos de identidade estáveis, resultados de autorização e instruções de reconexão sem receber material do tipo bearer. Os erros retornados pelos provedores devem ser normalizados para que a saída de depuração não vaze cabeçalhos, refresh tokens, client secrets ou componentes de requisição assinados na transcrição.

A regra operacional

A autenticação MCP segura começa nomeando cada principal e salto. Identidade inbound, acesso ao gateway, credencial outbound e autorização de negócios são controles relacionados, mas não intercambiáveis. O design mais seguro torna explícita qualquer alteração de principal ou audiência.

O TrueFoundry MCP Gateway fornece mecanismos documentados para cada camada voltada ao gateway, e a Identidade de Agente—documentada como beta no mapa de disponibilidade de governança—pode distinguir o ator de software do sujeito humano. A aplicação downstream ainda é proprietária de sua autorização de domínio e a organização ainda é responsável pela minimização de credenciais. Esse limite não é uma limitação na explicação; é o que torna o modelo de segurança testável.

Referências

1. TrueFoundry — MCP Gateway Authentication and Security.
2. TrueFoundry — Agent Identity.
3. TrueFoundry — MCP Gateway Overview.
4. IETF RFC 8693 — OAuth 2.0 Token Exchange.

Divulgação editorial. Este artigo reflete a interpretação de engenharia do TrueFoundry sobre os materiais públicos citados até 17 de setembro de 2026. As capacidades do produto estão restritas à documentação vinculada. Exemplos e padrões operacionais são ilustrativos; não constituem aconselhamento jurídico, parecer de auditoria, benchmark independente ou garantia de segurança, proteção ou conformidade.

‍