Acesso Cross-App no MCP Gateway do TrueFoundry: Acesso de Agentes Governado por Identidade, Mantido pelo seu IdP

Os agentes de AI estão se tornando rapidamente o controle remoto universal para o trabalho corporativo. Eles leem do Jira, escrevem no Slack, consultam o data warehouse, abrem pull requests e encadeiam uma dúzia de ferramentas juntas para concluir uma única tarefa. O Model Context Protocol (MCP) é o que torna isso possível — ele oferece aos agentes uma maneira padronizada de descobrir e chamar essas ferramentas.

Mas o MCP responde a como um agente conversa com uma ferramenta. Ele não responde à pergunta que toda equipe de segurança agora está fazendo: quais agentes têm permissão para alcançar quais sistemas, em nome de quem, com qual escopo — e quem pode visualizar e revogar isso?

Essa lacuna é exatamente o que o Acesso Cross-App (XAA) fecha. E isso se encaixa quase perfeitamente no que um gateway MCP foi construído para fazer. Este post explica o que é XAA, por que ele é importante e como o MCP Gateway do TrueFoundry o implementa — transformando seu provedor de identidade no plano de controle para cada conexão agente-ferramenta em sua organização.

O problema: conexões de agentes ocorrem fora do perímetro de identidade

Hoje, quando um usuário conecta um cliente MCP (um aplicativo de AI como Claude, Cursor ou VS Code) a um servidor MCP (Slack, Atlassian, um serviço interno), o aperto de mão (handshake) de autorização geralmente acontece diretamente entre esses dois aplicativos. O padrão se parece com uma de duas coisas, e ambas são problemáticas em escala corporativa:

• Credenciais estáticas e chaves de API. De longa duração, frequentemente com escopo excessivo, espalhadas por laptops e arquivos de configuração. Elas raramente são rotacionadas e quase nunca são revogadas de forma limpa. Cada chave representa privilégio permanente e raio de alcance de danos (blast radius).
• Consentimento OAuth por usuário. Melhor que chaves brutas, mas exibe uma tela de consentimento para o usuário para cada ferramenta, cada cliente, todas as vezes. O IdP corporativo autenticou o usuário no aplicativo — mas ele nunca autorizou o relacionamento entre o cliente de AI e a ferramenta. Do ponto de vista do IdP, essa concessão é invisível.

O resultado é a shadow AI: uma teia vasta e não gerenciada de conexões agente-aplicativo que as equipes de TI e segurança não conseguem inventariar nem controlar. Os administradores não conseguem responder "quais clientes de AI podem atuar no Atlassian como este usuário e com quais escopos?" — e não conseguem desligar isso em um único lugar quando um funcionário ou um agente é desligado (offboarded).

O TrueFoundry já resolve grande parte disso centralizando o acesso ao MCP por meio de um gateway governado único — um único ponto de entrada, RBAC até o nível da ferramenta, um cofre de credenciais seguro e uma trilha de auditoria completa. O XAA fecha a última lacuna: ele coloca o próprio provedor de identidade de volta na decisão de autorização, para que as mesmas políticas que governam o restante do seu stack agora governem seus agentes.

O que é realmente o Acesso Cross-App

Acesso Cross-App (XAA) é uma extensão do OAuth 2.0 que permite que um provedor de identidade corporativo medie e aprove a conexão entre dois aplicativos — em vez de esses dois aplicativos estabelecerem confiança diretamente. Ele foi introduzido pela Okta em junho de 2025, adotado pelo IETF OAuth Working Group em setembro de 2025 e incorporado ao MCP em novembro de 2025 como a extensão de autorização conhecida como Enterprise-Managed Authorization (EMA). Essa extensão atingiu o status estável em junho de 2026.

Uma rápida nota sobre terminologia, porque você verá ambos os nomes na prática:

• ID-JAG — o Identity Assertion JWT Authorization Grant — é a extensão OAuth neutra em relação a fornecedores que está sendo padronizada no IETF. É o modelo técnico: como um IdP emite uma asserção de identidade assinada, quais declarações (claims) ela carrega e como um aplicativo a resgata.
• XAA é o nome do produto da Okta para sua implementação do ID-JAG, e o termo com o qual a maioria das pessoas se depara primeiro. No MCP, o mesmo mecanismo é apresentado como a extensão Enterprise-Managed Authorization.

Usaremos "XAA" por toda parte, mas o ponto importante é que este é um padrão aberto. Qualquer IdP pode implementar o ID-JAG, e qualquer servidor, cliente ou gateway MCP pode dar suporte a ele.

As três funções

O XAA define uma separação clara de responsabilidades:

O fluxo

A magia do XAA é que ele substitui a etapa manual de consentimento por aplicativo por uma troca de tokens governada por políticas e intermediada pelo IdP:

Como o aplicativo de recurso já confia nas chaves de assinatura do IdP vindas do SSO, nenhuma nova infraestrutura de confiança é necessária. O IdP aplica a política uma vez, emite tokens com escopo de curta duração e registra cada concessão — e o usuário nunca vê uma solicitação de consentimento. As decisões de autorização se movem da camada de aplicação para a camada de identidade, onde são auditáveis e revogáveis.

Como o TrueFoundry implementa o XAA

Um gateway MCP é o lugar ideal para colocar o XAA, porque o gateway já se encontra exatamente no ponto onde o aplicativo solicitante se encontra com o aplicativo de recurso. A arquitetura de autenticação do TrueFoundry foi construída em torno de uma separação deliberada da autenticação inbound (como os clientes provam quem são para o Gateway) da autenticação outbound (como o Gateway alcança os servidores MCP downstream). Essa separação é precisamente o formato de que o XAA precisa.

O TrueFoundry dá suporte ao XAA com o Gateway assumindo a função de aplicativo solicitante (requesting app). Aqui está o fluxo principal.

O agente envia seu token Okta; o Gateway faz a troca

O aplicativo de agente autentica o usuário uma vez com o Okta e recebe um token Okta. A partir de então, ele simplesmente passa esse token para o Gateway em cada solicitação — ele não precisa implementar o XAA por si próprio nem obter suas próprias asserções com escopo. O Gateway cuida do restante:

1. Valida o token do Okta e o resolve para uma identidade do TrueFoundry (usuário, equipe ou conta virtual) usando a configuração existente do Identity Provider e o mapeamento de grupo do Okta → equipe, aplicando em seguida o RBAC/ABAC em nível de ferramenta.
2. Realiza a troca de token com o Okta, solicitando uma asserção ID-JAG com escopo específico para o servidor MCP que o agente está tentando alcançar. O Okta avalia a política de XAA e retorna a asserção com escopo — sem nenhuma solicitação adicional de consentimento ou autorização para o usuário.
3. Resgata a asserção por um token de acesso de curta duração e restrito ao público-alvo (audience) para aquele servidor MCP.
4. Chama o servidor MCP com o token de escopo definido e transmite o resultado de volta para o agente.

O usuário faz login uma única vez, na aplicação do agente. Ele nunca vê uma tela de consentimento OAuth por servidor, e o agente nunca mantém credenciais permanentes para nenhuma ferramenta downstream.

Isso se baseia diretamente no modelo de autenticação de entrada existente do TrueFoundry (tokens de Identity Provider e Token Passthrough), com o Gateway atuando como a aplicação solicitante de XAA — realizando a troca de tokens e definindo o escopo de cada asserção para o servidor específico em questão.

Conectando servidores MCP que não suportam XAA (o diferencial)

A maioria dos servidores MCP em uso — serviços internos, ferramentas envelopadas em OpenAPI, servidores de terceiros — não implementa XAA nativamente, e muitos nunca o farão. É aqui que um gateway justifica seu valor.

Como o Gateway finaliza o fluxo de identidade centralmente, ele pode colocar a governança XAA à frente de qualquer servidor MCP, independentemente de o servidor suportar ou não o padrão. Assim que a política é satisfeita e um token com escopo está disponível, o Gateway faz a mediação da conexão downstream usando qualquer método que o servidor realmente compreenda — OAuth 2.0 por usuário, client credentials, uma chave de API compartilhada do cofre seguro, token passthrough ou cabeçalhos customizados. O servidor MCP obtém uma autorização governada pela empresa e com o IdP no fluxo sem escrever uma única linha de código de troca de tokens, e você ganha um ponto de controle XAA consistente em todo o seu ecossistema de ferramentas, em vez de uma colcha de retalhos de servidores "prontos para XAA" e "legados".

Mapeando o XAA para recursos que o TrueFoundry já oferece

Como isso funciona na prática

Considere um desenvolvedor que pede ao Cursor para triar um incidente: buscar os chamados relacionados no Atlassian, verificar a thread relevante no Slack e resumir o histórico de deploy.

1. O desenvolvedor faz login na aplicação do agente uma vez via SSO do Okta, e o agente recebe um token do Okta.
2. O agente envia esse token do Okta para o TrueFoundry Gateway a cada requisição. Quando precisa do Atlassian, o Gateway valida o token, confirma que a equipe do desenvolvedor pode acessar o servidor MCP do Atlassian e apenas as ferramentas de leitura às quais tem direito, e realiza a troca de token com o Okta — solicitando uma asserção com escopo para esse servidor. O Okta verifica a política — o grupo deste desenvolvedor tem permissão para deixar um cliente de AI acessar o Atlassian? — e retorna a asserção com escopo. Sem pop-up de consentimento.
3. O Gateway resgata a asserção por um token de acesso de curta duração e com escopo definido e faz a mediação da chamada para o Atlassian.
4. Toda ação é gravada no log de auditoria do TrueFoundry, atribuída à identidade individual e ao agente específico.
5. Quando esse desenvolvedor sai da equipe, a TI o desativa no Okta. O acesso dele — e do seu agente — a cada servidor MCP atrás do Gateway é revogado pelo mesmo fluxo de offboarding que governa o restante de suas aplicações.

Nenhuma nova chave foi gerada. Nenhum privilégio permanente foi deixado para trás. A equipe de segurança revisou a política uma única vez, no Okta.

Por que TrueFoundry + Okta

O Okta agrupa o ecossistema XAA em três camadas: aplicações solicitantes (os clientes e agentes), aplicações de recursos (as ferramentas que contêm dados) e a infraestrutura de identidade e camada de gateway que roteia e protege o tráfego intermediário. O TrueFoundry está posicionado exatamente nessa terceira camada.

A combinação é natural e complementar:

• O Okta é o plano de controle. Ele autentica usuários, avalia quais aplicações podem se conectar e emite as asserções assinadas e tokens de curta duração que levam a política entre domínios.
• O TrueFoundry é o plano de execução e conectividade para MCP. É onde as asserções são resgatadas, onde o RBAC em nível de ferramenta é aplicado, onde servidores sem XAA são integrados ao padrão, onde os guardrails rodam e onde cada chamada é registrada.

Juntos, eles permitem que uma empresa responda à pergunta decisiva em qualquer revisão moderna de segurança de AI — "podemos governar isso em nosso IdP?" — com um sim inequívoco: seu provedor de identidade decide quais clientes de AI se conectam, a quais servidores MCP, com quais escopos, e você pode revogar tudo centralmente.

Primeiros passos

Se você já está executando o MCP Gateway do TrueFoundry, o suporte ao XAA estende o modelo de autenticação que você usa hoje — registre o Okta como um Identity Provider, mapeie grupos do Okta para equipes do TrueFoundry e traga seus servidores MCP (nativos em XAA ou não) para debaixo de uma única porta de entrada governada por identidade.

Se você está avaliando como implantar AI agents em escala sem herdar a proliferação de credenciais e o risco de shadow-AI, esta é a base: baseada em padrões, intermediada pelo IdP e construída sobre o OAuth e o OpenID Connect em que você já confia.