AWS Agent Registry получила отдельный namespace и каталог ресурсов

Каталог для agents, tools, skills и MCP servers

AWS Agent Registry — управляемый discovery service для публикации, курирования и поиска ресурсов, которыми пользуются люди и AI-агенты. Registry принимает записи об agents, MCP servers, tools, agent skills и custom resources, а одобренный каталог можно просматривать, искать через hybrid search или открывать через native MCP endpoint.

Сервис разделяет сам registry и registry records. Администратор задаёт имя, описание, тип авторизации и approval settings каталога; отдельная record хранит metadata конкретного ресурса. Registry можно организовать по типу ресурсов, среде, команде или business unit, вместо одного глобального списка на всю организацию.

Публикация записи не делает её автоматически видимой. Publisher создаёт draft и отправляет его на approval, curator одобряет или отклоняет запись, а consumer видит approved catalog. При включённом auto-approval запись переходит в Approved сразу; при ручном режиме остаётся Pending approval до решения администратора.

Поиск рассчитан и на человека, и на агента

Hybrid search сочетает semantic understanding и keyword matching, поэтому естественный запрос и точное имя ресурса проходят через один discovery layer. Для directory-style интерфейсов доступны просмотр с фильтрами и пакетное получение подробностей; MCP-compatible clients могут обращаться к Registry через удалённый MCP endpoint.

В новом namespace появились ListDiscoverableRegistryRecords, SearchDiscoverableRegistryRecords и BatchGetDiscoverableRegistryRecord. Первые и третьи доступны только через agent-registry, а не через прежний bedrock-agentcore namespace.

Доступ к discovery plane выбирается при создании Registry: IAM credentials либо JWT корпоративного identity provider. Один Registry не может одновременно принимать оба типа inbound authorization, а изменить authorization type после создания нельзя. Поэтому схему аутентификации нужно определить до наполнения каталога.

Миграция меняет не только имя CLI

6 августа 2026 года AWS запустила отдельный agent-registry namespace. Для клиентов прежнего preview переход затрагивает endpoints, IAM policies, SDK clients, CLI commands, resource ARN, observability integrations, API schemas и сами сохранённые registry records. Остальные компоненты AgentCore — Runtime, Gateway, Identity и Policy — остаются в bedrock-agentcore namespace.

CLI меняется с aws bedrock-agentcore на aws agent-registry, IAM action prefix — с bedrock-agentcore:* на agent-registry:*, а service principal — на agent-registry.amazonaws.com. Меняются также control-plane и data-plane endpoint, ARN ресурсов, CloudTrail event source, EventBridge source и CloudWatch namespace.

Одной замены строк недостаточно: AWS указывает на обратно несовместимые изменения API schema. В новой модели переработаны authorization configuration, поля и структура records, search filters и browsing APIs. Код, который формирует запросы или разбирает ответы, нужно обновить и повторно проверить.

Старый namespace отключается 17 сентября

Пользователи, имевшие Registry до 6 августа, временно получают доступ к обоим namespace. Миграционное окно закрывается 17 сентября 2026 года: после этой даты старый bedrock-agentcore namespace для Registry теряет read/write access, а оставшиеся там данные становятся недоступны.

AWS не переносит данные автоматически. Компания предоставляет tooling для extract, transform и load в том же account и region. Для активно изменяемого production-каталога документация предлагает active-active подход: сначала полная миграция, затем временная dual-write проверка и только после неё переключение чтения и записи.

Также нужно заменить managed policy BedrockAgentCoreFullAccess на AgentRegistryFullAccess: старая policy не будет дополнена permissions agent-registry:*. Командам следует отдельно проверить custom policies, permission boundaries, SCP, парсеры ARN, quotas, EventBridge rules и dashboards — эти зависимости могут не проявиться в простом API smoke test.

Registry решает discovery, но не доверие к коду

Approval workflow определяет, какие records доступны для discovery, а администратор может снова скрыть устаревший ресурс. Это помогает бороться с дублированием и неуправляемыми внутренними каталогами, но сама approved record остаётся metadata о ресурсе, а не доказательством безопасности его implementation.

Для production-каталога полезно разделить требования к записи и к исполняемому ресурсу. Registry может проверять protocol schema и approval state, тогда как владелец платформы отдельно отвечает за code review, version pinning, permissions вызываемого tool, обработку credentials и rollback. Обнаруживаемость без таких границ лишь ускорит распространение небезопасной интеграции.

Практический план перехода начинается с inventory: найти все старые clients, IAM references, ARN, events и данные, поднять новый Registry, перенести records и проверить поиск и approval end-to-end. Только после сравнения результатов и прекращения старых writes можно удалить временную совместимость — до дедлайна 17 сентября.