Strands Box: семантические политики и безопасная песочница для AI-агентов

У AI-агентов уже хватает реальной работы: разработка ПО, операционные задачи, обслуживание клиентов, внутренние бизнес-процессы. Но вместе с пользой быстро приходит вполне земной вопрос: кто и как ограничит действия агента? Нужны не абстрактные обещания «безопасности», а понятный контроль, изоляция и возможность проверить, почему агенту было разрешено одно действие и запрещено другое.

AWS последовательно вкладывается в эту область. Прошлым летом компания представила AgentCore — платформу для создания и эксплуатации агентов. В её основе лежит AgentCore Runtime: защищённая среда выполнения, где каждая сессия агента получает выделенную MicroVM на базе Firecracker. Затем появился AgentCore Policy с детальным управлением доступом агентов к инструментам на языке Cedar. Позже AWS открыла исходный код Dogwood — языка политик для определения разрешённых агенту действий, а также представила локальный runtime Dogwood Local Engine.

Теперь к этой экосистеме присоединяется Strands Box: локальная open-source-песочница для AI-агентов, доступная в предварительной версии для разработчиков. Она сочетает изоляцию на уровне ОС с семантическими политиками Dogwood. Проще говоря, команда может задать не только перечень доступных агенту ресурсов, но и условия, при которых он вправе ими пользоваться. Для корпоративной безопасности AI-агентов это уже не факультативная деталь, а рабочая основа.

Strands Box не зависит от конкретной модели, облака или агентного фреймворка. Агент может обращаться к инструментам напрямую, использовать MCP, генерировать команды shell или код Python — Box остаётся прослойкой контроля. Он также не привязан к Strands Harness SDK, хотя AWS рекомендует познакомиться со Strands Harness.

Политики, которые понимают смысл действия

Главная идея Strands Box — семантическая политика. Вместо грубого правила «разрешить» или «запретить» можно описать контекст. Например: разрешить git push, только если тесты успешно выполнены; позволить агенту вызывать платёжный API, но не больше чем на 100 долларов в день; ограничить число обращений к определённому MCP-серверу. Вот где начинается настоящая архитектура AI-агентов, а не просто запуск LLM с доступом ко всему подряд. Такие же правила — что агенту можно, сколько раз и при каких условиях — мы задаём, когда ставим AI-агенту ограничители и журнал всех действий.

Агенты ценны именно тем, что умеют находить путь к цели в неструктурированной ситуации. Если процесс полностью известен и однозначен, зачастую дешевле и надёжнее собрать обычный рабочий процесс. Но когда агенту дают свободу исследовать варианты, возникает противоречие: слишком жёсткие рамки убивают полезность, слишком мягкие — открывают дверь сюрпризам. Обычно неприятным.

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

Например, следующая политика запрещает git push, если после последнего git add в течение 15 минут не был успешно выполнен npm test:

forbid (principal, action == Box::Action::"shell:spawn", resource)
when { context.input.program == "git" && context.input has arg1 && context.input.arg1 == "push" }
unless temporal {
  (!Box::Action::"shell:spawn"::response{ input.program: "git", input.arg1: "add" }
   since within 15m
   Box::Action::"shell:spawn"::response{
     input.program: "npm", input.arg1: "test", input.arg_count: 1,
     input.cwd: "~/my-project", output.status: 0
   })
};

Это, конечно, не исчерпывающая защита: например, команда git switch способна изменить ситуацию так, что гарантия окажется неполной. Но пример хорошо показывает подход. Политика должна разрешать необходимое и перекрывать нежелательное — без магии, просто аккуратная инженерия.

Другой сценарий: ограничить агента 60 вызовами AWS MCP Server в час.

forbid (principal, action == Box::Action::"mcp:call", resource)
when { context.input.server == "aws" && context.input.method == "tools/call" }
when temporal {
  exists (n: Long). (
    (count for (t: Timepoint). where (
      formerly within 1h (
        Box::Action::"mcp:call"::request{
          input.server: "aws", input.method: "tools/call"
        } && tp(t)
      )
    )) == n && n >= 60
  )
};

Такие ограничения нужны не только для платных API. Они помогают делить квоты между агентами, сдерживать непредсказуемую активность и не получать в конце месяца счёт, от которого хочется молча закрыть ноутбук.

Политики Dogwood поначалу могут показаться сложными. Это честное впечатление. AWS планирует упростить их создание, чтение и сопровождение. При этом современные агенты для программирования уже неплохо работают с Dogwood без специальных плагинов и отдельного обучения.

Почему одной песочницы недостаточно

Изоляция недоверенных или частично доверенных нагрузок — задача старая, почти классическая. За десятилетия появились MicroVM, контейнеры, фильтрация системных вызовов, эмуляция ядра и множество гибридных подходов. У каждого есть сильные стороны. И свой ценник в виде компромиссов.

MicroVM, например Firecracker, обеспечивают сильную изоляцию, компактную доверенную вычислительную базу и высокую производительность. Однако на уровне виртуального оборудования сложно выразить богатые политики. Сетевая карта видит в основном TLS-шифротекст, а блочное устройство — операции наподобие «прочитать N байт со смещения X». Для надёжной грубой изоляции это отлично; для понимания того, какой MCP-вызов совершил агент, — уже нет.

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

Некоторые проекты, включая gVisor, решают часть проблемы через эмуляцию системных вызовов и ядра. Это сильный подход, но его семантического уровня всё равно недостаточно для полноценных политик над MCP-вызовами, инструментами и логикой конкретных программ.

Strands Box использует двухслойную модель. Ядро ОС изолирует процесс, а все контакты с внешним миром направляются через единый слой политик. Благодаря этому Box может применять правила к MCP-запросам, shell-командам, Python-программам, файловой системе и сети. Такой подход особенно актуален при разработке AI-агентов и автоматизации, где у агента часто есть доступ сразу к нескольким системам.

Компромиссы никуда не деваются

У этого решения есть цена. Strands Box должен доверять большему объёму кода: интерпретаторам, перехватчикам протоколов и другим компонентам доверенной вычислительной базы. AWS пишет этот код на Rust и инвестирует в тестирование, фаззинг и валидацию. Но базовый закон безопасности остаётся прежним: больше кода — больше потенциальных ошибок. В данном случае ошибка может стать обходом политики.

Для мультитенантных облачных развёртываний AWS рекомендует сочетать Box с выделенной MicroVM для каждой сессии агента. Один из удобных вариантов — запускать Box внутри AgentCore Runtime. Похожую схему можно собрать и на EC2, Lambda или Fargate. В результате детальные локальные правила применяются в Box, управление вызовами инструментов обеспечивается AgentCore Policy, а MicroVM создаёт прочную границу между сессиями.

Общая картина

Strands Box — ещё один шаг в развитии управляемых AI-агентов: с изоляцией, проверяемыми правилами и контролем действий на уровне их смысла. AWS развивает эту линию и в облачных сервисах — Bedrock и AgentCore, — и в open-source-проектах Dogwood, Strands и связанных инструментах.

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

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

Источник: strandsagents.com