Сценарии аутентификации агентов: от оркестрации до CIBA

Введение

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

В этой статье рассмотрены четыре типовых сценария, которые встречаются в агентных системах:

1. Внутриорганизационная оркестрация.
2. Межорганизационная коллаборация.
3. Эфемерные агенты с JIT-идентичностью.
4. Участие человека через CIBA.

Каждый сценарий включает участников, используемые стандарты и роль IAM-платформы.

Сценарий 1. Внутриорганизационная оркестрация

Описание

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

Поток аутентификации

1. Оркестратор получает JWT-SVID от Workload API SPIRE.
2. С помощью RFC 7523 обменивает JWT-SVID на OAuth access token.
3. При делегировании биллинг-агенту использует RFC 8693 с act-утверждением, указывающим SPIFFE ID оркестратора.
4. Биллинг-агент валидирует транзакционный токен и выполняет задачу с областью billing:read.
5. Каждый hop логируется в системе аудита с полной цепочкой делегирования.

Роль IAM-платформы

• сервис токенов выпускает access tokens на базе валидированных SVID;
• движок аутентификации поддерживает SPIFFE-аутентификатор;
• управление сессиями отслеживает делегационные цепочки;
• аудит-логи фиксируют вложенные act-утверждения.

Сценарий 2. Межорганизационная коллаборация

Описание

Логистический агент компании А взаимодействует с shipping-агентом компании Б для международной доставки. Агенты находятся в разных доменах доверия с отдельными инфраструктурами SPIFFE и серверами авторизации.

Поток аутентификации

1. Агент компании А предъявляет свой JWT-SVID шлюзу компании Б.
2. Шлюз использует федерацию SPIFFE для верификации подписи через trust bundles.
3. Сервер авторизации компании Б выполняет междоменный обмен токенами.
4. Токен содержит идентичность человека-инициатора, цепочку делегирования и ограниченные полномочия.
5. Ослабляющий авторизационный токен ограничивает доступ только к shipping:quote и shipping:track.

Роль IAM-платформы

• реестр доменов доверия управляет федеративными trust bundles;
• сервис токенов выполняет междоменный обмен с сохранением цепочки;
• движок политик применяет ограничения ослабления;
• резолюция DID обеспечивает верификацию без центрального реестра.

Сценарий 3. Эфемерные агенты с JIT

Описание

Serverless-платформа создаёт агент для обработки одного тикета поддержки клиентов. Агент существует 30 секунд, обращается к базе знаний, CRM и сервису email.

Поток аутентификации

1. Оркестратор платформы запрашивает JIT-провижининг идентичности.
2. Инфраструктура идентичности динамически создаёт SPIFFE ID spiffe://company.cloud/ephemeral/ticket-12345/<uuid>.
3. SPIRE регистрирует ID с TTL 1 минута и выдаёт JWT-SVID.
4. Агент обменивает SVID на транзакционный токен, ограниченный kb:read, crm:read, email:send для конкретного тикета.
5. По завершении обработки идентичность явно отзывается.

Роль IAM-платформы

• RFC 7591 — динамическая регистрация клиентов для эфемерных агентов;
• резолютор SPIFFE ID для провижининга во время выполнения;
• выпуск транзакционных токенов с кратким TTL;
• автоматическая очистка по истечении срока или явному отзыву.

Сценарий 4. Участие человека через CIBA

Описание

Финансовая транзакция высокого риска требует одобрения человека на уровне $10 000+. Торговый агент анализирует рыночные условия, формирует рекомендацию и инициирует поток CIBA.

Поток аутентификации

1. Торговый агент предъявляет аттестованную идентичность (JWT-SVID + DPoP Proof).
2. Запрашивает повышение уровня авторизации.
3. Сервер авторизации отправляет push-уведомление человеку-трейдеру с деталями транзакции.
4. Трейдер проходит MFA и одобряет или отклоняет операцию.
5. При одобрении выпускается транзакционный токен с TTL 60 секунд, содержащий принципала, актора и агентный контекст.

Роль IAM-платфорры

• конечная точка CIBA для push-уведомлений;
• интеграция MFA для повышения уровня доверия;
• выпуск транзакционных токенов с утверждениями агентного контекста;
• движок политик проверяет лимиты;
• аудит-трейл включает одобрение трейдера, анализ агента и метку времени исполнения.

Сравнение сценариев

Что важно для BDM

Эти сценарии показывают, что агентная аутентификация — это не один протокол, а композиция стандартов. Для бизнеса важно понимать:

• Когда нужен человек в контуре. CIBA и MFA остаются обязательными для высокорисковых операций.
• Когда можно автоматизировать. Внутренние рутинные цепочки могут работать без участия человека.
• Как ограничить ущерб. JIT-идентичности и краткосрочные токены сужают радиус взрыва.
• Как доказать compliance. Полная цепочка делегирования и неизменяемый контекст упрощают аудит.

Частые ошибки при аутентификации агентов

При внедрении агентной аутентификации команды часто повторяют одни и те же ошибки:

• Долгоживущие токены. Выдача токена на дни или недели увеличивает окно атаки. Агенты должны получать краткосрочные токены и ротировать их автоматически.
• Общие секреты. Использование одного API-ключа для всех экземпляров агента не позволяет отследить, какой именно экземпляр выполнил действие.
• Потеря контекста делегирования. Если каждый hop не фиксирует актора и принципала, расследование инцидента становится невозможным.
• Отсутствие отзыва. После завершения задачи идентичность и токены должны быть явно отозваны, особенно для JIT-агентов.
• Игнорирование человека в контуре. Высокорисковые операции должны требовать одобрения человека, даже если агент действует автономно.

Избежать этих ошибок помогает комплексный подход: короткие TTL, криптографическая привязка токенов, полное логирование цепочек и чёткие политики для human-in-the-loop.

Как тестировать сценарии

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

1. Развернуть тестовый SPIRE и выпустить SVID для агентов.
2. Настроить mock-сервер авторизации для обмена токенами и транзакционных токенов.
3. Проверить прохождение цепочки делегирования и корректность act-утверждений.
4. Протестировать отзыв идентичности и истечение TTL.
5. Проверить аудит-журналы на полноту и непротиворечивость.

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

Вывод

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