AWS выносит изоляцию памяти агентов между тенантами из кода приложений

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

28 августа AWS добавила детализированный контроль доступа в Amazon Bedrock AgentCore Memory и в тот же день выпустила гибкие переменные пространств имён. Вместе эти изменения позволяют настроенному AgentCore Gateway сопоставлять OAuth- или JWT-claims, политику Cedar, запрошенную операцию Memory и пространство имён памяти до передачи запроса в Memory. Существенно меняется место, в котором команда может решать, кто вправе читать, записывать или удалять долговременный контекст агента.

Главное изменение не в том, что агент запоминает больше. Доступ к памяти можно сделать runtime-решением, привязанным к идентичности, а не предположением, которое снова и снова реализуется в коде приложений.

Что изменилось в AWS

Путь детализированного контроля доступа состоит из AgentCore Gateway перед ресурсом Memory, управляемого коннектора Memory и подключённого к gateway движка политик Cedar. Запросы, приходящие этим путём, могут авторизоваться по аутентифицированным OAuth/JWT-claims. Политика, например, может требовать, чтобы actor ID в запросе совпадал с claim subject аутентифицированного субъекта. Она также может ограничить извлечение пространством имён, указанным в токене.

Проверка выполняется до отправки запроса из gateway в Memory. Документированная модель политик запрещает доступ по умолчанию: действие не разрешено, пока его явно не разрешит политика. Явный Cedar forbid имеет приоритет над permit. Это важное операционное свойство: организация может выразить жёсткую границу, которая останется решающей, даже если более широкое правило в иных условиях дало бы доступ.

Через управляемый коннектор AWS представляет 12 операций Memory как действия Cedar. Среди них — создание, перечисление, извлечение и удаление событий или записей памяти, а также запуск задач извлечения. Поэтому авторизация способна различать не только идентичности и пространства имён, но и тип выполняемой операции с памятью.

Связанное обновление пространств имён даёт структуру ресурсов, необходимую таким политикам. Долговременную память теперь можно ограничивать заданными приложением измерениями: организацией, тенантом, командой или средой. Ресурс Memory поддерживает до пяти ключей пространства имён, а значения во время выполнения можно передавать через CreateEvent API. Вместо кодирования каждой организационной границы в специфичном для приложения идентификаторе памяти команды могут явно отразить эти измерения в её структуре.

Почему это важно для автономных организаций

Автономная организация не может считать постоянный контекст нерегулируемым складом удобных данных для агентов. Память влияет на последующие решения: что агент считает верным о клиенте, какое исключение он вспоминает, какую операционную историю извлекает и какую прежнюю работу представляет релевантной. Если при извлечении такого контекста агент может пересечь границу тенанта, команды или среды, нарушение происходит ещё до того, как его рассуждение станет видно в ответе или действии.

Авторизация на уровне приложения по-прежнему необходима, но она остаётся слабой единственной границей, когда к одному ресурсу памяти обращаются многие агенты, сервисы и процессы. Каждый новый путь вызова должен безошибочно повторить одно и то же сопоставление идентичностей, проверку пространств имён и ограничения операций. Так возникает дрейф политик: одна интеграция проверяет actor, другая — только тенанта, третья создаёт память с непроверенным значением пространства имён.

Подход AWS предлагает более устойчивый паттерн: разместить точку принуждения политики непосредственно на маршруте к постоянной памяти. Вопрос авторизации становится конкретным: может ли этот аутентифицированный субъект выполнить это действие над этим пространством имён при данных атрибутах запроса? Такой вопрос уже и проверяемее, чем вопрос о том, «поддерживает» ли приложение изоляцию тенантов в целом.

“Изоляция памяти — не свойство промпта агента. Это свойство пути запроса, который достигает долговременного состояния.

Для автономной организации такое разделение также проясняет ответственность. Системы идентичности устанавливают, кто или что делает запрос. Проектирование пространств имён представляет организационные границы. Cedar выражает разрешённые и запрещённые отношения. Gateway применяет решение до доступа к состоянию. Агент всё ещё может ошибочно рассуждать, но не должен обходить границу лишь потому, что в одном из путей приложения пропущено условие.

Что не изменилось

Это не универсальная защита для любого способа обращения к AgentCore Memory. Механизм с OAuth/JWT-aware enforcement действует через AgentCore Gateway, настроенный с коннектором Memory и движком политик. IAM и ресурсные политики остаются отдельными уровнями. Команда, которая сохраняет прямые маршруты или добавляет новые, всё равно должна понимать и контролировать эти пути.

Обновление также не делает каждый Memory API объектом такой проверки Cedar на уровне записи или пространства имён. AWS указывает, что три пакетные операции не представлены как действия Cedar в этом механизме. Поэтому «детализированный контроль доступа» следует понимать как определённую поверхность принуждения, а не как общее утверждение обо всём сервисе.

И главное: сама функция не создаёт изоляцию тенантов. Корректная изоляция по-прежнему зависит от достоверных identity claims, осмысленного соответствия между аутентифицированными subject и actor ID, безопасного формирования пространств имён и перевода политик из режима наблюдения в режим принуждения. AWS отдельно отмечает вопросы миграции и выравнивания для существующих схем actor ID. Хороший язык политик не исправит токен с неверным tenant; пространство имён, переданное без надлежащей проверки, не становится достоверным автоматически.

Обновление также не управляет тем, что модель решает извлечь в память, не подтверждает точность сохранённой памяти, не устанавливает правила хранения и не доказывает удаление. Это отдельные вопросы управления данными и операционного контроля. Авторизация определяет, может ли запрос обращаться к памяти. Она не решает, должна ли эта память была появиться, должна ли она ещё существовать и должна ли влиять на решение.

Практическая последовательность внедрения

Начинать следует с границы, которую необходимо сохранить, а не со списка API-действий. Определите измерения, действительно разделяющие организационную память: tenant может быть обязательным, а team, environment или application — нужны, чтобы не допустить случайного смешения внутри тенанта. Модель пространства имён должна оставаться достаточно компактной для анализа: AWS допускает пять ключей, но каждое новое измерение увеличивает число комбинаций политик и тестов.

1. Сопоставьте аутентифицированные claims со стабильными организационными идентификаторами. Не считайте отображаемое имя, сгенерированное агентом поле или прежнее соглашение об actor ID идентичностью, пригодной для авторизации.
2. Определите матрицу действий для поддерживаемых операций gateway. Разделите право создавать события и права извлекать, перечислять, удалять их или запускать извлечение.
3. Пишите политики Cedar вокруг явных отношений между principal, action и namespace, включая запреты, которые должны перекрывать широкие разрешения.
4. Сначала запустите политики в рекомендованном AWS режиме LOG_ONLY. Анализируйте реальные результаты авторизации и выявляйте устаревших вызывающих клиентов, отсутствующие claims и несовпадения пространств имён, не блокируя трафик в production.
5. Переходите к принуждению только после понимания маршрутов запросов, claims и значений пространств имён. Затем рассматривайте отказы политик как операционные сигналы, а не просто как шум безопасности.

Эта последовательность важна, потому что контроль памяти особенно легко неверно проверить. Тест политики с чистым токеном и чистым namespace мало говорит о production-среде с сервисными идентичностями, делегированными агентами, старыми actor ID и миграционным трафиком. Нужен состязательный набор тестов: действительный пользователь в чужом тенанте, действительный tenant с неверным actor, разрешённый читатель, пытающийся удалить данные, и запрос, который приходит в память в обход предполагаемого gateway.

Архитектурное следствие

AWS предоставила конкретную инфраструктурную возможность, а не решила задачу корпоративного управления памятью. Но направление верное. Постоянную память агента следует эксплуатировать как любой другой корпоративный ресурс, привязанный к идентичности: ей нужны явный адрес, аутентифицированный запрашивающий субъект, ограниченная операция и решение политики на границе доступа.

Организациям, создающим агенты для множества пользователей, не стоит считать разделение тенантов соглашением, зашитым в промпты, метки сессий или разрозненный middleware. Эти механизмы могут дополнять архитектуру, но не являются границей. Граница — это компонент, способный отклонить запрос до того, как долговременный контекст будет возвращён или изменён.

В этом и состоит практическое значение релиза. Для команд, использующих настроенный путь через AgentCore Gateway, он позволяет перенести повторяющуюся и хрупкую ответственность за авторизацию из каждого приложения агента в runtime-путь к памяти. Следующая задача — дисциплинированная реализация: согласовать идентичность, пространство имён и политику, а затем доказать, что маршрут не может незаметно обойти эти условия.