Когда ИИ-агент работает в продакшене и должен действовать от имени пользователя — читать репозитории на GitHub, отправлять письма, обращаться к корпоративным API — возникает классическая проблема делегирования доступа. Агент не должен хранить чужие пароли, но должен получить разрешение пользователя и действовать строго в его рамках. Amazon Bedrock AgentCore Identity решает эту задачу как самостоятельный сервис, не привязанный к конкретной платформе запуска.
В основе решения лежит Authorization Code Grant — один из потоков OAuth 2.0 (RFC 6749), специально предназначенный для делегированного доступа. Пользователь аутентифицируется у провайдера идентификации (в примере AWS используется Microsoft Entra ID, но подойдёт любой OIDC-совместимый провайдер), даёт согласие на доступ агента к конкретным ресурсам, после чего приложение обменивает код авторизации на токен доступа. Этот токен AgentCore Identity помещает в собственное хранилище — Token Vault — и привязывает к идентификатору пользователя. Каждый последующий запрос агента к стороннему сервису проходит через этот механизм, создавая аудиторский след от аутентификации пользователя до конкретного действия агента.
| URL | Кто создаёт | Куда указывает | Назначение |
|---|---|---|---|
| Callback URL | AgentCore Identity автоматически | Сервис AgentCore Identity | Принимает код авторизации от провайдера идентификации после аутентификации пользователя |
| Session Binding URL | Клиент (разработчик) | Session Binding Service клиента | Завершает привязку OAuth-авторизации к пользовательской сессии |
Архитектура, которую AWS описывает в своём руководстве, разворачивает два сервиса на Amazon ECS за Application Load Balancer. Первый — агентный воркload на базе FastAPI с эндпоинтом /invocations, который принимает sessionId и сообщение пользователя, передаёт их агенту (в примере используется фреймворк Strands Agents, но совместимы LangChain и другие SDK) и вызывает LLM через Amazon Bedrock. Второй сервис — Session Binding Service — обрабатывает OAuth-коллбэки и связывает авторизацию с нужной пользовательской сессией через API AgentCore Identity. Разделение этих двух функций принципиально: агентный код не занимается OAuth-логикой, а сессионный сервис не знает о бизнес-логике агента.
Реализован Authorization Code Grant (3-legged OAuth): агент действует от имени пользователя только после явного согласия.
ALB берёт на себя аутентификацию входящего трафика через встроенный OIDC-поток. После успешной аутентификации балансировщик добавляет в запрос заголовок x-amzn-oidc-data с JWT, содержащим claims пользователя, в том числе поле sub — уникальный идентификатор. Агент использует sub как ключ для изоляции сессий в Amazon S3 и как userId при вызове API GetWorkloadAccessTokenForUserId. Этот вызов возвращает workload access token — токен, представляющий идентификатор агента в контексте конкретного пользователя. Затем агент вызывает GetResourceOauth2Token, передавая этот токен, имя OAuth-провайдера, URL привязки сессии и необходимые scopes (например, read:user для GitHub).
Если валидного токена для пользователя ещё нет, AgentCore Identity создаёт sessionURI — объект, отслеживающий состояние OAuth-потока между запросами. Именно здесь проявляется ключевое отличие от наивных реализаций: Session Binding URL — это не то же самое, что Callback URL. Callback URL генерируется автоматически при создании OAuth-клиента в AgentCore Identity и указывает на сам сервис AgentCore. Session Binding URL — это эндпоинт, реализованный и размещённый самим клиентом; он завершает привязку сессии, верифицируя, что пользователь, инициировавший авторизацию, совпадает с тем, кто дал согласие. Это защищает от CSRF-атак и сценариев подмены браузера.
Инфраструктурно решение включает AWS WAF с базовым набором правил на уровне ALB, шифрование через AWS KMS с ключом, управляемым клиентом (CMK), логирование через Amazon CloudWatch и хранение access-логов в S3. Образы контейнеров хранятся в Amazon ECR. Трафик шифруется по HTTPS с сертификатом из AWS Certificate Manager, маршрутизация — через alias A-запись в Amazon Route 53. Полный исходный код решения доступен в репозитории на GitHub.
