Транзакционные токены и ослабляющая авторизация: делегирование полномочий в цепочках агентов

Проблема: делегирование глубже одного шага

Реальная агентная система редко ограничивается парой «клиент — сервис». Пользователь просит оркестратора подготовить квартальный отчёт. Оркестратор делегирует выгрузку данных агенту CRM, тот вызывает расчётного агента для агрегации, а затем агента визуализации. Получается цепочка делегирования: оркестратор → рабочий агент → специализированный агент, и каждый hop — отдельный вызов, часто на другом узле и в другом процессе.

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

1. Кто инициировал работу — принципал (человек или система, от имени которой всё происходит).
2. Кто выполняет работу прямо сейчас — актор (конкретный агент в конкретном звене).
3. В каких рамках — намерение и ограничения исходной транзакции.

Обычный bearer access token отвечает разве что на первый вопрос, и только на первом шаге. Проброс одного токена по всей цепочке (token passthrough) — известный антипаттерн: аудитория токена не совпадает с получателем, журнал фиксирует лишь последнее звено, а скомпрометированный посредник получает все полномочия исходного клиента. Возникают три характерных сбоя:

• Размывание ответственности. В аудите виден только финальный исполнитель, восстановить, кто кому что поручил, невозможно.
• Избыточные полномочия. Токен оркестратора с широким scope «доезжает» до конца цепочки, хотя расчётному агенту нужна лишь малая его часть.
• Зависимость от центра. Если каждое звено интроспектирует токен у сервера авторизации, тот становится узким местом по задержке и доступности.

Ниже — три подхода, которые сообщество IETF и индустрия развивают для решения этой задачи: обмен токенами по RFC 8693, транзакционные токены и ослабляющая авторизация.

RFC 8693: обмен токенами и act-цепочки

RFC 8693 (OAuth 2.0 Token Exchange) определяет grant type urn:ietf:params:oauth:grant-type:token-exchange: клиент предъявляет серверу авторизации subject_token (и, опционально, actor_token) и получает новый токен для следующего звена.

Ключевое для цепочек — утверждение act (actor). Токен, выданный рабочему агенту, содержит sub принципала и act оркестратора. На следующем hop рабочий агент обменивает токен ещё раз, и новый act вкладывается внутрь предыдущего:

{
  "sub": "user-anna",
  "act": {
    "sub": "spiffe://corp.example/orchestrator",
    "act": {
      "sub": "spiffe://corp.example/worker-crm"
    }
  },
  "scope": "crm:read"
}

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

Где предел RFC 8693

• Предыдущие actor-утверждения только информационные. Спецификация прямо указывает: вложенные act описывают историю, но не создают обязательств для ресурсного сервера проверять и трактовать её. Полная семантика цепочки остаётся на совести конкретного развёртывания.
• Каждый hop — синхронный вызов сервера авторизации. При глубине цепочки в 4–5 звеньев это латентность на каждом шаге и жёсткая зависимость от доступности AS. Для автономных агентов, порождающих сотни делегирований в секунду, модель масштабируется плохо.
• Контекст исходной транзакции не закреплён. На каждом обмене набор утверждений формируется заново. Итоговый токен не доказывает, что исходное намерение («подготовить отчёт за Q2, не изменяя данные») было именно таким — нижестоящий сервис видит лишь то, что решил передать последний обмен.

Транзакционные токены: неизменяемый контекст

Транзакционные токены (Txn-Tokens) — рабочий черновик IETF OAuth WG, решающий именно проблему сохранения контекста. Идея: в начале внешней транзакции специальный сервис — Transaction Token Service (TTS) — выпускает короткоживущий подписанный JWT, который переносит идентичность пользователя, идентичность рабочей нагрузки и авторизационный контекст через всю цепочку вызовов внутри домена доверия.

Поток выглядит так:

1. Пограничный сервис получает внешний запрос с access token и обращается к TTS (запрос оформляется как обмен по RFC 8693).
2. TTS проверяет входящий токен, оценивает контекст и выпускает Txn-Token со сроком жизни в минуты или меньше — на длительность одной транзакции.
3. Сервис передаёт Txn-Token ниже по цепочке в HTTP-заголовке Txn-Token.
4. Каждое нижестоящее звено валидирует токен локально по ключам TTS — без обращения к серверу авторизации.

Тело Txn-Token включает характерные утверждения:

Критичны два свойства. Во-первых, неизменяемость tctx: ни одно промежуточное звено не может переписать параметры исходного намерения — их подписал TTS. Во-вторых, локальная проверка: цепочка не ходит в AS на каждом hop, что снимает узкое место RFC 8693.

Расширение для агентов

Черновик Transaction Tokens for Agents добавляет в Txn-Token агентный контекст:

• act — агент, выполняющий действие в данном звене;
• sub — принципал; для полностью автономного агента, действующего самостоятельно, sub указывает на самого агента;
• агентный контекст — операционное намерение и ограничения, в рамках которых агент действует.

В результате нижестоящий сервис отвечает не только на вопрос «кто этот агент?», но и на вопросы «кто инициировал работу?» и «в каких рамках она выполняется?» — криптографически проверяемым образом.

Ослабляющая авторизация: сужение без сервера авторизации

Третий подход — Attenuated Authorization Tokens (AAT), ослабляющие токены. Идея заимствована у capability-моделей (классический пример — макаруны с caveats): держатель токена может локально создать производный токен с дополнительными ограничениями — меньшим scope, конкретным ресурсом или аудиторией, укороченным TTL. Производный токен подписывается так, что проверяющий видит всю цепочку ограничений, а обращение к серверу авторизации не требуется.

Фундаментальное свойство — монотонность: ослаблять можно только в сторону сужения. Никакое звено цепочки не способно расширить свои полномочия сверх полученных. Минимальные привилегии перестают быть рекомендацией и становятся свойством механизма.

Для автономных цепочек это критично по трём причинам:

• Задержка. Делегирование не требует сетевого вызова — производный токен вычисляется на месте, за микросекунды.
• Устойчивость. Цепочка продолжает работать при временной недоступности сервера авторизации.
• Масштаб. Оркестратор, порождающий сотни подзадач, не создаёт нагрузки на инфраструктуру токенов.

Цена подхода: точечный отзыв производного токена невозможен (компенсируется коротким TTL), ресурсный сервер обязан проверять всю цепочку ограничений, а управление ключами и форматами caveat добавляет сложности.

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

На практике подходы комбинируются: Txn-Token выступает носителем неизменяемого контекста, AAT — механикой сужения полномочий на каждом шаге, а привязка к отправителю обеспечивается DPoP или взаимной TLS.

Риски и ограничения

• Кража и replay транзакционного токена. Txn-Token — bearer-инструмент: перехваченный токен можно переиграть в пределах TTL. Черновик прямо требует компенсирующие меры — короткий срок жизни, узкий scope и, где возможно, привязку к ключу отправителя.
• TTS как критическая точка. На домен доверия приходится ровно один логический TTS: его доступность, политики выпуска и ротация ключей становятся вопросом выживания всей цепочки.
• Аудит при AAT. Центральный сервер не видит отдельных ослаблений, поэтому след делегирования приходится реконструировать из цепочек caveat и журналов ресурсных сервисов — логирование на стороне ресурса обязательно.
• Незрелость. Оба ключевых документа — действующие черновики IETF: форматы утверждений ещё могут меняться. Проектировать стоит под семантику (принципал, актор, намерение), а не под конкретные имена полей.

Что закладывать в архитектуру уже сейчас

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

1. Идентичность рабочих нагрузок как база. Каждый агент получает верифицируемую идентичность (SPIFFE ID), а не общий API-ключ.
2. Запрет passthrough. Каждый hop — новый токен с проверкой аудитории; токен, выданный одному сервису, не принимается другим.
3. Сквозной идентификатор транзакции. Даже если сегодня это просто trace id в заголовках, журналы всех звеньев должны склеиваться в одну цепочку.
4. Политика «только сужение». При делегировании scope, TTL и аудитория могут уменьшаться, но не увеличиваться — так монотонность станет привычкой до появления AAT.
5. Токен-схема с принципалом, актором и намерением. Именно эти три сущности потребуются при миграции на Txn-Token и его агентное расширение.
6. Человек в контуре для высокорисковых операций. Ослабление полномочий не заменяет одобрения: для действий выше порога риска цепочка должна включать подтверждение человека (например, через CIBA).

Вывод

Многоступенчатое делегирование — норма агентных систем, и обычный access token этой норме не соответствует. RFC 8693 даёт работающий, но «централизованный» механизм с информационной цепочкой act. Транзакционные токены добавляют неизменяемый контекст и локальную проверку, ослабляющая авторизация — монотонное сужение полномочий без обращения к серверу авторизации. Стандарты ещё дозревают, но архитектурные решения — идентичность нагрузок, запрет passthrough, сквозной аудит и делегирование «только вниз» — можно и нужно закладывать уже сейчас: именно они определят, насколько безопасно масштабируются цепочки агентов.