에이전트 중심 엔터프라이즈의 신뢰할 수 있는 에이전트 신원

엔터프라이즈가 에이전트 패러다임을 채택함에 따라 새로운 보안 문제가 나타납니다. 최종 사용자 ID는 자율 AI 에이전트의 네트워크를 통해 어떻게 흐릅니까? 기존 API 아키텍처에서는 사용자가 한 번 인증하고 애플리케이션이 사용자를 대신하여 백엔드 서비스를 호출합니다. ID 체인은 짧고 잘 이해되며 일반적으로 단일 Trust 도메인 내에서 관리됩니다. 그러나 에이전트 아키텍처에서는 단일 요청이 여러 에이전트, 서비스, 그리고 모델 컨텍스트 프로토콜(MCP) 서버에 걸쳐 분산되어 훨씬 더 긴 신원 체인을 형성하며, 각각은 서비스 경계, 신뢰 도메인, 심지어 조직 경계를 넘을 수 있습니다. ID 전파를 위한 의도적인 전략이 없으면 엔터프라이즈는 보안과 기능 사이에서 선택해야 하는 딜레마에 직면하게 됩니다.

MuleSoft는 Trusted Agent Identity 기능을 사용하여 ID 전파의 복잡성을 해결합니다. 이 솔루션은 정책 기반 게이트웨이 관리 전략을 활용하여 에이전트 간(A2A) 프로토콜, MCP 도구 호출, REST API 요청 등 다양한 상호 작용 유형에 걸쳐 최종 사용자 ID를 유지합니다. 아웃바운드 인증 정책을 통해 Flex 게이트웨이 계층에서 ID 관리를 중앙 집중화하여 백엔드 서비스 또는 에이전트를 수정하지 않고 전체 에이전트 네트워크를 보호할 수 있습니다.

이 문서는 점진적으로 복잡성이 더해지는 여러 시나리오를 통해 신원 전파 과제를 살펴봅니다. 이러한 시나리오는 모두 신뢰할 수 있는 에이전트 신원이 엔터프라이즈 규모의 에이전트 배포에 대한 기본 요구 사항인 이유를 보여줍니다.

기존 애플리케이션에서는 신원 플로우(OAuth JWT 플로우)가 간단합니다. 사용자가 로그인하고 토큰을 받은 후, 애플리케이션이 토큰을 사용하여 백엔드 리소스에 액세스합니다. 토큰은 사용자 ID(자체 및 권한이 부여된 작업 포함)와 함께 포함되며 모든 요청과 함께 이동합니다. 호출 체인은 짧으며, 일반적으로 1~2홉이고, 신원 전파가 해결되어 있습니다.

그러나 에이전트 아키텍처에서는 단일 사용자 요청이 다양한 에이전트, 백엔드 서비스, MCP(모델 컨텍스트 프로토콜) 서버 전반에 걸쳐 분기될 수 있는 훨씬 더 긴 호출 체인을 특징으로 합니다. 각 요청 대상은 별도의 홉을 구성합니다. 이러한 과제(예: 멀티 홉 ID 전파, 혼합 권한 부여 모델, 도메인 간 Trust 경계)는 모든 분산 API 설정에서 일반적이지만, 현재의 생태계가 기본적으로 어떻게 반응하는지에 대한 차이점이 일 수 있습니다. 현재 에이전트 간 및 에이전트 간 API 통신의 주된 패턴은 클라이언트 자격 증명, API 키 또는 공유 암호에 의존합니다. 다음을 의미합니다.

기본적으로 사용자 신원이 손실됩니다. 에이전트가 클라이언트 자격 증명을 사용하여 MCP 서버 또는 다운스트림 API를 호출하면 요청에 최종 사용자가 아닌 에이전트의 서비스 ID가 전달됩니다. 다운스트림 서비스는 작업을 시작한 _사용자_를 알 수 없으므로 사용자별 권한 부여 및 감사 추적이 불가능합니다.
혼합 권한 부여 요구 사항은 무시됩니다. 모든 다운스트림 서비스에는 사용자 컨텍스트가 필요하지 않습니다. 일부 서비스는 트랜잭션 또는 포트폴리오와 같은 사용자별 정보를 관리하지만, 다른 서비스는 참조 자료 또는 시장 추세와 같은 공개 또는 시스템 수준 데이터를 제공합니다.현재 표준은 클라이언트 자격 증명에만 의존하므로 이러한 요구 사항을 구분하거나 필요한 경우에만 사용자 ID를 선택적으로 전파할 수 없습니다.
도메인 간 신뢰 경계는 해결되지 않습니다. B2B 및 규제 시나리오의 에이전트는 완전히 별도의 ID 공급자(IdP)가 관리하는 시스템과 상호 작용해야 할 수 있습니다. 예를 들어, 외부 은행 시스템은 기업의 싱글 사인온(SSO) 토큰을 해석할 수 없지만, 여전히 사용자의 동의와 의도를 받아야 합니다. 클라이언트 자격 증명 플로우에는 이러한 메커니즘이 없습니다.

사용자 귀속 및 최소 권한 액세스에 대한 엔터프라이즈 요구 사항과 사용자 컨텍스트가 없는 서비스 수준 인증에 대한 현재 생태계의 의존성 간에는 차이가 존재합니다. 이 격차를 해결하려면 ID 전파에 대해 의도적이고 계층화된 접근 방식을 취해야 합니다. 이러한 개념을 설명하기 위해 다음 시나리오에서는 가상의 핀테크 애플리케이션인 핀포트를 활용하여 이러한 아키텍처 패턴의 실용적인 예를 제공합니다.

Finport는 에이전트 아키텍처에 의해 지원되는 가상의 소비자 대면 Fintech 포트폴리오 관리 웹 응용 프로그램입니다. Agent Broker(MuleSoft Agent Broker를 사용하여 구축)는 여러 다운스트림 에이전트와 MCP 서버를 조정하여 사용자 요청을 처리합니다.

Finport는 각각 고유한 ID 요구 사항이 포함된 세 가지 핵심 기능을 노출합니다.

“내 포트폴리오를 보여줘.” 사용자가 개인 자산 및 트랜잭션 내역을 요청합니다. 이 데이터는 사용자별이므로, 다운스트림 포트폴리오 서비스 에이전트와 포트폴리오 MCP 서버는 반환할 어느 사용자의 데이터인지를 파악하고, 해당 사용자의 접근 권한을 확인해야 합니다. 모든 홉을 통해 사용자 ID를 전파해야 합니다.
“현재 시장의 추세는 무엇입니까?”: 사용자가 공개 시장 데이터 및 자산 가격을 요청합니다. 데이터는 공개되어 있고 사용자에 따라 달라지지 않으므로, 다운스트림 마켓 데이터 에이전트와 자산 마켓 MCP 서버는 사용자 범위 토큰을 요구하거나 기대하지 않습니다. 중개인의 자체 서비스 자격 증명이 충분합니다.
“내 외부 저축 계좌에 5,000달러를 전송하십시오.”: 사용자가 다른 IdP(예: Okta 대신 Auth0)를 사용하는 은행에 대한 기금 전송을 시작합니다. 사용자의 Finport 토큰은 은행 시스템에 의미가 없습니다. 전송을 진행하려면 사용자가 은행과 직접 인증해야 합니다(대화 내 인라인).

이러한 각 기능은 다른 ID 전파 패턴에 매핑됩니다. 다음 시나리오는 각각의 고유한 패턴을 통해 에이전트가 없는 표준 기준선에서 점진적으로 구축되며, 에이전트 또는 백엔드 서비스를 수정하지 않고 Flex 게이트웨이의 아웃바운드 정책이 각 요구 사항을 처리하는 방법을 보여줍니다.

에이전트를 소개하기 전에 클라이언트 응용 프로그램을 사용하여 인증하고 백엔드 서비스에 액세스하는 사용자와 같은 기준선을 설정해야 합니다.

플로우:

사용자가 Finport를 열고 IdP의 로그인 페이지로 리디렉션됩니다(예: Okta).
사용자가 인증합니다(사용자 이름, 암호, SSO, 다단계 인증(MFA), 기타 요구 사항).
IdP가 서명된 JWT 액세스 토큰을 Finport 애플리케이션에 발행합니다.
이제 Finport는 사용자의 신원을 나타내는 사용자 토큰을 보유하며, 여기에는 사용자의 정체, 부여된 권한 범위 및 토큰 만료 시점이 포함됩니다. 이 사용자를 대신하여 다운스트림 서비스에 제공할 수 있습니다.

이로써 확립되는 것: 이 프로세스는 표준 OAuth 2.0 아키텍처 패턴을 따릅니다. 신뢰할 수 있는 IdP에 의해 확인된 초기 사용자 토큰은 모든 후속 작업의 필수 기반이 됩니다. 모든 후속 시나리오는 이 토큰을 기반으로 합니다.

요구 사항: 인증되면 사용자가 기금 전송, 시장 분석 또는 포트폴리오 검토와 같은 작업을 시작합니다. 해당 요청은 에이전트 중개인을 통해 처리되며 여러 다운스트림 에이전트 또는 MCP 서버가 포함될 수 있습니다. 이것은 중요한 질문을 제기합니다. 배포된 요청 전반에서 사용자의 신원이 어떻게 유지됩니다? 다운스트림 서비스에서 완전히 다른 IdP를 사용하는 경우 어떻게 될까요?

사용자가 Finport 에이전트에게 _“내 포트폴리오를 보여줘.”_라고 요청합니다. 이 상호 작용은 MuleSoft Agent Broker를 사용하여 구축된 Finport Agent Broker부터 백엔드 체인을 트리거합니다. 중개인은 작업을 포트폴리오 서비스 에이전트에게 위임합니다. 이 에이전트는 포트폴리오 MCP 서버를 쿼리합니다. 이제 사용자의 초기 인증 토큰은 요청된 포트폴리오 레코드에 액세스하기 위해 여러 홉을 거쳐 이동해야 합니다.

원래 토큰을 전달하면 최소 권한 원칙이 위반되고 서비스 계정을 사용하면 사용자의 ID가 손실됩니다.

Finport 에이전트는 사용자의 토큰을 수신하지만, 최소 권한 원칙을 위반하고 다운스트림 서비스에 대한 요청 범위를 제대로 지정하지 않으므로 해당 토큰을 포트폴리오 서비스 에이전트에게 전달할 수 없습니다. 반대로 서비스 계정을 사용하면 전체적으로 사용자 ID가 손실됩니다. 포트폴리오 서비스 에이전트 및 포트폴리오 MCP 서버는 반환할 _사용자_의 포트폴리오를 알 수 없으며 감사 내역은 최종 사용자가 아닌 중개인의 서비스 ID에 모든 작업을 귀속합니다.

Flex Gateway는 이러한 ID 전파 복잡성을 아웃바운드 OAuth 2.0 토큰 교환 정책을 통해 투명하게 해결합니다. 이 솔루션은 호출 체인의 모든 홉에서 아웃바운드 요청을 가로채고, 들어오는 사용자 토큰을 IdP와 교환하여 다운스트림 서비스에 대해 특별히 범위가 지정된 새 자격 증명으로 교환합니다. On-Behalf-Of(OBO) 정책은 OAuth 2.0 토큰 교환(RFC 8693) 및 Microsoft Entra ID On-Behalf-Of 프로토콜을 모두 지원합니다.

주요 아키텍처적 이점: 이 전체 프로세스는 Flex Gateway 아웃바운드 정책에 따라 처리됩니다. 중개인 및 에이전트에는 제로 인증 논리가 포함되어 있습니다. 대신, 중개인과 에이전트는 순수하게 비즈니스 논리에만 집중하고, 게이트웨이 계층이 사용자 신원 전파를 적용합니다.

흐름:

사용자가 Okta를 통해 인증하고 Finport 애플리케이션이 Flex Gateway를 통해 요청을 보냅니다.
중개인은 확인된 사용자 토큰을 수신하고 포트폴리오 서비스 에이전트가 필요함을 결정합니다.
Flex Gateway의 아웃바운드 OBO 정책은 사용자 토큰을 IdP와 교환하여 포트폴리오 서비스 에이전트에 범위가 지정된 토큰을 받습니다.
포트폴리오 서비스 에이전트는 올바르게 범위가 지정된 토큰을 수신하고 포트폴리오 MCP 서버를 호출합니다.
Flex 게이트웨이는 토큰을 다시 교환하는데, 이번에는 MCP 서버 전용으로 범위가 지정된 토큰을 사용합니다.
포트폴리오 MCP 서버는 사용자의 특정 포트폴리오 데이터를 반환합니다.
전체 감사 내역이 있습니다. 모든 홉은 원래 최종 사용자에게 귀속됩니다.

이것이 중요한 이유: OBO 토큰 교환이 없으면 최소 권한을 위반하는 원래 토큰 전달 또는 사용자 ID를 잃을 위험이 있는 서비스 계정 사용 중에서 선택해야 합니다. OBO 패턴은 사용자의 ID가 모든 홉에 유지되고 각 토큰이 대상으로 범위가 지정되며 에이전트 자체가 ID 메커니즘을 완전히 인식하지 못하므로 이러한 제약을 제거합니다.

모든 다운스트림 서비스에는 사용자 컨텍스트가 필요하지는 않습니다. 사용자는 Finport 에이전트에게 _“현재 시장 동향은 무엇입니까?”_라고 질문합니다. 시나리오 1의 포트폴리오 요청과 달리, 시장 추세 데이터는 사용자에 따라 다르지 않으면 공개됩니다. 다운스트림 Market Data Agent 및 Asset Market MCP Server는 사용자 범위 토큰이 필요하지도 않고 요구되지도 않습니다.

사용자 토큰이 필요하지 않은 곳에 전파하면 공격 영역이 확장됩니다.

Finport Agent Broker가 시나리오 1의 OBO 패턴을 사용하여 사용자의 토큰을 Market Data Agent에 전파한다면 작동하지만 불필요합니다. 토큰이 필요하지 않은 위치에서 사용자 토큰을 전파하면 공격 표면이 확장되고 토큰 교환에 대한 IdP에 불필요한 종속성이 생성되며 최소 권한 원칙이 위반됩니다. 마켓 데이터 에이전트는 요청이 어떤 사용자가 요청하는 것이 아니라 권한이 있는 서비스에서 온다는 것을 알고 있어야 합니다.

Flex Gateway의 아웃바운드 OAuth 2.0 클라이언트 자격 증명 정책은 이를 투명하게 처리합니다. 정책은 사용자의 토큰을 교환하는 대신 클라이언트 자격 증명 부여를 통해 중개인의 자체 서비스 자격 증명을 발신 요청에 입력합니다. 다운스트림 시장 데이터 에이전트는 사용자 ID가 필요하지 않으므로 전파되지 않은 상태에서 올바르게 인증된 서비스 수준 토큰을 수신합니다.

주요 아키텍처 이점: ID 전파 전략은 일대일이 아니라 데이터의 특성 및 대상 서비스의 요구 사항을 기반으로 다운스트림 경로별로 결정됩니다. Flex 게이트웨이의 아웃바운드 정책을 사용하면 경로별로 구성할 수 있습니다. 같은 Finport 에이전트 브로커는 코드 변경 없이 OBO 플로(시나리오 1) 및 S2S 플로에 모두 참여할 수 있습니다. 출력 게이트웨이의 정책 구성에 따라 다운스트림 호출에 적용되는 패턴이 결정됩니다.

플로:

사용자는 Finport 에이전트에게 _“현재 시장 추세는 무엇입니까?”_라고 질문합니다.
중개인은 요청을 처리하기 위해 시장 데이터 에이전트가 필요함을 판단합니다.
Flex Gateway의 아웃바운드 클라이언트 자격 증명 정책은 중개인의 자체 자격 증명을 사용하여 서비스 수준 토큰을 가져옵니다(사용자 토큰이 교환되거나 전파되지 않음).
시장 데이터 에이전트가 적절하게 인증된 서비스 요청을 수신하고 자산 시장 MCP 서버를 호출합니다.
자산 시장 MCP 서버가 공개 시장 데이터를 반환합니다.
이 유형의 데이터에는 필요하지 않으므로, 설계에 따라 체인 내에 사용자 ID가 존재하지 않습니다.

이것이 중요한 이유: Flex Gateway의 정책 중심 프레임워크는 아키텍트가 모든 상호 작용에 대해 최적의 ID 모델을 선택할 수 있도록 하여, 오버헤드와 보안 위험을 증가시키는 전체 사용자 토큰 전파와 사용자 컨텍스트 및 규정 준수를 희생하는 전역 서비스 계정 사용 사이의 어려운 선택을 해결할 수 있게 합니다.

가장 복잡한 ID 시나리오는 에이전트가 기존 사용자 토큰을 인식하지 않는 완전히 다른 IdP로 관리되는 시스템과 상호 작용해야 하는 경우에 발생합니다.

시나리오: Finport 사용자는 Finport 에이전트에게 _“내 외부 저축 계좌로 $5,000를 이체해 주세요.”_라고 요청합니다. 이 요청에는 다음과 같은 두 가지 고유한 다운스트림 경로가 포함됩니다.

사용자의 자산을 확인하는 포트폴리오 서비스 에이전트(OBO) 경로
실제 이체를 실행하기 위한 트랜잭션 에이전트 → 트랜잭션 MCP 서버 → 사용자의 은행 경로

트랜잭션 에이전트는 자체 IdP를 사용하는 사용자의 은행과 상호 작용해야 합니다. 사용자의 Finport Okta 토큰은 은행 시스템에 의미가 없습니다. 은행은 Finport의 IdP와 신뢰 관계가 없기 때문입니다. OBO 패턴(스테이너리오 1)이나 S2S 패턴(스테이너리오 2)은 이 문제를 해결할 수 없습니다. OBO는 동일한 IdP 내에서 토큰을 교환하며, S2S는 사용자 ID를 전혀 가져오지 않는 서비스 자격 증명을 사용합니다. 은행에서는 사용자가 MFA를 포함한 자체 은행 자격 증명을 사용하여 직접 인증해야 합니다.

Flex Gateway의 Outbound A2A In-Task Authorization Code 정책은 에이전트 대화 내에서 challenge-response 메커니즘을 사용합니다. 은행에 연락할 때 보조 토큰이 누락된 경우, 정책이 인증 필요 챌린지를 반환합니다. 이 챌린지에는 클라이언트가 은행 공급자와 OAuth 2.0 플로우를 시작할 수 있도록 끝점, 범위, PKCE 매개 변수와 같은 모든 필수 세부 사항이 포함됩니다.

그런 다음 Finport 앱에 직접 사용자 인증을 위해 은행의 로그인 인라인이 표시됩니다. 완료되면 클라이언트가 A2A 요청에서 토큰을 반환합니다. 정책은 은행 시스템에 대해 이 토큰을 추출하고 메시지 본문에서 제거하여 보안을 유지합니다.

핵심 아키텍처 이점: 게이트웨이 정책 계층은 전체 교차 도메인 인증 프로세스를 오케스트레이션하여 중개인이나 에이전트가 원시 자격 증명과 상호 작용하거나 은행의 IdP에 대한 정보를 요구하지 않도록 합니다. 이 챌린지-응답 프레임워크를 사용하면 사용자는 완전한 통제권을 유지하면서, 외부 시스템 인증 시 명시적으로 동의하고, 결과 토큰은 정책 계층을 통해 안전하게 전송됩니다.

흐름:

사용자가 Finport에 이체를 시작하도록 요청합니다. 요청은 중개자를 통해 흐릅니다.
중개자는 Portfolio (OBO)를 사용하여 보유 자산을 확인하고, Transaction (In-Task)를 사용하여 이체를 실행합니다.
트랜잭션 경로는 Flex Gateway의 In-Task 정책에서 인증 요구 챌린지를 발생시킵니다.
이 챌린지는 Finport 애플리케이션으로 전파되어, 사용자에게 인라인 방식으로 은행의 로그인 플로우를 제공합니다.
사용자는 필요 시 다중 인증(MFA)을 포함하여 은행에서 인증합니다.
은행 토큰은 후속 A2A 요청에 포함됩니다. 정책이 토큰을 추출하여 권한 부여 헤더에 설정한 후 요청을 전달합니다.
트랜잭션 MCP 서버가 은행 토큰을 포함한 요청을 수신하고 이체를 실행합니다.

이것이 중요한 이유: 교차 도메인 ID는 에이전트 아키텍처의 주요 과제입니다. 작업 내 인증이 없으면, 기업은 네트워크 내의 모든 IdP 간에 복잡한 신뢰 관계를 사전에 구축하거나, 사용자가 에이전트에 은행 자격 증명을 제공하도록 요청해야 합니다. In-Task 패턴은 외부 공급자와의 사용자 직접 인증을 허용하여 문제를 해결합니다. 동시에 정책은 토큰 메커니즘을 관리하며, 에이전트는 외부 신원 도메인과 분리되어 유지됩니다.

모든 세 가지 시나리오에서 한 가지 아키텍처 원칙이 적용됩니다: ID 전파는 게이트웨이 계층에서 적용되며 에이전트나 서비스 내에서는 적용되지 않습니다. 에이전트 및 MCP 서버에는 인증 논리가 전혀 포함되어 있지 않습니다. 역할은 인증된 요청을 처리하고 결과를 반환하도록 제한되지만 Flex 게이트웨이 아웃바운드 정책 계층은 모든 ID 관련 작업을 관리합니다.

Flex Gateway의 아웃바운드 인증 정책은 에이전트가 라우팅 결정을 내린 후, 요청이 다운스트림 서비스에 도달하기 전에 올바른 지점에서 트래픽을 가로채기하기 때문에 작동합니다. 정책은 토큰을 변환합니다—OBO 교환, 클라이언트 자격 증명 주입, 또는 과업 내 챌린지-응답—그리고 올바르게 인증된 요청을 전달합니다. 다운스트림 서비스는 차이를 알지 못하므로 에이전트는 걱정할 필요가 없습니다. 인증 로직은 서비스에 분산되어 있지 않고, 게이트웨이에서 중앙 집중적으로 관리됩니다. 백엔드 서비스에는 코드 변경이 필요하지 않으며 동일한 정책 구성을 여러 경로에서 재사용할 수 있습니다.

이 접근 방식은 프로토콜에 구애받지 않습니다. 정책은 HTTP 레이어에서 작동하므로 에이전트가 REST, MCP, A2A 또는 웹후크를 통해 커뮤니케이션하는지 여부에 따라 일관되게 적용됩니다. Agent Fabric Deep Dive에서 설명한 바와 같이 모든 A2A 및 MCP 트래픽은 모든 엔드포인트에 정책이 적용되도록 Flex 게이트웨이를 통해 라우팅됩니다. 즉, ID 전파는 통신 프로토콜에 관계없이 일관되게 적용됩니다.

구성 가능한 세 가지 패턴은 에이전트 아키텍처의 전체 ID 요구 사항 스펙트럼에 적용됩니다.

패턴	정책	사용자 ID	사용자 상호 작용	사용 사례
On-Behalf-Of (OBO)	OAuth 2.0 OBO 자격 증명 주입 정책	유지됨	없음(투명)	동일한 Trust 도메인 내의 사용자별 데이터
서버 간 서버(S2S)	아웃바운드 OAuth 2.0 클라이언트 자격 증명	전파되지 않음	없음	공개 데이터, 시스템 수준 작업
작업 내 인가 코드	아웃바운드 A2A 작업 내 인가 코드	기본 + 보조	필수(인라인 인증)	교차 도메인, 다중 ID 공급자, 고위험 작업

이러한 패턴은 상호 배타적이지 않습니다. Finport 시나리오에서 알 수 있듯이, 단일 에이전트 브로커는 하나의 다운스트림 호출에 OBO를, 다른 호출에는 S2S를, 세 번째 호출에는 In-Task를 사용할 수 있습니다. 각 아웃바운드 경로의 정책 구성에 따라 적용되는 패턴이 결정됩니다. 에이전트 코드 변경 사항 및 서비스 수정 사항은 없으며 정책만 있습니다.

위에 설명된 게이트웨이 적용 패턴은 개별 상호 작용을 안전하게 유지하지만, ID 전파는 고립된 문제가 아닙니다. 광범위한 MuleSoft Agent Fabric 거버넌스 모델의 기본 계층입니다. Agent Fabric Deep Dive에서 설명한 바와 같이 Agent Fabric은 다음 네 가지 기둥에 기반합니다. 검색, 오케스트레이션, 관리, 관찰, 각각 효과적으로 작동하려면 신뢰할 수 있는 신원 체인에 의존합니다.

검색: 에이전트 레지스트리는 에이전트 및 해당 기능을 카탈로그화합니다. 인증 요구 사항을 포함하는 에이전트 메타데이터를 사용하면 중개인이 각 에이전트가 기대하는 ID 패턴을 이해할 수 있습니다.
오케스트레이트: 에이전트 브로커는 다중 에이전트 워크플로를 조정합니다. Flex 게이트웨이는 각 홉에서 신원 변환을 투명하게 처리하므로, 에이전트 브로커는 과업 분해 및 라우팅에 집중할 수 있습니다.
관리: 대상 시스템이 안전하지 않은 경우에도 모든 A2A 및 MCP 트래픽이 Flex 게이트웨이를 통해 라우팅되어 모든 엔드포인트에 정책이 적용되도록 합니다. 아웃바운드 인증 정책은 거버넌스 계층의 일부입니다.
관찰: 에이전트 시각화 도구는 동적이고 대화형인 에이전트 상호 작용 맵을 통해 실시간 모니터링을 제공합니다. 각 홉에서 사용자 신원이 유지되므로, 추적 및 로그는 에이전트 네트워크 전반에 걸쳐 사용자 식별이 가능한 감사 추적을 제공합니다.

신뢰할 수 있는 신원 전파가 없으면 거버넌스가 불완전합니다. 에이전트를 카탈로그 및 오케스트레이션할 수 있지만, 사용자의 권한 부여 범위 내에서 작업할 수는 없습니다. 신뢰할 수 있는 에이전트 ID는 이 격차를 해소하여 보안 및 사용자 컨텍스트가 에이전트 워크플로의 중심이 될 수 있도록 합니다.

다음 패턴 구현:

아웃바운드 정책 디렉터리를 이해하십시오. Flex Gateway에 사용할 수 있는 전체 아웃바운드 인증 정책을 검토하십시오.
OBO로 시작하세요. OAuth 2.0 토큰 교환 정책은 가장 일반적인 신원 전파 요구 사항인 에이전트 홉 전반의 사용자 컨텍스트 보존을 해결합니다.
교차 도메인 시나리오에 In-Task 추가: 에이전트 네트워크가 신뢰 경계를 넘을 경우, A2A 작업 내 인가 코드 정책은 사용자로부터 보조 자격 증명을 얻기 위한 챌린지-응답 메커니즘을 제공합니다.
에이전트 패브릭 활용. 경로당 ID 모델을 지정하는 정책 구성을 사용하여 agent-network YAML에서 에이전트 네트워크를 정의합니다. 플랫폼에서 나머지를 처리합니다.

세부적인 구현 지침은 동반 구현 가이드를 참조하십시오.

Nikhil Aggarwal은 MuleSoft 및 Salesforce Automation Cloud의 아키텍처를 이끄는 Salesforce의 유명 엔지니어입니다. Nikhil은 대규모 제품을 제공하는 데 18년 이상의 경험을 보유하고 있으며 확장 가능한 아키텍처, 직관적인 개발자 경험, 고성능 팀 구축에 열정적입니다. Salesforce 이전에는 Microsoft Power Platform, Dataverse 및 Office 365의 여러 이니셔티브를 개념부터 출시까지 이끌었습니다. 그의 작업은 AI 우선 시대에 현대 기업이 시스템을 연결하고, 워크플로를 자동화하며, 비즈니스 가치를 창출하는 방식을 지속적으로 형성하고 있습니다.

Akash Trivedi는 Salesforce의 엔지니어링 디렉터로서 확장 가능하고 안전하며 고성능 엔터프라이즈 시스템 구축에 18년 이상의 경험을 보유하고 있습니다. AI, 엔터프라이즈 아키텍처, 프로세스 인텔리전스의 교차 지점에서 작업하며, 대규모로 작동하는 클라우드 네이티브 플랫폼 및 신뢰할 수 있는 솔루션에 중점을 둡니다. Salesforce 이전에는 Copilot, Dataverse, Power Platform을 비롯한 제품에 기여한 Microsoft에서 엔지니어링 역할을 담당했습니다.