Amazon Quick вынесла защиту агентов в структуру данных

Amazon Web Services опубликовала практическую схему защиты Amazon Quick при переходе от пилота к production. Quick объединяет dashboards, Chat Agents, Flows, Spaces и knowledge bases, поэтому обычной настройки доступа к отчёту уже недостаточно. В учебном сценарии AnyCompany работает 5000 сотрудников, пять подразделений и пять локаций, а одним и тем же HR-источником пользуются руководство, менеджеры и весь штат.

Главный принцип AWS — уменьшать доступный контекст до того, как запрос попадёт к агенту. Исходные данные превращаются в три отдельных представления: полный HR-датасет с зарплатами и attrition risk, набор для менеджеров без чувствительных столбцов и с Row-Level Security, а также агрегированная таблица по подразделениям и локациям без персональных записей. К каждому набору подключается отдельный агент и соответствующий dashboard.

Отсутствующее поле надёжнее запрета в prompt

AWS подчёркивает: набор столбцов определяет верхнюю границу того, что пользователь вообще может увидеть. Если зарплата удалена из downstream-датасета, ошибочная группа или слишком широкое правило sharing не смогут внезапно открыть её рядовому сотруднику. Для менеджерского представления RLS связывает пользователя или группу с конкретным значением Department; правило должно проверяться как минимум на HR-администраторе и обычном менеджере.

Это меняет роль системного prompt. Инструкции агента всё ещё задают поведение — например, требуют отвечать только агрегатами и отказывать в запросе зарплаты конкретного человека. Но реальная граница проходит не по тексту запрета, а по доступному источнику. AWS предлагает подключать агента ровно к одному датасету, исключать ненужные темы и отдельно тестировать adversarial-запросы от каждой пользовательской роли.

Такой подход уменьшает радиус prompt injection и человеческой ошибки, но не отменяет тестирование. Ошибка в подготовке датасета или RLS-сопоставлении по имени пользователя способна либо показать лишнее, либо вернуть ноль строк. Поэтому production-проверка должна подтверждать фактические ответы под разными учётными записями, а не только конфигурацию в консоли.

Knowledge base наследует отдельную модель риска

Для документов AWS вводит ещё более жёсткое правило. Все материалы knowledge base доступны для запроса пользователям с Viewer-доступом к Space. Поэтому файл с индивидуальными performance reviews в демонстрации не ограничивают дополнительным permission — его вообще не загружают в общий Space. Если он нужен HR, для него следует создать отдельный Space, доступный только руководству.

Внутри Space роли делятся на Owners, которые могут читать, задавать вопросы и загружать документы, и Viewers, которым доступны только чтение и запросы. AWS рекомендует классифицировать каждый документ до загрузки, разделять права upload и query и не помещать PII в общую базу без явной необходимости. Это важная деталь для RAG-систем: фильтрация ответа после retrieval слабее, чем исключение закрытого документа из области поиска.

Действие отделено от рекомендации

В примере Weekly Attrition Risk Alert Flow находит сотрудников с высоким риском ухода и готовит уведомления менеджерам. Но отправка не происходит сразу: workflow ставится на паузу на шаге Human Approval Process и продолжает работу только после явного approve. Внешние credentials предлагается хранить в AWS Secrets Manager, а не внутри определения Flow.

Для аудита AWS использует CloudTrail. Команда должна видеть идентичность пользователя, время, событие и ARN ресурса для управленческих операций Quick, а также проверять события после тестов агента и запуска Flow. Вместе с группами вместо индивидуального sharing это формирует повторяемую операционную модель: новый сотрудник получает доступ через membership, а новая зона конфиденциальности создаёт новый датасет или Space.

Почему это важно

Кейс полезен тем, что переносит безопасность agentic analytics из области обещаний модели в проверяемую архитектуру. Данные сокращаются заранее, агенты изолируются по назначению, документы классифицируются до ingestion, а действие получает approval gate. Каждое ограничение можно проверить отрицательным тестом: закрытого столбца нет, чужая строка не возвращается, документ не ищется, уведомление без подтверждения не отправляется.

Практический вывод — перед выпуском корпоративного агента составить матрицу «аудитория → данные → агент → действие». Для каждой строки нужен отдельный тестовый пользователь и набор запросов на обход границ. Чувствительные поля следует удалять из доступного представления, а не только скрывать UI или prompt. Любой Flow, который пишет во внешнюю систему или отправляет сообщения, должен иметь явное подтверждение, защищённые credentials и журнал. Именно такие технические границы масштабируются лучше, чем надежда на дисциплинированный ответ LLM.