AWS Bedrock AgentCore: políticas de segurança e interceptadores Lambda para agentes de IA

AWS Machine Learning Blog опубликовал материал о том, как Amazon Bedrock AgentCore — платформа AWS для развёртывания и эксплуатации ИИ-агентов — помогает встраивать контроль доступа непосредственно в инфраструктуру автономных систем. В качестве примера авторы используют так называемого lakehouse-агента — ИИ-агента, работающего с данными в озере данных (data lakehouse), — чтобы показать, как совместить два разных механизма защиты: Policy для детерминированного контроля доступа и Lambda-перехватчики (Lambda interceptors) для динамической проверки запросов в реальном времени.

Как работают два уровня контроля доступа

Policy в терминологии материала — это детерминированный, основанный на жёстких правилах механизм: он заранее описывает, какие действия агент может совершать с определёнными ресурсами, и применяется одинаково при каждом обращении, независимо от контекста конкретного запроса — по аналогии с классическими политиками управления идентификацией и доступом (IAM), которые давно используются для людей и сервисных учётных записей. Lambda-перехватчики устроены иначе: это пользовательские бессерверные функции на базе AWS Lambda, которые выполняются непосредственно в момент запроса и умеют учитывать условия, которые невозможно заранее зашить в статичное правило, — например, вычисляемые в реальном времени значения, состояние внешних систем или сигналы о фактическом контексте конкретного обращения агента.

Зачем совмещать детерминированный и динамический контроль?

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

Что это значит для разработчиков агентов на Bedrock

Для команд, которые строят автономных агентов поверх Amazon Bedrock AgentCore, связка двух этих механизмов открывает путь к запуску систем в регулируемых отраслях — финансах, здравоохранении, работе с трансграничными данными, — где требования комплаенса меняются в зависимости от юрисдикции и не могут быть покрыты одним статичным набором ролей. Пример lakehouse-агента демонстрирует реалистичный корпоративный сценарий: агент, которому в целом разрешён широкий доступ к данным озера данных для аналитических задач, тем не менее не должен иметь возможности обращаться к данным вне своей географической или регуляторной зоны ответственности, даже если технически у него есть сетевой доступ ко всему хранилищу. Такой двухуровневый подход к контролю — детерминированные правила плюс динамическая проверка в момент запроса — становится практическим ответом на более широкий вызов, с которым сталкивается вся отрасль по мере того, как ИИ-агентам делегируют всё больше самостоятельных действий с реальными, зачастую конфиденциальными корпоративными данными.

Важно и то, что оба механизма встроены непосредственно в платформу Amazon Bedrock AgentCore, а не реализованы силами команды разработки поверх неё с нуля: Policy и Lambda-перехватчики выступают как готовые примитивы, которые можно комбинировать под конкретный сценарий, будь то геозависимые ограничения, разграничение доступа по отделам внутри компании или проверка соответствия запроса регуляторным требованиям конкретной отрасли. Такой подход снижает вероятность того, что каждая команда будет заново изобретать собственную, потенциально уязвимую схему контроля доступа для своих агентов, и приближает управление правами ИИ-агентов к зрелости, привычной для традиционных облачных сервисов AWS.

Показательно и то, что материал разбирает именно lakehouse-агента — то есть систему, работающую с аналитическими данными компании, а не с второстепенными служебными процессами. Выбор такого примера подчёркивает, что вопрос контроля доступа для AWS Bedrock AgentCore не абстрактный, а привязан к реальному классу задач, где агенту действительно требуется широкий, но при этом строго очерченный доступ к большим массивам корпоративной информации, и где ошибка в настройке прав способна затронуть данные сразу многих подразделений и юрисдикций одновременно.