Identity do agente confiável para a empresa agente

Conforme as empresas adotam o paradigma de agência, um novo desafio de segurança aparece: Como a identidade do usuário final flui por uma rede de agentes de IA autônomos? Em arquiteturas de API tradicionais, um usuário autentica uma vez e o aplicativo chama serviços de back-end em nome do usuário. A cadeia de identidade é curta, bem compreendida e geralmente gerenciada dentro de um único domínio Trust. No entanto, as arquiteturas agentes apresentam cadeias muito mais longas em que uma única solicitação é enviada para vários agentes, serviços e servidores do Modelo de Protocolo de Contexto (MCP), cada um potencialmente atravessando limites de serviço, domínios Trust e até mesmo limites organizacionais. Sem uma estratégia deliberada para propagação de identidade, as empresas enfrentam uma escolha entre segurança e funcionalidade, um dilema que nenhum arquiteto deve enfrentar.

A MuleSoft lida com as complexidades da propagação de identidade com seu recurso de identidade do agente confiável. Essa solução utiliza uma estratégia gerenciada por gateway baseada em política para garantir que a identidade do usuário final seja mantida em vários tipos de interação, incluindo protocolos de agente para agente (A2A), chamadas de ferramenta MCP e solicitações da API REST.Ao centralizar o gerenciamento de identidade na camada do Gateway flexível por meio de políticas de autenticação de saída, as empresas podem proteger toda a rede de agentes sem modificar serviços de back-end ou agentes.

Este documento explica o desafio de propagação de identidade usando uma série progressiva de cenários, cada um apresentando complexidade adicional. Juntos, esses cenários ilustram por que a Identidade do agente confiável é um requisito fundamental para qualquer implantação de agente em escala corporativa.

Em um aplicativo convencional, o fluxo de identidade (fluxo JWT do OAuth) é simples: O usuário faz login, recebe um token e o aplicativo usa o token para acessar recursos de backend. O token é integrado à identidade do usuário, incluindo quem ele é e o que ele está autorizado a fazer, e viaja com cada solicitação. A cadeia de chamadas é curta, geralmente um ou dois saltos, e a propagação de identidade é resolvida.

Porém, as arquiteturas agentes apresentam cadeias de chamadas muito mais longas em que uma única solicitação de usuário pode ser exibida em vários agentes, serviços de back-end e servidores de Protocolo de contexto de modelo (MCP).Cada destino da solicitação constitui um salto separado. Embora esses desafios, como propagação de identidade de vários saltos, modelos de autorização mista, limites de Trust entre domínios, sejam comuns em qualquer configuração de API distribuída, o que é distinto é como o ecossistema atual responde por padrão. Hoje, o padrão dominante para comunicação entre agentes e agentes de API depende de credenciais de cliente, chaves de API ou segredos compartilhados. Isso significa:

A identidade do usuário é perdida por padrão. Quando um agente chama um servidor MCP ou a API downstream usando credenciais do cliente, a solicitação carrega a identidade de serviço do agente, não a do usuário final. O serviço a jusante não tem como saber qual usuário iniciou a ação, impossibilitando a autorização por usuário e as trilhas de auditoria.
As necessidades de autorização mista são ignoradas. Nem todos os serviços a jusante exigem contexto do usuário.Enquanto alguns gerenciam informações específicas do usuário, como transações ou portfólios, outros fornecem dados voltados para o público ou em nível do sistema, como material de referência ou tendências de mercado.Visto que o padrão atual depende exclusivamente das credenciais do cliente, não há maneira de diferenciar essas necessidades ou de propagar seletivamente a identidade do usuário apenas quando necessário.
As fronteiras de Trust entre domínios não foram abordadas. Os agentes em cenários B2B e regulados podem precisar interagir com sistemas governados por provedores de identidade (IdPs) totalmente separados. Por exemplo, um sistema bancário externo não pode interpretar um token de Single Sign On (SSO) corporativo, mas ainda precisa receber o consentimento e a intenção do usuário. O fluxo de credenciais do cliente não tem mecanismo para isso.

O resultado é uma lacuna entre o requisito corporativo de acesso de privilégio mínimo atribuível ao usuário e a dependência atual do ecossistema de autenticação em nível de serviço sem contexto do usuário. Fechar essa lacuna requer uma abordagem deliberada e em camadas para propagação de identidade. Para ilustrar esses conceitos, os cenários a seguir utilizam Finport, uma aplicação fictícia de fintech, para fornecer exemplos práticos desses padrões arquitetônicos.

O Finport é um aplicativo da Web fictício de gerenciamento de portfólio Fintech voltado para o consumidor com suporte em uma arquitetura agente. Um agente (construído usando o MuleSoft Agent Broker) coordena vários agentes a jusante e servidores MCP para atender às solicitações do usuário.

O Finport expõe três funcionalidades principais, cada uma com um requisito de identidade distinto:

“Mostre-me o meu portfólio.”: O usuário solicita suas participações pessoais e o histórico de transações. Como esses dados são específicos do usuário, o agente de serviço de portfólio a jusante e o Servidor MCP de portfólio devem saber quais dados do usuário retornar e devem verificar se o usuário está autorizado a acessá-los. A identidade do usuário deve ser propagada a cada salto.
“Quais são as tendências atuais do mercado?”: O usuário solicita dados de mercado público e preços de ativos. Como os dados são públicos e não variam de acordo com o usuário, o Agente de dados de mercado a jusante e o Servidor MCP do mercado de ativos não precisam ou esperam um token no escopo do usuário. As credenciais de serviço próprias do agente são suficientes.
“Transfira $ 5.000 para minha conta de poupança externa.”: O usuário inicia uma transferência de fundos para um banco que usa um IdP diferente (por exemplo, Auth0 em vez de Okta). O token Finport do usuário é sem significado para o sistema do banco. O usuário deve se autenticar diretamente com o banco (em linha na conversa) antes que a transferência possa prosseguir.

Cada uma dessas funcionalidades é mapeada para um padrão de propagação de identidade diferente. Os cenários a seguir criam progressivamente de uma linha de base padrão (sem agentes) em cada padrão distinto, ilustrando como as políticas de saída no Gateway flexível atendem a cada requisito sem modificar os agentes ou serviços de back-end.

Antes de apresentar agentes, é essencial estabelecer a linha de base: um usuário autenticando-se com um aplicativo cliente e acessando um serviço de back-end.

O fluxo:

O usuário abre o Finport e é redirecionado para a página de login do IdP (por exemplo, Okta).
O usuário se autentica (nome de usuário, senha, SSO, autenticação multifator (MFA) e quaisquer outros requisitos).
O IdP emite um token de acesso JWT assinado para o aplicativo Finport.
O Finport agora tem um token de usuário que representa a identidade do usuário: quem são, em quais escopos foram concedidos e quando o token expira. Ele pode apresentá-lo a qualquer serviço downstream em nome desse usuário.

O que isto estabelece: Esse processo segue o padrão padrão de arquitetura do OAuth 2.0. O token de usuário inicial, validado por um IdP confiável, serve como a base essencial para todas as operações subsequentes. Cada cenário subsequente é baseado nesse token.

A pergunta: Depois de autenticado, o usuário inicia ações como transferências de fundos, análise de mercado ou análises de portfólio. Essas solicitações são processadas por meio de um agente e podem envolver vários agentes downstream ou servidores MCP. Isso levanta questões críticas: Como a identidade do usuário é mantida nessas solicitações distribuídas? O que acontece quando um serviço downstream usa um IdP completamente diferente?

O usuário pede ao agente da Finport para “Mostrar-me o meu portfólio”. Essa interação aciona uma cadeia de back-end começando com o Finport Agent Broker, criado usando o MuleSoft Agent Broker. O corretor entrega a tarefa a um agente de serviço de portfólio, que, por sua vez, consulta um Servidor MCP de portfólio. O token de autenticação inicial do usuário agora deve percorrer vários saltos para acessar os registros de portfólio solicitados.

Passar o token original viola o princípio de privilégio mínimo, enquanto usar uma conta de serviço perde a identidade do usuário.

O Agente de portfólio recebe o token do usuário, mas não pode simplesmente encaminhar esse mesmo token para o agente de serviço de portfólio, pois isso violaria o princípio do privilégio mínimo e não abrangeria adequadamente a solicitação para o serviço a jusante. Por outro lado, usar uma conta de serviço resulta em uma total perda de identidade do usuário. O agente de serviço de portfólio e o servidor MCP de portfólio não teriam como saber qual portfólio do usuário retornar, e a trilha de auditoria atribuiria cada ação à identidade de serviço do corretor em vez do usuário final.

O Flex Gateway resolve essas complexidades de propagação de identidade de forma transparente por meio de sua política de troca de token OAuth 2.0 de saída. Essa solução intercepta solicitações de saída a cada salto na cadeia de chamadas, trocando o token de usuário recebido com o IdP por uma nova credencial definida especificamente para o serviço downstream. A política On-Benefit-Of (OBO) é compatível com os protocolos OAuth 2.0 Token Exchange (RFC 8693) e Microsoft Entra ID On-Benefit-Of.

Principal benefício arquitetônico: Todo esse processo é tratado pela política de saída do Flex Gateway. O corretor e os agentes contêm lógica de autenticação zero. Em vez disso, eles se concentram apenas na lógica de negócios, enquanto a camada de gateway impõe a propagação de identidade.

O fluxo:

O usuário se autentica com Okta e o aplicativo Finport envia uma solicitação por meio do Flex Gateway.
O corretor recebe o token de usuário validado e determina qual agente de serviço de portfólio é necessário.
A política de OBO de saída do Flex Gateway troca o token de usuário com o IdP por um token no escopo do agente de serviço de portfólio.
O agente de serviço de portfólio recebe um token com escopo adequado e chama o Servidor MCP de portfólio.
O Gateway flexível troca novamente o token, desta vez no escopo do servidor MCP.
O servidor MCP de portfólio retorna os dados de portfólio específicos do usuário.
Existe uma trilha de auditoria completa. Cada salto é atribuível ao usuário final original.

Por que isso importa: Sem a troca de token OBO, as empresas devem escolher entre encaminhar o token original, que viola o privilégio mínimo, ou usar contas de serviço, que correm o risco de perder a identidade do usuário. O padrão de OBO elimina essa compensação, pois a identidade do usuário é preservada a cada salto, cada token é delimitado para seu destino e os agentes permanecem completamente ignorantes da mecânica de identidade.

Nem todos os serviços a jusante exigem contexto do usuário. O usuário pergunta ao agente Finport, “Quais são as tendências atuais do mercado?” Diferentemente da solicitação de portfólio no Cenário 1, os dados de tendência de mercado são públicos quando não variam de acordo com o usuário. O downstream Market Data Agent e o Asset Market MCP Server não precisam ou esperam um token no escopo do usuário.

Propagar tokens de usuário onde eles não são necessários expande a superfície de ataque.

Se o Finport Agent Broker propagar o token do usuário para o Market Data Agent usando o padrão OBO do cenário 1, isso funcionaria, mas seria desnecessário. Propagar tokens de usuário onde eles não são necessários expande a superfície de ataque, cria dependências desnecessárias no IdP para trocas de token e viola o princípio de privilégio mínimo. O Agente de dados de mercado simplesmente precisa saber que a solicitação vem de um serviço autorizado, não qual usuário está solicitando.

A política de credenciais de cliente OAuth 2.0 de saída do Flex Gateway lida com isso de forma transparente. Em vez de trocar o token do usuário, a política insere as credenciais de serviço próprias da corretora por meio de uma concessão de credenciais do cliente na solicitação de saída. O Agente de dados de mercado a jusante recebe um token de nível de serviço autenticado adequadamente em que nenhuma identidade do usuário é propagada porque nenhuma é necessária.

Principal benefício arquitetônico: A estratégia de propagação de identidade não é adequada a todos, mas é determinada por rota a jusante com base na natureza dos dados e nos requisitos do serviço de destino. As políticas de saída do Flex Gateway tornam isso configurável por rota. O mesmo agente Finport Broker pode participar de fluxos OBO (no Cenário 1) e fluxos S2S sem nenhuma alteração de código. A configuração da política no gateway de saída determina qual padrão se aplica a qual chamada a jusante.

O fluxo:

O usuário pergunta ao agente Finport, “Quais são as tendências atuais do mercado?”
A corretora determina que o Agente de dados de mercado é necessário para cumprir a solicitação.
A política de Credenciais do cliente de saída do Flex Gateway obtém um token de nível de serviço usando as credenciais próprias da corretora (nenhum token de usuário é trocado ou propagado).
O Agente de dados de mercado recebe uma solicitação de serviço autenticada adequadamente e chama o Servidor MCP do mercado de ativos.
O servidor MCP do mercado de ativos retorna os dados de mercado público.
Nenhuma identidade de usuário está presente na cadeia por design, pois nenhuma é necessária para esse tipo de dados.

Por que isso importa: A estrutura orientada por políticas do Flex Gateway capacita os arquitetos a selecionar o modelo de identidade ideal para cada interação, resolvendo a difícil escolha entre a propagação universal de token de usuário (que aumenta os riscos de sobrecarga e segurança) e o uso de conta de serviço global, que sacrifica o contexto e a conformidade do usuário.

O cenário de identidade mais complexo surge quando um agente precisa interagir com um sistema governado por um IdP completamente diferente, um que não reconhece o token de usuário existente.

O cenário: O usuário do Finport pede ao Agente do Finport para “Transferir $ 5.000 para minha conta de poupança externa.” Essa solicitação envolve dois caminhos a jusante distintos:

O caminho do agente de serviço de portfólio (OBO) para verificar as participações do usuário
O caminho do Agente de transação → Servidor MCP de transação → Banco do usuário para executar a transferência real

O Agente de transação precisa interagir com o banco do usuário, que usa seu próprio IdP. O token Okta do usuário da Finport é sem significado para o sistema do banco, pois o banco não tem relação de Trust com o IdP da Finport. Nem o padrão OBO (do Cenário 1) nem o padrão S2S (do Cenário 2) podem resolver isso. O OBO troca tokens no mesmo IdP, e o S2S usa credenciais de serviço que não têm identidade de usuário. O banco exige que o usuário autentique diretamente com suas próprias credenciais bancárias, possivelmente incluindo MFA.

A política Código de autorização em tarefa de saída A2A no Gateway flexível usa um mecanismo de resposta a desafios na conversa do agente. Se um token secundário estiver ausente ao entrar em contato com o banco, a política retornará um desafio exigido por autenticação. Esse desafio inclui todos os detalhes necessários, como pontos de extremidade, escopos e parâmetros de PKCE, para que o cliente inicie um fluxo do OAuth 2.0 com o provedor do banco.

O aplicativo Finport então exibe o login em linha do banco para autenticação de usuário direta. Quando concluído, o cliente retorna o token na solicitação A2A. A política extrai esse token para o sistema do banco e o depura do corpo da mensagem para garantir a segurança.

Principal benefício arquitetônico: A camada de política de gateway orquestra todo o processo de autenticação entre domínios, garantindo que nem o corretor nem os agentes interajam com credenciais brutas ou exigam Knowledge do IdP do banco. Ao usar essa estrutura de resposta a desafios, os usuários mantêm controle total sobre: eles fornecem consentimento explícito para autenticação com sistemas externos, enquanto o token resultante é transmitido com segurança por meio da camada de política.

O fluxo:

O usuário solicita que o Finport inicie uma transferência. A solicitação flui pelo agente.
O agente defende, usando o Portfólio (OBO) para verificar participações e a Transação (em tarefa) para executar a transferência.
O caminho da transação aciona um desafio obrigatório de autenticação da política Em tarefa no Gateway flexível.
O desafio se propaga de volta ao aplicativo Finport, que apresenta o fluxo de login do banco ao usuário em linha.
O usuário se autentica com seu banco, incluindo MFA, se necessário.
O token bancário é incluído na solicitação A2A subsequente. A política a extrai, a define no cabeçalho Autorização e encaminha a solicitação.
O Servidor MCP da transação recebe a solicitação com o token do banco e executa a transferência.

Por que isso importa: A identidade entre domínios é um grande desafio em arquiteturas de agentes. Sem autenticação na tarefa, as empresas devem pré-estabelecer relacionamentos de Trust complexos entre cada IdPin da rede ou pedir aos usuários para fornecer credenciais bancárias a um agente. O padrão Em tarefa resolve isso permitindo a autenticação de usuário direta com provedores externos; a política gerencia a mecânica de token enquanto mantém os agentes desconectados dos domínios de identidade externos.

Em todos os três cenários, um único princípio arquitetônico contém: A propagação de identidade é imposta na camada de gateway, não dentro de agentes ou serviços. Os agentes e servidores MCP contêm lógica de autenticação zero. Seu papel é restrito ao processamento de solicitações autenticadas e retorno de resultados, enquanto a camada de política de saída do Gateway flexível gerencia todas as operações relacionadas à identidade.

Isso funciona porque as políticas de autenticação de saída do Flex Gateway interceptam o tráfego no ponto certo: após o agente tomar a decisão de roteamento, mas antes que a solicitação chegue ao serviço downstream. A política transforma o token, seja uma intercâmbio de OBO, injeção de credenciais do cliente ou em tarefa challenge-response, e encaminha uma solicitação autenticada adequadamente. O serviço downstream nunca sabe a diferença, portanto, o agente nunca precisa se importar. A lógica de autenticação é centralizada no gateway, não espalhada entre os serviços. Os serviços de back-end não exigem alterações de código e a mesma configuração de política pode ser reutilizada em várias rotas.

Essa abordagem também é agnóstica de protocolo. Como as políticas operam na camada HTTP, elas se aplicam de modo consistente se o agente se comunica por meio de REST, MCP, A2A ou webhooks. Como documentado no Agent Fabric Deep Dive, todo o tráfego A2A e MCP é roteado por meio do Flex Gateway para garantir que as políticas sejam aplicadas em cada ponto final, o que significa que a propagação de identidade é aplicada uniformemente, independentemente do protocolo de comunicação.

Três padrões compostos cobrem todo o espectro de requisitos de identidade em uma arquitetura agente:

Padrão	Política	Identidade do usuário	Interação do usuário	Caso de uso
Em nome de (OBO)	Política de injeção de credenciais OBO OAuth 2.0	Mantido	Nenhum (transparente)	Dados específicos do usuário no mesmo domínio Trust
Serviço para servidor (S2S)	Credenciais de cliente de saída do OAuth 2.0	Não propagado	Nenhum	Dados públicos, operações no nível do sistema
Código de autorização em tarefa	Código de autorização em tarefa A2A de saída	Principal + secundário	Obrigatório (autenticação em linha)	Operações entre domínios, provedor de várias identidades, de alto risco

Esses padrões não são mutuamente exclusivos. Conforme os cenários do Finport mostram, um único agente pode usar OBO para uma chamada a jusante, S2S para outra e Em tarefa para um terceiro. A configuração da política em cada rota de saída determina qual padrão se aplica. Não há alterações no código do agente e nenhuma modificação de serviço, apenas política.

Os padrões impostos por gateway descritos acima protegem interações individuais, mas a propagação de identidade não é uma preocupação isolada. É uma camada fundamental do modelo de governança mais amplo do MuleSoft Agent Fabric. Como descrito no Agent Fabric Deep Dive, o Agent Fabric é construído em quatro pilares: Descubra, orquestra, controla e observa, e cada um depende de uma cadeia de identidade confiável para funcionar de forma eficaz.

Descobrir: O Registro de agentes cataloga agentes e suas capacidades. Metadados do agente, incluindo requisitos de autenticação, permitem que os agentes entendam quais padrões de identidade cada agente espera.
Orquestração: O agente agente coordena fluxos de trabalho de vários agentes. O Gateway flexível lida com transparência com a transformação de identidade a cada salto, de modo que o agente pode se concentrar na decomposição e no roteamento de tarefas.
Govern: Todo o tráfego A2A e MCP é roteado por meio do Flex Gateway, mesmo que o sistema de destino não esteja seguro, para garantir que as políticas sejam aplicadas a cada ponto de extremidade. As políticas de autenticação de saída fazem parte da camada de governança.
Observar: O Visualizador do agente fornece observabilidade em tempo real por meio de um mapa dinâmico e interativo de interações do agente. Com a identidade do usuário preservada a cada salto, os rastreamentos e registros fornecem trilhas de auditoria atribuíveis ao usuário em toda a rede de agentes.

Sem propagação de identidade confiável, a governança está incompleta. Você pode catalogar e orquestrar agentes, mas não pode garantir que eles atuem dentro dos limites da autorização do usuário. A Identidade do agente confiável fecha essa lacuna, garantindo que a segurança e o contexto do usuário permaneçam essenciais para fluxos de trabalho agentes.

Para implementar estes padrões:

Entenda o diretório de políticas de saída. Revise o conjunto completo de políticas de autenticação de saída disponíveis para o Flex Gateway.
Comece com OBO. A política de troca de token OAuth 2.0 atende às necessidades mais comuns de propagação de identidade: preservar o contexto do usuário entre saltos de agente.
Adicionar no trabalho para cenários entre domínios: Quando sua rede de agentes ultrapassa limites de Trust, a política de Código de autorização na tarefa A2A fornece o mecanismo de resposta a desafios para obter credenciais secundárias do usuário.
Tela do Agente de alavanca. Defina sua rede de agentes no YAML de agente-rede com configurações de política que especificam o modelo de identidade por rota. A plataforma cuida do restante.

Para orientações detalhadas sobre a implementação, consulte o guia de implementação.

Nikhil Aggarwal é um Engenheiro distinguido na Salesforce, onde ele lidera a arquitetura para MuleSoft e Salesforce Automation Clouds. Nikhil traz mais de 18 anos de experiência em entregar produtos em grande escala e tem paixão pela arquitetura escalonável, experiências intuitivas do desenvolvedor e a criação de equipes de alto desempenho. Antes da Salesforce, ele liderava várias iniciativas no Microsoft Power Platform, no Dataverse e no Office 365 do conceito ao lançamento. Seu trabalho continua a moldar como as empresas modernas conectam sistemas, automatizam fluxos de trabalho e liberam valor comercial na era de IA.

Akash Trivedi é Diretor de Engenharia na Salesforce com mais de 18 anos de experiência na criação de sistemas corporativos escalonáveis, seguros e de alto desempenho. Ele trabalha na interseção de IA, arquitetura corporativa e inteligência de processos, com foco em plataformas nativas da nuvem e soluções confiáveis que operam em escala. Antes da Salesforce, ele ocupava cargos de engenharia na Microsoft, onde contribuiu para produtos, incluindo Copilot, Dataverse e Power Platform.