Как Amazon Bedrock AgentCore собирает многоарендных ИИ-агентов под ключ — VogueTech

Что нового

Amazon запустила Amazon Bedrock AgentCore — управляемый безсерверный сервис для построения многоарендных (multi-tenant) агентных приложений на AWS.

Ключевые новшества:

Управляемый рантайм для агентов
AgentCore Runtime запускает сессии в изолированных microVM. Для каждой сессии — отдельная файловая система и окружение. Это снижает риск утечек между арендаторами без накладных расходов полноценной виртуалки.
Поддержка MCP-серверов и инструментов
Встроенная работа с MCP (Model Context Protocol): можно хостить MCP-серверы и подключать инструменты как часть агентной архитектуры.
Встроенная идентификация и делегирование прав
AgentCore Identity реализует работу с токенами по схеме on-behalf-of (OAuth 2.0 RFC 8693): агент получает отдельный, урезанный по правам токен для обращения к downstream-сервисам, а не работает под полными правами пользователя.
Память с иерархическими пространствами имён
AgentCore Memory даёт пять уровней памяти: глобальная, стратегическая (под тип агента), арендатор, пользователь, сессия. Встроенная изоляция по namespace, поддержка resource-based и атрибутного доступа.
Шлюз для инструментов и API
AgentCore Gateway превращает внешние API и AWS Lambda в инструменты для агентов. Поддерживает Amazon API Gateway, OpenAPI, Smithy, Lambda и MCP-сервера.
Политики и авторизация на уровне инструментов
AgentCore Policy перехватывает все запросы агентов к инструментам и проверяет их по политикам, написанным на естественном языке или в Cedar. Можно учитывать tenant_id, тариф, квоты и параметры вызова.
Многоарендный RAG на базе Bedrock Knowledge Bases
Поддержка как «силосного» варианта (отдельный векторный индекс на арендатора), так и «пула» (общий индекс с фильтрацией по метаданным/namespace).
Каталог агентов и навыков
AWS Agent Registry — общий реестр агентов, навыков, MCP-серверов и кастомных ресурсов внутри организации. Поддерживает версии и правила публикации.
Наблюдаемость и учёт затрат по арендаторам
AgentCore Observability интегрируется с OpenTelemetry и Amazon CloudWatch. Можно логировать токены ввода/вывода, вызовы инструментов, длительность и метрики с tenant-тегами.
Контентные гардрейлы на уровне Bedrock
Amazon Bedrock Guardrails фильтрует вход и выход моделей: запрещённые темы, фильтры по типам контента, стоп-слова, маскирование чувствительных данных, конфигурация по арендаторам и тарифам.
Поддержка трёх паттернов многоарендности
Silo, Pool и Bridge для:
- рантайма агентов,
- RAG,
- workflow,
- памяти и доступа к данным.

Числовых бенчмарков по скорости, стоимости токена или размеру контекста Amazon не приводит. Основной акцент — на архитектуре и изоляции арендаторов.

Как это работает

Рантайм агентов: microVM на сессию

Главная архитектурная развилка — запускать агентов по схеме:

Dedicated (Silo) — отдельный рантайм на арендатора.
Shared (Pool) — общий рантайм для всех арендаторов.

AgentCore Runtime пытается совместить плюсы обоих подходов:

Для каждого запроса создаётся сессионный microVM.
Это не полноценная виртуалка, а облегчённое окружение с:
- отдельным процессным пространством,
- собственной файловой системой на сессию,
- изолированным выполнением кода агента.
Сессионная файловая система позволяет:
- хранить промежуточные артефакты вычислений,
- сохранять состояние между шагами сложного workflow,
- минимизировать риск утечки данных между сессиями.
Контекст арендатора передаётся через HTTP-заголовки**:**
- tenant_id,
- тариф или уровень (tier),
- региональные предпочтения,
- фичефлаги и права доступа,
- стандартные токены авторизации.

Агент читает эти заголовки при вызове и подстраивает поведение: какой workflow запускать, какие инструменты разрешены, к каким API обращаться.

Модели: общая, по тарифу или fine-tuned

Amazon Bedrock даёт выбор больших языковых моделей (LLM) от разных вендоров и три схемы использования:

Shared FM — одна общая модель для всех арендаторов.
Плюс: проще эксплуатация, единое обновление. Минус: минимум кастомизации.
Tier-specific — разные модели под разные тарифы.
Например, более дешёвая модель для базового плана и более мощная — для Enterprise.
Tenant-specific fine-tuned — отдельная дообученная модель на данные арендатора.
Это нужно, когда:
- жёсткие требования по терминологии,
- отраслевое регулирование,
- SLA по качеству ответов.

Amazon Bedrock поддерживает:

Fine-tuning встроенных foundation models на ваших размеченных датасетах.
Custom Model Import — импорт уже дообученных моделей в инфраструктуру Bedrock.

Workflows: Silo, Pool и Bridge

Агент — это не только LLM, но и последовательность шагов: вызовы MCP-инструментов, API, навыков. Для описания workflow в многоарендном мире Amazon предлагает три паттерна:

Silo
- Каждый арендатор получает свои навыки/skills.
- В одном skill — весь бизнес-процесс: валидации, интеграции, правила.
- Максимальная кастомизация, максимальные затраты на сопровождение.
Pool
- Общие навыки для всех арендаторов.
- Логика определяется входными параметрами и контекстом арендатора.
- Дешевле поддерживать, сложнее удержать изоляцию и вариативность логики.
Bridge
- Общие шаги (аутентификация, логирование, обработка ошибок) вынесены в shared skills.
- Критичная бизнес-логика — в tenant-specific skills.
- Компромисс: повторное использование инфраструктуры плюс кастомизация.

Workflows можно реализовать как:

MCP-инструменты с пошаговыми процессами,
API-эндпоинты с бизнес-логикой,
навыки (skills) внутри агента.

Multi-tenant RAG

RAG (Retrieval Augmented Generation) требует строгой изоляции данных. Bedrock Knowledge Bases поддерживает два основных сценария:

Silo — отдельный векторный индекс под каждого арендатора.
Подходит для:
- банков,
- медицины,
- крупных Enterprise с требованием выделенной инфраструктуры.
Pool — общий векторный индекс с фильтрацией по:
- метаданным (tenant_id и др.),
- namespace.
  Плюс: экономия на инфраструктуре для множества небольших арендаторов.

Важно:

В запросы на поиск автоматически подмешивается фильтр по арендатору.
Результаты дополнительно проверяются, чтобы исключить кросс-арендаторные утечки.

Bedrock Knowledge Bases берёт на себя:

подключение к источникам данных,
нарезку документов на чанки,
генерацию эмбеддингов,
хранение векторов.

Идентичность, act-on-behalf и токены

Многоарендная архитектура ломает наивный подход «выдали JWT — и забыли». У агентов есть автономность: они сами решают, какой инструмент вызвать и с какими параметрами. Это создаёт риски:

кража полномочных токенов пользователя,
эскалация прав,
проблема Confused Deputy — когда сервис с более высокими привилегиями действует в интересах менее привилегированного субъекта.

Amazon предлагает чёткую схему:

Контекст арендатора кодируется в JWT в трёх слоях:
- Security Context: стандартные поля iss, sub, exp, aud.
- Tenant Context: tenant_id и tenant-specific scopes.
- Request Context: доменные атрибуты под бизнес-логику.
Два паттерна работы с правами:
- Impersonation — агент действует с полными правами пользователя. Просто, но нарушает принцип наименьших привилегий.
- Act-on-Behalf (Delegation) — рекомендованный вариант.
  На каждом шаге токен меняется на новый, с урезанными правами и полем act по RFC 8693.
On-behalf-of token exchange в AgentCore Identity:
- Агент или MCP-сервер получает пользовательский access token.
- Обменивает его на новый токен, выпущенный для конкретного downstream-сервиса.
- Новый токен содержит:
  - идентичность агента,
  - идентичность исходного пользователя.

Ресурсные серверы видят оба слоя и могут реализовать zero-trust авторизацию на каждом хопе.

Доступ к MCP-инструментам и API

Контроль доступа строится на трёх уровнях.

Политики (AgentCore Policy)

Все запросы агентов к инструментам проходят через Policy-слой.
Политики могут:
- анализировать tenant_id, тариф, квоты,
- смотреть на параметры вызова инструмента,
- принимать решение allow/deny в рантайме.
Хранение политик централизованное, с версионированием и аудитом.
Язык политик — естественный язык или Cedar.

Invocation-уровень (MCP servers и Gateway)

MCP-серверы фильтруют доступные инструменты по:
- тарифу арендатора,
- фичефлагам,
- лимитам.
Interceptors проверяют JWT и подтверждают права на конкретную операцию.
Возможна трансформация схемы инструмента под конфигурацию арендатора.

AgentCore Gateway:

Оборачивает API и Lambda в инструменты для агентов.
Поддерживает Amazon API Gateway, OpenAPI, Smithy, Lambda, MCP.
Доступ можно ограничивать:
- кастомными interceptors,
- resource-based политиками в стиле AWS IAM.

Данные (ABAC через IAM)

Для доступа к данным используются Attribute-Based Access Control (ABAC).
Tenant_id и другие атрибуты приходят из JWT.
IAM-политики ограничивают доступ к ресурсам по тегам и атрибутам субъекта.
Можно реализовать row-level security и storage-политики, чтобы агент видел только данные своего арендатора.

Память: пять уровней и namespace

AgentCore Memory реализует многоуровневую память:

Global — общие знания для всех арендаторов.
Strategy — паттерны поведения для конкретного типа агента.
Tenant — история и предпочтения арендатора.
User — контекст отдельного пользователя внутри арендатора.
Session — краткосрочное состояние активного диалога.

Варианты изоляции:

Pool — общий сторедж, логическая изоляция через namespace-пути.
Все операции над памятью идут с префиксом, например tenant_123:user_456.
Silo — отдельное хранилище памяти на арендатора.
Максимальная изоляция, более высокая стоимость управления.

Авторизация:

Используются resource-based политики и ABAC.
Агент может читать и писать только в те namespace, которые разрешены его идентичности.

Идентичность, доверие и каталог агентов

AgentCore Identity

Агент получает workload identity, привязанную к AWS-аккаунту и IAM.
Может безопасно обращаться к AWS-ресурсам и сторонним инструментам.
Интеграция с Okta, Microsoft Entra ID и Amazon Cognito без миграции пользователей.

Доверие к агентам

Одна только идентичность не говорит, можно ли доверять агенту.
В экосистеме обсуждается Agent Naming Service (ANS) v2 (IETF draft), где каждая идентичность агента привязана к DNS-домену.
Предлагаются три уровня верификации: Bronze (PKI), Silver (PKI + DANE), Gold (PKI + DANE + Transparency Log).

AWS Agent Registry

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

Наблюдаемость и учёт затрат

AgentCore Observability:

Интеграция с OpenTelemetry и Amazon CloudWatch.
Трассировка шагов выполнения агента: какие инструменты вызывались, в каком порядке, сколько заняли.
Логирование с tenant-контекстом:
- токены ввода/вывода,
- время выполнения,
- количество вызовов инструментов.

Это база для:

биллинга по арендаторам,
поиска узких мест,
планирования ёмкости.

Guardrails и безопасность контента

Amazon Bedrock Guardrails добавляет три точки контроля:

Пре-процессинг входа
- Блокировка вредоносных промптов,
- защита от prompt injection,
- очистка PII по требованиям арендатора (HIPAA, PCI-DSS и др.).
Пост-процессинг выхода
- Проверка фактической корректности,
- поиск галлюцинаций,
- соблюдение формата ответа,
- поиск утечек чувствительных данных между арендаторами.
Конфигурация по арендаторам и тарифам
- Настройка уровней токсичности,
- списки запрещённых тем и слов,
- метрики: доля заблокированных запросов, категории, false positive.

Что это значит для вас

Когда AgentCore действительно помогает

AgentCore имеет смысл, если вы:

строите SaaS с ИИ-агентами для десятков или сотен клиентов;
обязаны соблюдать регуляторные требования и аудит (финансы, медицина, госзаказ);
хотите развести тарифы по качеству и стоимости ИИ (разные модели, разные инструменты);
планируете много инструментов и внешних API, а не только чат с LLM;
вам нужен понятный биллинг по арендаторам и контроль квот.

Примеры сценариев:

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

Где AgentCore может быть избыточен

Лучше поискать более простое решение, если:

у вас один арендатор и нет планов масштабироваться в B2B-SaaS;
агент ограничивается одной-двумя интеграциями и не требует сложной политики доступа;
вы не используете AWS как основную инфраструктуру.

В таких случаях достаточно прямой работы с Amazon Bedrock, OpenAI, Anthropic или других провайдеров через API и собственного приложения без AgentCore.

География и доступность

AgentCore — часть Amazon Bedrock и AWS.
Для работы нужен аккаунт AWS и доступ к регионам, где доступен Bedrock.

Если вы находитесь в России, прямой доступ к AWS и Bedrock может потребовать VPN и юридическую оценку рисков. Это особенно важно для коммерческих и государственных проектов.

Место на рынке

AgentCore конкурирует не с отдельными LLM вроде GPT-4o или Claude 3, а с платформами для построения агентных систем и многоарендных SaaS на базе ИИ.

По сути, это ответ Amazon на задачу: «как собрать production-ready агентную платформу на AWS, не изобретая свою IAM, свой RAG и свой биллинг по арендаторам».

Что можно сказать по позиционированию:

По глубине интеграции с облаком
AgentCore сильно завязан на AWS IAM, CloudWatch, API Gateway, Lambda, Bedrock Knowledge Bases и Guardrails.
Если вы уже живёте в AWS, это плюс: меньше кода, больше декларативных политик.
По модели безопасности
Мало кто из конкурентов называет в явном виде act-on-behalf, RFC 8693 и workload identity как базу для агентов.
Здесь Amazon даёт довольно строгую и понятную схему для CISO и архитекторов.
По многоарендности
Три паттерна (Silo, Pool, Bridge) проходят через все уровни: рантайм, память, RAG, workflow, доступ к данным.
Это удобно, если вы проектируете SaaS с нуля и хотите единый подход к изоляции.
По моделям
Bedrock даёт выбор LLM от разных вендоров и механизм fine-tuning/Custom Model Import.
Цены и качество зависят от выбранной модели и тарифа Bedrock; в материале нет прямых сравнений с GPT-4o или Claude, поэтому делать выводы по скорости или стоимости нельзя.

Если ваша инфраструктура уже тесно связана с AWS и вы строите многоарендный продукт с ИИ-агентами, AgentCore закрывает типовые архитектурные задачи «из коробки»: изоляция арендаторов, делегирование прав, RAG, память, наблюдаемость и политику доступа.
Если вы работаете вне AWS или делаете небольшой однопользовательский продукт, AgentCore будет излишне сложным и тяжёлым решением.