Идентичность агента после MCP и A2A: кто на самом деле уполномочен действовать от имени пользователя

Пользователь просит агента оплатить счёт. Оркестратор передаёт подзадачу удалённому A2A-агенту, тот вызывает MCP-инструмент, а инструмент обращается к платёжному API. На последнем шаге API видит корректный OAuth-токен — но этого недостаточно, чтобы ответить на главный вопрос: кто именно разрешил перевести конкретную сумму конкретному получателю?

Токен может подтверждать право клиента вызвать API. SPIFFE ID — идентичность исполняемого процесса. A2A Agent Card — возможности и способы аутентификации агента. Trace ID — технический маршрут запроса. Ни один из этих элементов по отдельности не доказывает, что данный агент действует по ограниченному поручению данного пользователя.

MCP и A2A закрывают важные, но разные части задачи. MCP формализует OAuth-ориентированный доступ к ресурсу и запрещает транзитную передачу пользовательского токена. A2A стандартизирует обнаружение агентов и обмен задачами. Сквозную семантику делегирования между пользователем, оркестратором, агентами и инструментами должна построить прикладная архитектура.

Идентичность, авторизация и происхождение действия — три разных вопроса

Термин «идентичность агента» часто объединяет несколько независимых сущностей. В реальной цепочке могут участвовать:

Для каждого действия необходимо отдельно ответить на три вопроса:

1. Кто аутентифицирован? Например, пользователь, OAuth-клиент или рабочая нагрузка с определённым SPIFFE ID.

2. Кто уполномочен выполнить именно это действие? Здесь важны целевой ресурс, операция, граница арендатора, параметры, срок и глубина делегирования.

3. Чем это можно доказать после выполнения? Нужны не только журналы вызовов, но и идентификатор полномочия, решение политики, подтверждение пользователя и отпечаток фактического запроса.

Идентичность рабочей нагрузки не заменяет пользовательскую делегацию. SPIFFE ID и SVID позволяют процессу криптографически доказать свою машинную идентичность внутри домена доверия. Это подходит для mTLS, доступа к брокеру токенов и идентификации оркестратора, но не выражает согласие пользователя или допустимую область полномочий для задачи (SPIFFE Identity).

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

Что MCP действительно гарантирует

В актуальной на 30 октября 2026 года финальной ревизии MCP 2026-07-28 сохранена OAuth-ориентированная модель авторизации. При этом протокольные сессии удалены: каждый запрос несёт версию протокола и клиентские метаданные (обзор ревизии MCP 2026-07-28).

MCP-сервер является OAuth resource server

HTTP MCP server рассматривается как защищённый OAuth-ресурс. Он публикует Protected Resource Metadata, а клиент использует эти метаданные, чтобы обнаружить подходящий authorization server. Сам authorization server остаётся отдельной ролью, которая выдаёт токены.

RFC 9728 определяет well-known URI для метаданных защищённого ресурса и позволяет связать ресурс с допустимыми authorization servers. Если состав участников известен заранее, стороны могут проверять взаимную согласованность опубликованных метаданных.

Это важно не только для автоматического обнаружения. Такая связь снижает риск ситуации, когда клиент получает токен не у того издателя или предъявляет его неподходящему ресурсу.

Токен должен быть привязан к ресурсу

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

Из этого следуют два обязательных архитектурных правила:

• токен для MCP Server A нельзя принимать на MCP Server B;

• MCP-сервер не должен пересылать входной пользовательский bearer token во внешний API.

Второе правило принципиально. Если инструмент просто передаёт исходный токен дальше, downstream-сервис получает полномочия, предназначенные другому ресурсу. Возникают условия для атак confused deputy, подмены токенов и неконтролируемого расширения зоны доверия. Требования к привязке ресурса и запрету token passthrough описаны в спецификации авторизации MCP; в dossier эта страница относится к предыдущей ревизии, поэтому при реализации необходимо фиксировать используемую версию спецификации.

Идентификатор OAuth-клиента — не идентичность агента

Client ID Metadata Documents позволяют использовать HTTPS URL как client_id: authorization server получает по этому адресу метаданные приложения, включая redirect URI. MCP отдаёт предпочтение предварительной регистрации клиента, затем CIMD и только после этого Dynamic Client Registration.

Но CIMD описывает OAuth-клиент. Он не доказывает:

• личность пользователя;

• идентичность запущенного экземпляра оркестратора;

• поручение на конкретное действие;

• полномочия удалённого агента.

Кроме того, CIMD оставался проектом IETF на дату исследования. Рабочая реализация должна фиксировать поддерживаемые версии и проверять изменения перед обновлением (проект CIMD).

Базовая OAuth-гигиена остаётся обязательной

Агентная архитектура не отменяет обычные требования безопасности OAuth. OAuth Security BCP требует, среди прочего, точного сравнения redirect URI, PKCE для Authorization Code flow, отказа от implicit и password grants и защиты от mix-up attacks. Для аутентификации confidential clients рекомендуется асимметрическая криптография — например, mTLS или private_key_jwt.

MCP даёт хороший фундамент для доступа к инструменту. Но он не описывает всю историю полномочий до и после этого инструмента.

Что A2A 1.0 стандартизирует — и чего не стандартизирует

A2A 1.0 определяет взаимодействие независимых агентов:

• обнаружение через Agent Cards;

• жизненный цикл задач;

• сообщения и artifacts;

• синхронный, потоковый и асинхронный обмен;

• объявление схем безопасности;

• authenticated extended card для дополнительных сведений, доступных после аутентификации.

В HTTP-примерах используются bearer tokens. Доступ к задачам связан с аутентифицированным клиентом: клиент должен видеть только доступные ему задачи.

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

• от какого пользователя пришло поручение;

• какие права были делегированы на предыдущем шаге;

• мог ли агент передавать их дальше;

• сохраняется ли исходный tenant;

• было ли одобрено конкретное изменение состояния.

Core A2A 1.0 не задаёт единого обязательного формата многошаговой цепочки пользовательской делегации, actor token или криптографической записи provenance. Это не обязательно недостаток самого транспортного протокола. У разных организаций различаются модели tenant, согласия, юридической ответственности и принятия решений. Такие правила могут быть оформлены отдельным профилем или строго определённой прикладной схемой.

Институциональное развитие A2A также не следует путать с готовой моделью полномочий. В августе 2026 года A2A был принят как Growth Stage project в Agentic AI Foundation (сообщение проекта). Governance создаёт площадку для развития, но само по себе не стандартизирует сквозное делегирование.

Как должна выглядеть сквозная модель полномочий

Надёжная схема не пытается поместить всю систему в один «супертокен». Вместо этого она раздельно фиксирует участников и на каждом переходе выдаёт новое, более узкое полномочие.

Минимальная модель действия включает:

• пользователь — пользователь, от которого исходит задача;

• OAuth-клиент — приложение или MCP-хост;

• идентичность рабочей нагрузки — конкретный оркестратор, агент или инструмент;

• исполняющий компонент — модель или иной компонент, сформировавший решение;

• целевой ресурс — канонический идентификатор MCP-, A2A- или API-ресурса;

• операция — разрешённое действие;

• область полномочий — набор допустимых прав;

• арендатор — граница данных и политики;

• цель — цель поручения, если она используется политикой;

• глубина делегирования — допустимое число последующих передач;

• срок действия — момент прекращения действия полномочия;

• идентификатор полномочия или делегирования — ссылка на исходное решение о делегировании.

На каждом переходе нужен отдельный токен

Оркестратор не должен передавать A2A-агенту пользовательский токен, а MCP-сервер — пересылать его конечному API. Для каждого следующего ресурса следует получать отдельный краткоживущий токен:

Пользователь
  → токен для MCP host/server
  → токен для конкретного A2A endpoint
  → токен для конкретного MCP tool
  → токен для downstream API

Каждый последующий токен должен иметь:

• одну узкую аудиторию;

• область полномочий, не шире входного полномочия;

• явную привязку к арендатору;

• короткий срок действия;

• ограничение глубины делегирования;

• при необходимости — привязку к ключу получателя.

RFC 8693 Token Exchange позволяет запросить новый токен для определённых resource, audience и scope. Claims act и may_act могут описывать действующую или допустимую acting party.

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

Не стоит также запрашивать один токен сразу для множества аудиторий и областей полномочий. RFC 8693 предупреждает, что такой запрос фактически формирует декартово произведение ресурсов и прав. Сервер авторизации вправе отклонить его как invalid_target. Для агентной цепочки безопаснее несколько узких токенов, чем универсальный токен предъявителя для нескольких аудиторий.

Решение о доступе должно приниматься вне LLM

Модель может предложить вызов инструмента, выбрать параметры или построить план. Она не должна быть единственным компонентом, решающим, разрешено ли действие.

Точка применения политики должна проверять структурированные данные:

• субъекта и workload;

• issuer и audience;

• tenant;

• разрешённую операцию;

• фактические параметры запроса;

• срок и глубину делегирования;

• наличие требуемого подтверждения;

• версию применённой политики.

Это особенно важно для параметров, которые меняют смысл операции: суммы, получателя, tenant, идентификатора объекта или целевого endpoint. Текст в истории диалога не является заменой формального решения политики.

Как выбрать механизм делегирования

Универсального формата для всех сценариев пока нет. Выбор зависит от границ доверия и требований к переносимости полномочий.

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

W3C Verifiable Credentials Data Model 2.0 позволяет выразить проверяемые утверждения issuer о subject и содержит credentialStatus для обнаружения приостановки или отзыва. Однако конкретный механизм статуса, доверие к issuer и бизнес-правила проверки остаются за пределами модели данных. Проверять VC на каждом вызове инструмента может быть неоправданно дорого и сложно.

OpenA2A Agent Authorization Protocol нельзя считать устоявшимся эксплуатационным стандартом. На октябрь 2026 года проект обозначает версию 0.5.1 как proposed draft, открытый для соавторов. Его можно изучать и испытывать, но не следует предполагать стабильную совместимость или подтверждённое внедрение без отдельной проверки.

Внутри одного корпоративного домена доверия сложная цепочка делегированных полномочий может быть не нужна. OAuth, идентичность рабочей нагрузки, краткоживущие токены, централизованные PDP/PEP и единый аудит часто дают более простую и достаточно сильную модель. OpenID Foundation также считает OAuth 2.1 пригодным для многих синхронных сценариев одного домена, выделяя пробелы прежде всего для междоменных, высокоавтономных, асинхронных и многопользовательских делегаций (Identity Management for Agentic AI).

Основные пути атаки

Confused deputy и подмена аудитории

Типовой сценарий: агент имеет законный доступ к двум ресурсам, но использует полномочия одного пользователя или tenant при обращении к другому ресурсу.

На каждой точке применения политики следует проверять:

• issuer и подпись либо результат introspection;

• срок действия;

• точное значение audience/resource;

• канонический идентификатор endpoint;

• tenant из полномочия и tenant целевого объекта;

• scope и операцию;

• запрет пересылки входного токена дальше.

Особое внимание требуется к нормализации host, path и идентификаторов ресурсов. Нельзя допускать, чтобы изменение пути или имени хоста заставляло сервер обработать запрос tenant A как запрос tenant B.

Кража и повторное использование токена

DPoP привязывает OAuth-токен к ключу держателя. Proof связывается с HTTP method, URI назначения и хешем access token через параметры htm, htu и ath (RFC 9449). Перехваченного токена предъявителя без соответствующего ключа становится недостаточно.

Но DPoP не устраняет replay автоматически. Повтор того же proof на том же endpoint требует короткого окна приёма и, для строгой защиты, одного из механизмов:

• общей проверки jti на повторное использование;

• server nonce;

• согласованной комбинации обоих подходов.

В горизонтально масштабированной системе локального кэша одного экземпляра недостаточно. Иначе доказательство, уже принятое узлом A, может быть повторно использовано на узле B. Общее хранилище для защиты от повторов повышает стоимость и сложность обработки, поэтому его влияние необходимо измерять, а не предполагать.

Межтенантная эскалация

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

Для особо чувствительной цепочки практичной исходной политикой будет:

• аудитория — одна конкретная конечная точка;

• область полномочий — подмножество входных прав;

• глубина делегирования — не более одного перехода;

• арендатор — явное обязательное поле;

• передача дальше — только через новый обмен токена.

Подтверждение пользователя и долгие задачи

В MCP 2026-07-28 многошаговые запросы позволяют инструменту или серверу запросить пользовательский ввод либо подтверждение, а затем получить его при повторе исходного вызова. Это полезный механизм human-in-the-loop, но сам протокол не решает, какие действия требуют одобрения и как привязать одобрение к операции.

Подтверждение следует хранить как отдельное решение, связанное как минимум с:

• классом риска;

• пользователем или иным утверждающим лицом;

• целевым ресурсом;

• каноническими параметрами действия или их хешем;

• арендатором;

• идентификатором делегирования;

• сроком действия.

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

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

Отзыв не распространяется по цепочке автоматически

Если исходный grant отозван, ранее выпущенные downstream-токены могут оставаться действительными до exp. Token Exchange не гарантирует каскадный отзыв.

Архитектуре приходится выбирать комбинацию мер:

• короткий TTL;

• introspection перед чувствительными действиями;

• deny-list для идентификаторов grant или токенов;

• события об отзыве;

• повторную авторизацию на критических этапах.

У каждой комбинации остаётся окно риска. Его необходимо измерить и документировать: например, как быстро отзыв доходит до всех точек применения политики и сколько уже выданный токен может использоваться без обращения к authorization server.

Provenance и аудит: trace ID недостаточно

Trace context помогает связать технический путь исполнения. MCP 2026-07-28 предусматривает передачу W3C trace context через _meta, а OpenTelemetry определяет context propagation как перенос значений, относящихся к исполнению, через границы процессов (OpenTelemetry Context Propagation).

Но trace ID не доказывает полномочие. Его наличие не означает, что пользователь одобрил действие, что политика разрешила конкретные параметры или что промежуточный агент не расширил scope.

Минимальная запись действия должна включать:

• subject пользователя;

• OAuth client_id;

• workload identity оркестратора и исполнителя;

• идентификаторы A2A-агента и MCP-инструмента;

• идентификатор и версию исполняющего компонента, если это требуется модели контроля;

• канонический целевой ресурс;

• grant/delegation ID;

• jti или безопасный хеш токена;

• решение политики и её версию;

• сведения о пользовательском подтверждении;

• хеш канонического запроса;

• trace_id;

• результат downstream-вызова.

Такая запись связывает идентичности, полномочие, решение и фактический запрос. Требования к защите журнала от изменений, срокам хранения, приватности и юридической доказательности зависят от отрасли и юрисдикции; обычные JWT claims, логи диалога или trace ID нельзя автоматически считать доказательством неотказуемости.

NIST concept paper отдельно выделяет различие человеческих и агентных идентичностей, минимальные привилегии при непредсказуемом поведении, доказательство полномочия конкретного действия, делегирование и accountability. Это именно концептуальный документ и запрос общественного мнения, а не завершённый профиль стандарта.

Как проверить архитектуру до рабочего запуска

Совместимость конкретных MCP hosts, A2A SDK и authorization servers нельзя вывести из текста спецификаций. Её следует проверять экспериментально. Следующие сценарии — методика валидации, а не опубликованные результаты измерений.

1. Базовый поток

Разверните authorization server, MCP host, MCP resource server и тестовый API.

1. Пользователь проходит Authorization Code + PKCE.

2. Host запрашивает токен с resource конкретного MCP endpoint.

3. MCP-сервер проверяет issuer, подпись или introspection, exp, audience, scope и tenant.

4. Для API сервер получает отдельный короткоживущий токен через Token Exchange.

5. В аудит записываются пользователь, client_id, SPIFFE ID оркестратора, инструмент, ресурс, jti или хеш токена, решение политики, trace_id и результат.

Критический инвариант: исходный пользовательский bearer token не достигает downstream API.

2. Confused deputy и token substitution

Создайте два MCP-сервера и два tenant API.

• Отправьте токен для Server A на Server B.

• Попробуйте заставить MCP-инструмент переслать входной токен во внешний API.

• Подмените path, host или resource identifier так, чтобы запрос tenant A выглядел как запрос tenant B.

Защищённая система должна отклонять чужую аудиторию, запрещать транзитную передачу токена и сохранять tenant binding после канонизации адреса.

3. Replay и передача полномочия агенту

Выдайте для A2A Agent B downstream-токен, привязанный через DPoP.

Проверьте:

• использование токена без закрытого ключа;

• повтор того же proof на том же method и URI;

• повтор proof на другом endpoint;

• проверку cnf, htm, htu, ath, iat, nonce и jti;

• различие поведения на одном узле и в горизонтально масштабированной системе.

Если повтор проходит через другой экземпляр сервиса, защита от replay фактически ограничена границами узла.

4. Межтенантная делегация и подтверждение

Пользователь tenant A передаёт задачу оркестратору, который делегирует подзадачу агенту B.

Проверьте, что B не может:

• вызвать привилегированный инструмент другого tenant;

• расширить scope;

• превысить разрешённую глубину делегирования;

• заменить целевой endpoint;

• использовать подтверждение после изменения суммы, получателя или tenant.

Затем отзовите исходный grant и измерьте, сколько уже выпущенные токены продолжают работать без introspection или deny-list.

Критерии готовности

Архитектуру можно считать подготовленной к рабочей эксплуатации только после проверки следующих инвариантов:

• upstream-токен не принимается ресурсом с другой audience;

• пользовательский bearer token не пересылается по цепочке;

• полномочия при делегировании только сужаются;

• каждый workload криптографически идентифицируется отдельно от пользователя;

• tenant проверяется на каждой точке применения политики;

• решение о доступе принимается вне LLM;

• подтверждение связано с точными параметрами и не допускает повторного использования после их изменения;

• защита DPoP от replay работает во всём кластере, а не только на одном узле;

• аудит связывает действие с пользователем, workload, grant, политикой и фактическим запросом;

• окно между отзывом grant и прекращением действия downstream-токенов измерено и принято владельцем риска.

MCP и A2A не следует оценивать как конкурирующие ответы на один вопрос. MCP ограничивает доступ клиента к инструменту. A2A организует обмен задачами между агентами. Сквозное полномочие возникает только тогда, когда архитектура связывает человеческого субъекта, OAuth-клиента, исполняющий workload, целевой ресурс и конкретное действие — и на каждом переходе выдаёт новое, узкое и проверяемое разрешение вместо передачи исходного токена дальше.