Паспорт для ИИ-агента: как хотят проверять, кто им управляет

Когда ИИ-агент сам оформляет заказ, бронирует билет или подписывает запрос к чужому API, у второй стороны нет способа проверить главное: кто его выпустил, от чьего имени он действует и не подделан ли он. Пароль и ключ API отвечают на вопрос «пропускать ли запрос», но не на вопрос «кто за ним стоит». На фоне бума автономных агентов в 2024–2025 годах несколько инициатив предложили решение — единый «паспорт агента» с проверяемым происхождением и указанием владельца.

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

Что вообще значит «паспорт агента»

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

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

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

Почему это стало актуально именно сейчас

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

Отсюда конкретные риски: подмена агента (кто-то выдаёт своего бота за агента известного банка), неограниченное делегирование (агент делает то, на что владелец его не уполномочивал) и невозможность разобрать инцидент постфактум — если непонятно, чей это был агент, некому предъявлять претензии.

Подходы, которые обсуждаются

Единого принятого стандарта на сегодня нет. Есть несколько направлений, которые пытаются закрыть задачу с разных сторон.

• Верифицируемые учётные данные (VC) и DID. Идентичность агента описывается как децентрализованный идентификатор со подписанными утверждениями о владельце и правах. Технология существует независимо от ИИ и стандартизирована W3C.
• Идентичность поверх протоколов взаимодействия агентов. Вендоры продвигают протоколы обмена между агентами и инструментами; в них встраивают поля с указанием происхождения и оператора.
• Делегированные токены OAuth-стиля. Владелец выдаёт агенту токен с ограниченным набором прав и сроком действия, и принимающая сторона проверяет область полномочий.
• Реестры и списки доверенных операторов. Централизованный или федеративный список, в котором можно посмотреть, кому принадлежит агент с данным идентификатором.

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

Сравнение подходов

Важная оговорка: в этой таблице сравниваются классы решений, а не конкретные готовые продукты «паспорт агента». Массово принятого коммерческого сервиса с таким названием на рынке пока нет — есть строительные блоки.

Как это работает в цепочке доверия

Упрощённая схема, к которой сходятся большинство предложений:

1. Оператор выпускает агента и подписывает утверждение о его происхождении своим ключом.
2. Владелец (человек или компания) выдаёт агенту делегированные полномочия с ограничениями и сроком.
3. Агент при обращении к внешнему сервису предъявляет паспорт: происхождение плюс права.
4. Принимающая сторона проверяет подписи и сверяет, не отозван ли агент.
5. Действие логируется так, чтобы позже можно было восстановить, чей это был агент.

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

Кому это пригодится, а кому пока нет

Пригодится:

• Финтеху и платёжным сервисам — если агент инициирует операцию, надо знать, чьё это поручение и в каких пределах.
• B2B-интеграциям, где агенты одной компании ходят в API другой: паспорт заменяет ручное согласование доверенных ключей.
• Маркетплейсам инструментов и агентов — чтобы отличать проверенных поставщиков от анонимных ботов.
• Регулируемым отраслям, где нужно доказать, кто и на каком основании совершил автоматическое действие.

Пока избыточно:

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

Что мешает единому паспорту

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

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

¹ Отзыв (revocation) — механизм, который делает ранее выданные учётные данные или токен недействительными до истечения их срока, например при компрометации ключа или отзыве полномочий владельцем.