Удостоверение надежного агента для предприятия-агента

По мере внедрения предприятиями агентурной парадигмы возникает новая проблема безопасности: Каким образом удостоверение конечного пользователя проходит через сеть автономных агентов искусственного интеллекта? В традиционных архитектурах API пользователь проходит проверку подлинности один раз, и приложение вызывает фоновые службы от имени пользователя. Цепочка удостоверений коротка, понятна и обычно управляется в одном домене Trust. Агентская архитектура, однако, содержит гораздо более длинные цепочки, когда один запрос проходит веером по разным серверам агентов, служб и Model Context Protocol (MCP), каждый из которых потенциально пересекает сервисные границы, домены Trust и даже организационные границы. Без преднамеренной стратегии распространения удостоверений предприятия стоят перед выбором между безопасностью и функциональностью – дилеммой, с которой не должен сталкиваться архитектор.

MuleSoft решает проблемы распространения удостоверений с помощью функции «Надежное удостоверение агента». Это решение использует стратегию на основе политики, управляемую шлюзом, чтобы обеспечить сохранение идентификации конечного пользователя в разных типах взаимодействия, включая протоколы взаимодействия между агентами (A2A), вызовы инструментов MCP и запросы REST API.Централизация управления удостоверениями на уровне Flex Gateway посредством исходящих политик проверки подлинности позволяет предприятиям обезопасить всю сеть агентов, не изменяя базовых служб или агентов.

Этот документ проходит испытание распространения удостоверений с помощью постепенной последовательности сценариев, каждый из которых добавляет дополнительную сложность. Вместе эти сценарии иллюстрируют, почему идентификация надежного агента является основополагающим требованием для любого развертывания агента в масштабах предприятия.

В обычном приложении поток идентификации (поток OAuth JWT) является простым: Пользователь входит, получает маркер, а приложение использует маркер для доступа к фоновым ресурсам. Маркер встраивается в удостоверение пользователя (включая его личность и полномочия) и перемещается при каждом запросе. Цепочка вызовов короткая, обычно один или два прыжка, и распространение удостоверений решено.

Агентская архитектура, однако, содержит гораздо более длинные цепочки вызовов, где один запрос пользователя может веериться на разных серверах агентов, серверах серверных служб и серверах протокола контекста модели (MCP).Каждое назначение запроса представляет собой отдельный переход. Хотя эти проблемы (например, распространение мульти- скачковых удостоверений, смешанные модели авторизации, междоменные границы Trust) распространены в любой настройке распределенного API, отличительной чертой является то, как нынешняя экосистема реагирует по умолчанию.. Сегодня доминирующая схема связи между агентом и между агентом и API зависит от учетных данных клиента, ключей API или общедоступных секретов. Это означает:

По умолчанию удостоверение пользователя теряется. Когда агент вызывает сервер MCP или API в нисходящем направлении посредством регистрационных данных клиента, запрос несет удостоверение службы агента, а не конечного пользователя. Служба в нисходящем направлении не может узнать, какой пользователь инициировал действие, что делает невозможным авторизацию и контрольные журналы для каждого пользователя.
Смешанные потребности авторизации игнорируются. Не каждая служба в нисходящем направлении требует пользовательского контекста.В то время как некоторые управляют пользовательской информацией, например, транзакциями или портфолио, другие предоставляют общедоступные или системные данные, например, справочный материал или тенденции рынка.Поскольку текущий стандарт зависит исключительно от регистрационных данных клиента, нет способа различать эти потребности или выборочно распространять удостоверение пользователя только при необходимости.
Границы доверия между доменами не рассматриваются. Агентам в B2B и регулируемых сценариях может понадобиться взаимодействовать с системами, управляемыми полностью отдельными поставщиками удостоверений (IdP). Например, внешняя банковская система не может интерпретировать корпоративный маркер единой регистрации (SSO), но должна получить согласие и намерение пользователя. Поток регистрационных данных клиента не имеет механизма для этого.

Результатом этого является разрыв между требованием предприятия к доступу, приписываемому пользователю и имеющему наименьшие привилегии, и зависимостью нынешней экосистемы от проверки подлинности на уровне обслуживания, не имеющей пользовательского контекста. Для устранения этого пробела необходим продуманный многоуровневый подход к распространению удостоверений. Для иллюстрации этих концепций в следующих сценариях используется вымышленное приложение финтеха " Финпорт "; , позволяющее получить практические примеры этих архитектурных моделей.

Finport - это вымышленное веб-приложение для управления портфолио Fintech, ориентированное на потребителей и поддерживаемое агентской архитектурой. Агент Брокер (созданный посредством MuleSoft Agent Broker) координирует несколько агентов в нисходящем направлении и серверы MCP для выполнения запросов пользователей.

Finport открывает три основные функции, каждая из которых имеет разные требования к идентификации:

"Покажи мне мое портфолио." Пользователь запрашивает личные фонды и журнал транзакций. Поскольку эти данные характерны для пользователя, агент обслуживания портфолио и сервер MCP портфолио в нисходящем направлении должны знать, какие данные пользователя возвращать, и должны проверить наличие у пользователя полномочия на доступ к ним. Удостоверение пользователя должно распространяться через каждый переход.
"Каковы текущие тенденции рынка?": Пользователь запрашивает общедоступные данные рынка и цены активов. Поскольку данные являются общедоступными и не меняются в зависимости от пользователя, агент Market Data и сервер MCP рынка активов в нисходящем направлении не нуждаются и не ожидают маркера в масштабе пользователя. Для этого достаточно собственных регистрационных данных брокера.
"Перевести $5,000 на мой внешний сберегательный счет.": Пользователь инициирует перевод средств в банк, использующий другой IdP (например, Auth0 вместо Okta). Маркер Finport пользователя не имеет смысла для системы банка. Пользователь должен пройти проверку подлинности напрямую в банке (встроенном в разговор), прежде чем перевод будет продолжен.

Каждая из этих функций соотносится с отдельной схемой распространения удостоверения. Следующие сценарии развиваются постепенно от стандартного базиса (без агентов) по каждой отдельной схеме, иллюстрируя, как исходящие политики в Flex Gateway учитывают каждое требование, не изменяя агентов или базовые службы.

Прежде чем представить агентов, необходимо установить базовый уровень: пользователь, авторизующийся посредством клиентского приложения и имеющий доступ к базовой службе.

Поток:

Пользователь открывает Finport и перенаправляется на страницу входа IdP (например, Okta) .
Пользователь проходит проверку подлинности (имя пользователя, пароль, единый вход, многофакторная проверка подлинности (MFA) и любые другие требования).
IdP выдает подписанный маркер доступа JWT приложению Finport.
Теперь у Finport есть маркер пользователя, представляющий личность пользователя: кто они, какие области им были предоставлены и когда истекает срок действия маркера. Он может представить его любой службе в нисходящем направлении от имени этого пользователя.

Что это создает: Этот процесс соответствует стандартной схеме архитектуры OAuth 2.0. Первичный маркер пользователя, проверенный надежным IdP, служит важной основой для всех последующих операций. Каждый последующий сценарий основан на этом маркере.

Спрос: После проверки подлинности пользователь инициирует такие действия, как переводы средств, анализ рынка или проверки портфолио. Эти запросы обрабатываются посредством агента-брокера и могут быть связаны с несколькими агентами в нисходящем направлении или серверами MCP. В связи с этим возникают важные вопросы: Как обеспечивается идентификация пользователя в данных распределенных запросах? Что происходит, когда служба в нисходящем направлении использует совершенно другой IdP?

Пользователь просит агента Finport "Показать портфолио". Это взаимодействие запускает опорную цепочку, начиная с агента Финпорта, созданного посредством агента Финпорт. Брокер передает задачу агенту обслуживания портфелей, который, в свою очередь, запрашивает сервер MCP портфолио. Первичный маркер проверки подлинности пользователя теперь должен пройти через несколько переходов для доступа к запрошенным записям портфолио.

Передача исходного маркера нарушает принцип наименьших прав, в то время как использование учетной записи службы теряет личность пользователя.

Агент Finport получает маркер пользователя, но он не может просто переслать этот же маркер агенту обслуживания портфолио, поскольку это нарушит принцип наименьших привилегий и не будет надлежащим образом объемом запроса на обслуживание в нисходящем направлении. И наоборот, использование учетной записи службы приводит к полной потере подлинности пользователя. Агент обслуживания портфелей и сервер MCP портфолио не будут иметь возможности узнать, какому пользователю возвратить портфель, и контрольный журнал будет приписывать каждое действие идентификации обслуживания брокера, а не конечного пользователя.

Flex Gateway разрешает эти сложности распространения удостоверений прозрачно посредством политики обмена маркерами OAuth 2.0. Это решение перехватывает исходящие запросы на каждом переходе в цепочке вызовов, обменивая входящий маркер пользователя с IdP на новые регистрационные данные, ограниченные специально для службы в нисходящем направлении. Политика On-Behal-Of (OBO) поддерживает протоколы OAuth 2.0 Token Exchange (RFC 8693) и Microsoft Entra ID On-Behald-Of.

Ключевое архитектурное преимущество: Весь процесс обрабатывается исходящей политикой Flex Gateway. Брокер и агенты содержат нулевую логику проверки подлинности. Вместо этого они фокусируются исключительно на бизнес-логике, в то время как уровень шлюза внедряет распространение удостоверений.

Поток:

Пользователь авторизуется посредством Okta, а приложение Finport отправляет запрос через Flex Gateway.
Брокер получает проверенный пользовательский маркер и определяет необходимость агента обслуживания портфолио.
Политика исходящего OBO Flex Gateway обменивает маркер пользователя с IdP на маркер, относящийся к агенту обслуживания портфолио.
Агент обслуживания портфолио получает корректно объемный маркер и вызывает MCP-сервер портфолио.
Flex Gateway снова обменивает маркер, на этот раз ограниченный сервером MCP.
Сервер Portfolio MCP возвращает определенные данные портфолио пользователя.
Существует полный контрольный журнал. Каждый переход относится к исходному конечному пользователю.

Почему это важно: Без обмена маркерами OBO предприятия должны выбирать между пересылкой исходного маркера, нарушающего наименьшие привилегии, или использованием учетных записей службы, что может потерять личность пользователя. Схема OBO устраняет это компромиссное решение, поскольку личность пользователя сохраняется при каждом переходе, каждый маркер ограничен целевым значением, а сами агенты остаются совершенно не в курсе механики идентификации.

Не каждая служба в нисходящем направлении требует пользовательского контекста. Пользователь спрашивает агента Finport: "Каковы современные тенденции рынка?" В отличие от запроса портфеля в сценарии 1, данные рыночных тенденций являются общедоступными, если они не меняются в зависимости от пользователя. Агент данных рынка и сервер MCP рынка активов в дальнейшем не нуждаются и не ожидают наличия маркера в масштабе пользователя.

Распространение маркеров пользователя там, где они не нужны, расширяет область атаки.

Если брокер-агент Финпорта передаст маркер пользователя агенту Market Data посредством схемы OBO из сценария 1, это сработает, но будет ненужно. Распространение маркеров пользователей там, где они не нужны, расширяет поверхность атаки, создает ненужные зависимости от IdP для обмена маркеров и нарушает принцип наименьших привилегий. Агент Market Data просто должен знать, что запрос поступает от авторизованной службы, а не от того, какой пользователь спрашивает.

Политика исходящих регистрационных данных клиента OAuth 2.0 Flex Gateway обрабатывает их прозрачно. Вместо обмена маркера пользователя политика впрыскивает собственные регистрационные данные брокера посредством предоставления регистрационных данных клиента в исходящий запрос. Агент Market Data в нисходящем направлении получает надлежащим образом проверенный маркер уровня обслуживания, где удостоверение пользователя не распространяется, поскольку оно не нужно.

Ключевое архитектурное преимущество: Стратегия распространения удостоверений не является универсальной, скорее она определяется для маршрута в нисходящем направлении на основе природы данных и требований целевой службы. Исходящие политики Flex Gateway делают это настраиваемым для каждого маршрута. Один и тот же брокер-агент Finport может участвовать в потоках OBO (в сценарии 1) и S2S без изменений кода. Конфигурация политики в шлюзе выхода определяет схему, применяемую к вызову в нисходящем направлении.

Поток:

Пользователь спрашивает агента Финпорта: "Каковы современные тенденции рынка?"
Брокер определяет, что агент Market Data необходим для выполнения запроса.
Политика исходящих регистрационных данных клиента Flex Gateway получает маркер уровня обслуживания посредством собственных регистрационных данных брокера (маркер пользователя не обменивается и не распространяется).
Агент Market Data получает надлежащим образом проверенный запрос на обслуживание и вызывает сервер MCP рынка активов.
Сервер MCP рынка активов возвращает общедоступные данные рынка.
Удостоверение пользователя отсутствует в цепочке намеренно, поскольку оно не нужно для этого типа данных.

Почему это важно: Инфраструктура Flex Gateway, управляемая политикой, позволяет архитекторам выбирать оптимальную модель удостоверения для каждого взаимодействия, разрешая сложный выбор между универсальным распространением маркера пользователя, что повышает риски накладных расходов и безопасности, и глобальным использованием учетной записи службы, которая жертвует контекстом пользователя и соответствием.

Самый сложный сценарий удостоверения возникает, когда агенту нужно взаимодействовать с системой, управляемой совершенно другим IdP, которая не распознает существующий маркер пользователя.

Сценарий: Пользователь Finport просит агента Finport "Перевести 5 000 долларов на мой внешний сберегательный счет". Этот запрос включает два отдельных последующих пути:

Путь агента обслуживания портфолио (OBO) для проверки фондов пользователя
Путь агента транзакций → сервера MCP транзакций → банка пользователя для выполнения фактической передачи

Агент транзакций должен взаимодействовать с банком пользователя, использующим собственный IdP. Маркер Okta пользователя из "Финпорта" бессмыслен для системы банка, так как у банка нет отношений Trust с IdP "Финпорта". Ни схема OBO (из сценария 1), ни схема S2S (из сценария 2) не могут решить эту проблему. OBO обменивается маркерами в одном IdP, а S2S использует регистрационные данные службы, которые не несут удостоверения пользователя. Банк требует, чтобы пользователь проходил проверку подлинности напрямую с помощью собственных банковских регистрационных данных, в том числе потенциально MFA.

Политика исходящего кода авторизации A2A в задаче в Flex Gateway использует механизм вызова-ответа в разговоре агента. Если дополнительный маркер отсутствует при обращении в банк, полис возвращает обязательный для проверки подлинности вызов. Эта задача содержит все необходимые сведения (например, конечные точки, области и параметры PKCE), чтобы клиент инициировал поток OAuth 2.0 с поставщиком банка.

Приложение Finport потом отображает встроенный вход банка для прямой проверки подлинности пользователя. После завершения клиент возвращает маркер в запросе A2A. Политика извлекает этот маркер для системы банка и удаляет его из текста сообщения для обеспечения безопасности.

Ключевое архитектурное преимущество: Уровень политики шлюза оркестрирует весь процесс междоменной проверки подлинности, обеспечивая, что ни брокер, ни агенты никогда не будут взаимодействовать с исходными регистрационными данными и не потребуют Knowledge о IdP банка. Используя эту инфраструктуру вызова и ответа, пользователи сохраняют полный контроль: они предоставляют явное согласие на проверку подлинности с помощью внешних систем, в то время как результирующий маркер безопасно передается через уровень политики.

Поток:

Пользователь просит Finport инициировать передачу. Запрос проходит через брокера.
Брокер веерирует, используя портфель (OBO) для проверки фондов, а транзакцию (в задаче) для выполнения передачи.
Путь транзакции запускает обязательный для проверки подлинности вызов из политики в задаче в Flex Gateway.
Задача распространяется обратно в приложение Finport, которое представляет поток входа банка пользователю встроенным способом.
Пользователь проходит проверку подлинности в своем банке, включительно с MFA, при необходимости.
Банковский маркер добавляется в последующий запрос A2A. Политика извлекает его, устанавливает в заголовке авторизации и пересылает запрос.
Сервер MCP транзакций получает запрос с маркером банка и выполняет передачу.

Почему это важно: Междоменная идентификация является серьезной проблемой в агентской архитектуре. Без проверки подлинности в задаче предприятия должны либо предварительно установить сложные отношения Trust между каждой сетью IdPin, либо попросить пользователей предоставить банковские регистрационные данные агенту. Шаблон «В задаче» решает эту проблему, разрешая прямую проверку подлинности пользователя с внешними поставщиками; политика управляет механикой маркера, сохраняя агентов оторванными от внешних доменов удостоверения.

Во всех трех сценариях единый архитектурный принцип соответствует: Распространение удостоверений внедряется на уровне шлюза, а не внутри агентов или служб. Агенты и серверы MCP содержат нулевую логику проверки подлинности. Их роль ограничена обработкой проверенных запросов и возвратом результатов, в то время как уровень исходящей политики Flex Gateway управляет всеми операциями, связанными с удостоверениями.

Это работает, поскольку политики исходящей проверки подлинности Flex Gateway перехватывают трафик в нужной точке: после принятия агентом решения о маршрутизации, но до того, как запрос достигнет службы нисходящего направления. Политика трансформирует маркер, будь то обмен OBO, внедрение регистрационных данных клиента или ответ вызова в процессе работы, и пересылает корректно проверенный запрос. Служба в нисходящем направлении никогда не знает разницы, поэтому агенту не нужно заботиться. Логика проверки подлинности централизована у шлюза, а не разбросана по службам. Базовые службы не требуют изменений кода, и одну конфигурацию политик можно повторно использовать в нескольких маршрутах.

Этот метод также является протокольным агностическим. Поскольку политики работают на уровне HTTP, они применяются последовательно, независимо от того, общается ли агент посредством REST, MCP, A2A или веб-хуков. Как задокументировано в разделе «Глубокое изучение ткани агента», весь трафик A2A и MCP перенаправляется через Flex Gateway для обеспечения применения политик к каждой конечной точке, то есть распространение удостоверений внедряется единообразно, вне зависимости от протокола связи.

Три составные схемы охватывают весь спектр требований к идентификации в агентской архитектуре:

Схема	Политика	Удостоверение пользователя	Взаимодействие с пользователем	Способ использования
От имени (OBO)	Политика впрыска регистрационных данных OAuth 2.0 OBO	Сохранено	Нет (прозрачный)	Пользовательские данные в одном домене Trust
Server-to-Server (S2S)	Исходящие регистрационные данные клиента OAuth 2.0	Не распространено	Нет	Общедоступные данные, операции системного уровня
Код авторизации в задаче	Исходящий код авторизации A2A в задаче	Основная + средняя	Обязательно (встроенная проверка подлинности	Междоменные операции с многофакторным поставщиком удостоверений и высокой степенью риска

Эти схемы не являются взаимоисключающими. Как показывают сценарии Finport, один брокер-агент может использовать OBO для одного последующего вызова, S2S для другого и In-Task для третьего. Конфигурация полиса для каждого исходящего маршрута определяет применяемую схему. Нет изменений кода агента и изменения обслуживания, только политика.

Вышеописанные схемы внедрения шлюза обеспечивают безопасность взаимодействия отдельных лиц, но распространение удостоверений не является изолированной проблемой. Это базовый слой более широкой модели управления тканью агента MuleSoft. Как описано в разделе «Глубокое погружение ткани агента», ткань агента построена на четырех столпах: Обнаружение, оркестрация, управление и наблюдение, и каждое из них зависит от надежной цепочки удостоверений для эффективного функционирования.

Обнаружение: Реестр агентов каталогизирует агентов и их возможности. Метаданные агента, включая требования проверки подлинности, позволяют брокерам понять, какие схемы идентификации ожидает каждый агент.
Оркестр: Агент Брокер координирует бизнес-процессы нескольких агентов. Flex Gateway прозрачно обрабатывает трансформацию удостоверения при каждом переходе, поэтому брокер может сосредоточиться на декомпозиции задач и маршрутизации.
Управление: Весь трафик A2A и MCP перенаправляется через Flex Gateway, даже если целевая система небезопасна, чтобы обеспечить применение политик к каждой конечной точке. Политики исходящей проверки подлинности являются частью уровня управления.
Наблюдать: Agent Visualizer предоставляет возможность наблюдения в режиме реального времени посредством динамической интерактивной карты взаимодействий агентов. При сохранении подлинности пользователя при каждом переходе журналы и журналы предоставляют контрольные журналы, приписываемые пользователю, в сети агентов.

Без надежного распространения удостоверений управление будет неполным. Вы можете каталогизировать и оркестровать агентов, но не можете обеспечить их действия в пределах авторизации пользователя. Trusted Agent Identity устраняет этот пробел, обеспечивая безопасность и контекст пользователя в качестве центрального элемента бизнес-правил агента.

Для внедрения следующих схем:

Понимание каталога исходящих политик. Просмотрите полный набор политик исходящей проверки подлинности, доступных для Flex Gateway.
Начните с OBO. Политика обмена маркерами OAuth 2.0 учитывает наиболее распространенные потребности в распространении удостоверений: сохранение контекста пользователя в прыжках агента.
Добавление внутрипрограммных сценариев для междоменных сценариев: Когда сеть агентов пересекает границы Trust, политика кода авторизации A2A предоставляет механизм вызова-ответа для получения дополнительных регистрационных данных от пользователя.
Использование ткани агента. Определите сеть агентов в сети агентов YAML с конфигурациями политик, определяющими модель удостоверения для каждого маршрута. Остальное обрабатывает платформа.

Подробные рекомендации по внедрению см. в руководстве по внедрению.

Никхил Аггарвал является выдающимся инженером в Salesforce, где он возглавляет архитектуру MuleSoft и Salesforce Automation Cloud. Компания Nikhil обладает более чем 18-летним опытом производства масштабных продуктов и увлечена масштабируемой архитектурой, интуитивно понятным опытом разработчиков и созданием высокопроизводительных рабочих групп. До Salesforce он возглавлял несколько инициатив в Microsoft Power Platform, Dataverse и Office 365 от концепции до запуска. Его работа продолжает определять, как современные предприятия соединяют системы, автоматизируют бизнес-правила и разблокируют ценность бизнеса в эпоху искусственного интеллекта.

Акаш Триведи является директором по инжинирингу Salesforce с более чем 18-летним опытом создания масштабируемых, безопасных и высокопроизводительных корпоративных систем. Он работает на пересечении искусственного интеллекта, корпоративной архитектуры и интеллектуальных процессов, уделяя особое внимание облачным платформам и надежным решениям, действующим в масштабе. До Salesforce он занимал инженерные должности в Microsoft, где участвовал в создании продуктов, включая Copilot, Dataverse и Power Platform.