AWS показал, как не дать LLM-агенту читать чужие документы: userContext подставляет шлюз

Представьте внутреннего ассистента, которым пользуется вся компания. Сотрудник отдела A просит: «Сравни план моего отдела с общим уведомлением и покажи отстающие инициативы». Агент сам формулирует поисковые запросы и копает по документам, пока не наберёт достаточно информации. Тот же вопрос задаёт сотрудник отдела B. Если поиск не привязан к конкретному человеку, бизнес-план одного отдела легко окажется в ответе другому. В мультиарендном SaaS то же самое случается с клиентскими компаниями, и цена ошибки там выше.

AWS Machine Learning Blog выпустил разбор, как закрыть эту дыру в связке Amazon Bedrock Managed Knowledge Base и AgentCore Gateway.

Почему с агентами сложнее, чем с обычным приложением

В классическом приложении код сам знает, кто вошёл в систему, и ищет с правами этого пользователя. В агенте инструмент вызывает LLM, и аргументы тоже выбирает она. Если у поискового инструмента есть параметр «от чьего имени искать», его заполнит модель. Хватит фразы пользователя «поищи как user-b», ошибки модели или косвенной prompt injection в найденном документе, и агент ищет под чужой личностью.

У Managed Knowledge Base есть режим ACL awareness. При загрузке данных база запоминает права на документы, а при поиске отдаёт только то, что разрешено пользователю из userContext.userId (это его email). Но сама база пользователей не аутентифицирует, она верит тому, что пришло. А когда её публикуют как MCP-инструмент через AgentCore Gateway, userContext становится обычным аргументом, который строит модель. Ни шлюз, ни база не проверяют, что значение принадлежит вошедшему человеку.

Четыре слоя: два основных и два страховочных

Принцип простой: LLM не решает, кто пользователь. Это решает доверенный код на основе данных, которые проверил провайдер идентификации. Запрос проходит так:

• Пользователь входит через Amazon Cognito и получает JWT. Lambda-триггер pre token generation добавляет в токен claim с email.
• Агент пересылает токен в заголовке Authorization, а авторизатор шлюза проверяет подпись, срок действия и client ID.
• Request interceptor, то есть Lambda на шлюзе, достаёт email из проверенного токена и перезаписывает userContext в каждом вызове tools/call. Что бы ни прислал клиент или модель, база получит email реального пользователя. Батчи и невалидные тела запросов отклоняются по принципу fail-closed.
• Policy in AgentCore проверяет Cedar-политикой, что userContext.userId совпадает с email из JWT. Если нет, запрос отклоняется.
• Resource-based policy базы знаний запрещает поиск всем, кроме роли выполнения шлюза.

Первые два слоя (перехватчик и ACL) — основная защита. Для запросов через шлюз их достаточно, если больше никто не может обратиться к базе напрямую. Cedar-политика и resource-based policy нужны на случай бага в перехватчике или постороннего принципала с правом bedrock:Retrieve в том же аккаунте. Сам агент на Strands Agents логики доступа не содержит: он просто пробрасывает токен дальше.

Подводные камни

• ACL для S3 задаются глобальным файлом на префикс или метафайлом на документ. Документ без ACL просто не попадёт в индекс.
• Изменения прав применяются только после следующей синхронизации: проверки в реальном времени у S3 нет.
• Ошибки в ACL не вызывают исключений, документы тихо исчезают из выдачи. Проверяйте это тестами.
• Запрос без userContext не вернёт документы из источника с включёнными ACL, зато документы из источника без ACL увидят все.
• Для кастомизации access token в Cognito нужен план Essentials или Plus. На Lite email в токене не появится.
• Чтобы перехватчик мог записать userContext, его нужно открыть в схеме инструмента через parameterOverrides, даже если клиенты его не задают.

Что с этим делать

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

Готовый пример на CDK лежит в репозитории sample-managed-knowledge-base-patterns, в каталоге agentcore-access-control. Оговорка: это схема для стека AWS, и на других платформах её придётся воспроизводить самостоятельно.