Двойной контроль для AI-агентов: как AWS фильтрует запросы

Когда AI-агент начинает работать с реальными данными, вопрос безопасности выходит на первый план. Мало того, что нейросеть должна давать правильные ответы, - нужно ещё контролировать, кто и откуда эти ответы запрашивает. Amazon показал, как решают эту задачу в Bedrock AgentCore: комбинируют жёсткие правила доступа с динамическими проверками через Lambda-функции. Разберёмся, зачем это нужно и как устроено.

Почему одного слоя проверок недостаточно

Любая система контроля доступа строится на правилах. Можно задать список стран, IP-адресов или ролей пользователей, которым разрешён доступ. Это называется детерминированным контролем - статический набор условий, который не меняется от запроса к запросу.

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

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

Как устроена связка Policy и Lambda

В демонстрации Amazon показали агента для работы с lakehouse - это гибридное хранилище, которое объединяет данные из озёр данных (data lakes) и традиционных хранилищ. Агент получает доступ через политику, где прописаны базовые правила: какие действия разрешены, какие источники данных доступны.

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

На практике это выглядит как цепочка: сначала запрос проходит через статический фильтр, затем попадает в Lambda для динамической проверки. Если хотя бы один этап даёт отказ, агент не получает данные. Такой двойной контроль снижает риск, что один слой пропустит что-то лишнее.

Подводные камни: тайм-ауты и отладка

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

Ещё один нюанс - согласованность данных. Список запрещённых стран может меняться, и Lambda должна получать актуальную информацию. Если политика и динамическая проверка используют разные источники, возможны расхождения. Например, политика разрешает запрос из страны, а Lambda блокирует, потому что её список устарел или, наоборот, обновился раньше.

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

Кому это нужно и когда оправдано

Такая схема контроля в первую очередь важна для компаний, которые работают с данными из разных стран и должны соблюдать локальные законы. Например, если агент обрабатывает персональные данные граждан ЕС, нужно блокировать запросы из стран, не соответствующих GDPR. Или если данные содержат коммерческую тайну, доступ из определённых регионов должен быть запрещён на уровне политики компании.

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

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

Что в итоге

AWS показал рабочий пример, как совместить жёсткие правила и гибкие проверки для AI-агентов. Подход не новый - похожие схемы используют в веб-приложениях и API-шлюзах. Но для AI-агентов, которые всё чаще получают доступ к корпоративным данным, такой контроль становится стандартом безопасности.

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