Допущение о сессии ломается
Большинство агентных систем построены на неявном допущении, унаследованном от веб-автоматизации: что агент — это ускоренный браузер. Он несёт пользовательскую сессию, предъявляет те же cookies и обращается к тем же эндпоинтам. Это допущение держится, пока агент только читает. Оно рушится в тот момент, когда агент пытается совершить транзакцию.
OAuth не отвечает на этот вопрос. Access token описывает предоставление прав от владельца ресурса клиентскому приложению. Он фиксирует, на что согласился человек, а не то, какой автономный процесс сейчас пользуется этим предоставлением. Когда у одного пользователя три агента работают против одного и того же аккаунта, токен у всех одинаковый. Нет способа отозвать одного агента, не отозвав остальных, и нет способа постфактум приписать конкретную транзакцию конкретному действующему лицу.
Пробел здесь не в аутентификации. Пробел — в идентичности.
Что нужно делегированной идентичности
Делегированная машинная идентичность — это учётные данные, выпущенные control plane принципала конкретному агенту и несущие собственный жизненный цикл. У неё есть три свойства, которых нет у пользовательской сессии.
Стабильный идентификатор, отдельный от принципала
Агенту нужен собственный ключевой материал и собственный график ротации. Принципал — человек или организация, от чьего имени действует агент, — остаётся корнем полномочий, но агент является отдельным субъектом с отдельным публичным ключом. Именно это разделение делает возможной атрибуцию: подписанный запрос называет агента, и ключ агента подтверждает это утверждение, не раскрывая учётные данные принципала.
Ротация должна быть независимой. Если ключ агента скомпрометирован, его ротация не должна заставлять человека заново аутентифицироваться везде. И наоборот, если учётные данные принципала ротируются, делегированное предоставление агента должно выживать через путь перевыпуска, а не через смену пароля.
Явное сужение скоупа
Делегированное предоставление должно быть узким одновременно по трём осям:
- По контрагенту. Агент, уполномоченный покупать у одного мерчанта, не уполномочен покупать у другого. Скоупы должны называть relying party, а не обобщённую поверхность API.
- По классу транзакции. Чтение, резервирование, фиксация и возврат — это разные полномочия. Большинству агентов первые два нужны гораздо чаще, чем третье.
- По временному окну. Предоставление, выпущенное для сценария оформления заказа, должно истекать, когда сценарий завершается, а не когда истекает session cookie. Короткоживущие предоставления с явным продлением проще осмыслить, чем долгоживущие токены с широкими скоупами.
Конкретный механизм для этого — подписанный capability token: структурированные учётные данные, которые агент предъявляет контрагенту и которые содержат идентификатор агента, разрешённого контрагента, разрешённый класс действий, окно действия и цепочку подписей обратно к принципалу. Контрагент проверяет цепочку и применяет скоуп локально. Control plane принципала не обязан быть онлайн, чтобы транзакция прошла, но остаётся единственной стороной, способной выпустить новое предоставление.
Путь отзыва, не затрагивающий человека
Отзыв — свойство, которое чаще всего отсутствует. Если единственный способ остановить агента — сменить пароль аккаунта, то агент на самом деле не делегирован — он выдаёт себя за другого. Отзыв должен быть полноценной операцией: пометить идентификатор агента как отозванный в control plane, опубликовать это состояние и позволить контрагентам отклонять предъявление отозванных учётных данных. Учётные данные человека при этом не задействованы.
Правило проектирования: идентичность как ресурс control plane
Практическое следствие в том, что идентичность агента относится к той же категории, что учётные данные базы данных или сервисный аккаунт. Она выпускается, ограничивается скоупами, лимитируется по частоте, отзывается и логируется инфраструктурой, а не формой входа.
Это значит, что control plane нужен реестр с определённым жизненным циклом для каждого агента:
agent_id stable, opaque, never reused
principal_id the authority root
key_material public key, rotation schedule
scopes [{counterparty, action_class, window}]
state active | suspended | revoked
rate_limits per counterparty, per action_class
audit_log append-only, every presentation recorded
Каждое использование идентичности пишется в журнал аудита: какой агент, какой контрагент, какой класс действий, какое предоставление и каков результат. Это та запись, которая делает спорную транзакцию разрешимой. Без неё агент, действующий от имени принципала, неотличим от принципала, действующего напрямую, и подотчётность снова схлопывается к человеку.
Проектируйте под отказ
Контрагенты будут фингерпринтить автономный трафик и лимитировать его по частоте. Некоторые будут отказывать outright. Это нормальное рабочее условие, а не путь ошибки. Агентная архитектура, которая трактует отказ как исключение, подлежащее повтору, будет генерировать эскалирующий трафик против контрагента, который уже принял решение. Правильное поведение — зафиксировать отказ, показать его принципалу и остановиться.
Ограничение частоты принадлежит и стороне агента по эту сторону границы. Делегированная идентичность с потолком на контрагента не даёт агенту исчерпать квоту, которая нужна и принципалу. Это также даёт сигнал: устойчивое давление лимитов на одного контрагента — свидетельство того, что скоуп неверен, а не того, что агенту нужно больше мощности.
Компромисс
Эта схема дороже, чем переиспользование сессии. Она требует реестра, механизма подписи, графика ротации, канала отзыва и конвейера аудита. Она добавляет задержку к каждой транзакции, потому что контрагент должен проверить цепочку учётных данных, а не просто принять cookie. Она требует координации с контрагентами, которые могут вообще пока не принимать делегированные учётные данные — и тогда у агента нет соответствующего требованиям пути, и он должен откатываться к подтверждению с участием человека.
Эта цена и есть суть. Альтернатива — агент, действующий с полными полномочиями человека, которого нельзя атрибутировать, нельзя сузить и нельзя остановить, не сломав доступ человека. Как только агенты начинают совершать транзакции с третьими сторонами, единица подотчётности уже сместилась. Инфраструктура должна последовать за ней.
К чему это приводит
Идентичность агента — не функция аутентификации, прикрученная к существующему продукту. Это примитив, определяющий, чем агенту позволено быть. Команды, которые относятся к ней как к логину, будут снова и снова обнаруживать, что контрагенты считают их агентов неизвестным классом клиентов, и снова и снова не будут знать, что ответить на вопрос, кто действует и по чьим полномочиям.
Команды, которые относятся к ней как к инфраструктуре — выпускаемой, ограничиваемой скоупами, лимитируемой по частоте, отзываемой, логируемой, — будут знать ответ. У них также будет журнал аудита, чтобы это доказать.