AWS научил AI-агентов безопасно работать с токенами пользователей в мультитенантных системах
AWS представил встроенную поддержку OAuth 2.0 Token Exchange (RFC 8693) в Amazon Bedrock AgentCore. Теперь AI-агенты могут безопасно вызывать API от имени пользователей в мультитенантных архитектурах, сохраняя цепочку аудита и не превращая каждый сервис в confused deputy. Система автоматически обменивает входящий токен пользователя на новый с правильным audience для каждого downstream-сервиса.
Это не абстрактная security-теория — это решение конкретной проблемы безопасности продакшн мультитенантных AI-агентов. Без правильного обмена токенов каждый такой агент либо становится точкой безусловного доверия (и единой точкой отказа безопасности), либо передаёт неправильные credentials downstream. AWS сделал это встроенной функцией, убрав координационную нагрузку между agent runtime, authorization серверами и downstream APIs.
Проблема безопасности мультитенантных агентов
Когда AI-агент работает с несколькими клиентами (tenants) и вызывает внешние API от имени пользователей, возникает классическая проблема безопасности: какую идентичность передавать downstream-сервисам?
Три подхода и их недостатки:
-
Service-account impersonation — агент действует от своего имени, передавая ID пользователя в заголовке. Все downstream-сервисы должны безусловно доверять агенту. Скомпрометированный агент может действовать от имени любого пользователя — это confused deputy в чистом виде.
-
Прямая передача токена — агент пересылает токен пользователя без изменений. Работает только если audience токена уже совпадает с downstream API, что редко бывает в мультитенантных системах.
-
On-behalf-of (OBO) token exchange — входящий токен обменивается на новый, где
subостаётся оригинальным пользователем,audпереписывается на целевой API, а подпись выдаётся authorization сервером, которому доверяет downstream-сервис.
Решение от AWS
Amazon Bedrock AgentCore Identity теперь поддерживает OAuth 2.0 Token Exchange (RFC 8693) как встроенный credential-provider grant type. AgentCore Gateway автоматически перехватывает вызовы инструментов, определяет целевого tenant'а и выполняет обмен токенов перед отправкой запроса.
Ключевые преимущества:
- Identity propagation — оригинальная идентичность пользователя (
subclaim) сохраняется end-to-end, даже когда audience меняется - Cryptographic least privilege — каждый downstream-вызов несёт токен, привязанный к конкретному сервису через
audclaim; токен для одного tenant'а нельзя использовать у другого - Нет логики обмена в агенте — код агента работает с одним входящим токеном и вызывает tools, всё остальное делает AgentCore
- Стандартизация — построено на RFC 8693, работает с любым authorization сервером, поддерживающим этот grant type
Референсная реализация
AWS предоставляет TravelBot — мультитенантного ассистента бронирований для двух примерных tenant'ов (Acme и Globex). Код будет доступен в репозитории aws-samples/sample-obo-flow-poc с демонстрацией JWT-трансформаций на каждом hop'е и audience binding для defense in depth.
OBO vs Impersonation: В OBO-обмене sub claim сохраняется, aud переписывается на downstream-сервис, а actor обмена записывается в отдельный claim (act по RFC 8693, cid в Okta). Это позволяет downstream API одновременно ответить на два вопроса: от чьего имени действуют (sub) и кто выполняет действие (actor). Авторизация решается по sub, аудит и rate-limiting — по actor.
Ключевые выводы
- AWS реализовал RFC 8693 Token Exchange как встроенную функцию AgentCore, устраняя необходимость писать логику обмена токенов в самих агентах
- OBO-паттерн — единственный способ сохранить идентичность пользователя end-to-end, обеспечить least privilege на границе audience и создать токен, валидируемый downstream API независимо от доверия к агенту
- Система решает проблему confused deputy: скомпрометированный агент не может действовать от имени произвольного пользователя, так как каждый токен криптографически привязан к конкретному downstream-сервису
- Разделение `sub` (от чьего имени) и actor claim (кто выполняет) позволяет правильно разделить авторизацию, аудит и rate-limiting
- Прямая передача токенов работает только в узком случае single-tenant агентов, где inbound audience уже совпадает с downstream API — для остальных сценариев нужен OBO
Автор: Елена Верещагина · Источник: aws.amazon.com
**Наконец-то кто-то сделал security для AI-агентов не костылём, а продуктом.** Проблема confused deputy в аgentic AI — это не гипотетическая атака из учебника, а реальная дыра в архитектуре большинства продакшн-систем. Когда один агент обслуживает сотни клиентов и дёргает десятки внешних API, вопрос "чьим токеном ходить дальше" превращается в кошмар: либо агент — бог с root-доступом ко всему (и единая точка взлома), либо каждый downstream-сервис должен сам разбираться, кому верить.
AWS взял RFC 8693 — стандарт обмена токенов, который существует с 2020 года, но почти никто не использует из-за сложности интеграции — и запёк его прямо в AgentCore. Теперь это работает out of the box: агент получает один токен, Gateway сам переписывает audience для каждого вызова, сохраняя оригинального пользователя в `sub`, а actor обмена — в отдельном claim. Downstream API видит и "от чьего имени" (для авторизации), и "кто реально стучится" (для аудита). Это правильная архитектура, которую раньше приходилось городить руками. Единственный вопрос — насколько легко интегрировать сторонние authorization серверы, если у тебя не Okta. Но сам факт, что AWS сделал это встроенной фичей, а не оставил "разберитесь сами" — это шаг вперёд для всей индустрии.
Комментарии