Amazon Bedrock AgentCore incorpora Policy para controlar el acceso de los agentes de AI

Amazon описала, как в Bedrock AgentCore появился отдельный механизм Policy для защиты ИИ-агентов. Его задача — проверять доступ к инструментам и данным не по «здравому смыслу» модели, а по жёстким правилам, которые исполняются независимо от её рассуждений и выносят безопасность из промптов в управляемый инфраструктурный слой.

Отдельный слой правил

Ключевая идея в том, что Policy в AgentCore создаёт детерминированный слой контроля. Даже если агент решил, что для ответа ему стоит открыть внутренний сервис, скачать файл или вызвать инструмент с повышенными правами, финальное решение принимает не он. Запрос проходит через отдельную систему правил, и только она определяет, разрешено действие или нет.

Такой подход снижает риск, когда модель ошибается в интерпретации инструкций, слишком широко понимает задачу пользователя или пытается добраться до данных, которые ей видеть не положено. AWS также описывает более удобный путь настройки таких ограничений. Бизнес-правила можно сначала сформулировать на естественном языке, а затем перевести в политики Cedar — язык, который нужен для точного описания разрешений.

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

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

Проверка на шлюзе На практике Policy применяется через AgentCore Gateway.

Этот шлюз перехватывает каждый запрос от агента к инструменту во время выполнения и проверяет его до того, как действие будет выполнено. Иначе говоря, речь не о разовой настройке в начале сессии, а о runtime-контроле: агент может десятки раз обращаться к API, базам, файловым хранилищам и внутренним сервисам, и каждый такой шаг проходит оценку по политике. Это делает защиту ближе к реальному поведению агента, а не к его изначальным намерениям.

• Кто именно инициировал запрос: конкретный пользователь, роль или группа К какому инструменту обращается агент и какое действие он хочет выполнить Имеет ли пользователь право видеть эти данные или запускать этот workflow * Нужно ли запретить, разрешить или сузить доступ в зависимости от контекста Главный акцент здесь на identity-aware доступе. Агент получает не абстрактное разрешение «работать с CRM» или «читать документы», а права, привязанные к личности и полномочиям пользователя, от имени которого он действует. Если сотруднику доступна только часть клиентских записей, агент должен видеть ту же границу. Если у менеджера есть доступ к одному набору инструментов, а у аналитика — к другому, это тоже должно соблюдаться автоматически. Такой подход особенно полезен там, где один и тот же агент обслуживает разных сотрудников с разными уровнями доступа. В результате Bedrock AgentCore предлагает не просто guardrails для ответов, а более строгую модель управления действиями.

Что это значит

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