Temporal policy runtime для AI-агентов: когда IAM и sandbox уже недостаточно

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

Именно здесь заканчивается выразительность обычной проверки «субъект — действие — ресурс». Проблема не в том, что IAM настроен неправильно, а в том, что решение зависит от истории: что агент уже прочитал, чем закончилась предыдущая проверка, сколько операций он совершил за интервал и было ли получено одобрение конкретного изменения.

Для таких правил нужен отдельный слой — temporal policy runtime. Он находится между агентом и точками исполнения, ведёт доверенную историю событий и разрешает либо блокирует действие до возникновения побочного эффекта.

Однако добавить журнал вызовов и написать правило «если раньше было X, запретить Y» недостаточно. Без полного перехвата значимых операций, достоверного происхождения событий, защищённого состояния и режима fail-closed такой runtime создаёт скорее иллюзию контроля. Strands Box и Dogwood показывают перспективную архитектуру, но одновременно хорошо демонстрируют её ограничения.

Смена вопроса: разрешён ли следующий эффект в этой истории

Cedar-подобная авторизация рассматривает отдельный запрос через четыре элемента: principal, action, resource и context. Политика получает сведения о субъекте, действии, ресурсе и текущем контексте, после чего возвращает решение. Прошлые вызовы инструментов в базовую модель запроса не входят — их должен предоставить внешний компонент либо другая модель политики. Это следует из описания авторизации Cedar и архитектуры Dogwood.

Для обычного API этого часто достаточно:

• пользователь может прочитать документ;

• сервисная роль может вызвать определённый endpoint;

• агенту доступен инструмент отправки сообщения;

• запрос разрешён только для ресурса конкретного арендатора.

В агентном процессе допустимость следующего действия нередко зависит не только от текущего запроса.

Правила, которым нужна история

Запрет передачи после чтения. После доступа к конфиденциальному каталогу нельзя отправлять данные во внешнюю сеть.

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

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

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

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

Такие ограничения относятся не к идентичности агента как таковой, а к трассе его выполнения. Минимальная полезная трасса должна включать запрос, ответ, результат, время и доверенное происхождение события. Одних записей «инструмент был вызван» мало: правило, зависящее от успешности проверки, невозможно корректно вычислить без события ответа.

Почему существующие защитные слои не решают эту задачу по отдельности

Temporal runtime не является улучшенной версией IAM или заменой sandbox. Это дополнительный слой с другой областью ответственности.

IAM остаётся нижней границей привилегий

Если IAM запрещает действие, temporal runtime не должен уметь его разрешить. Политика по истории может только дополнительно сузить уже доступную поверхность.

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

Sandbox ограничивает последствия исполнения, но не смысл действий

Контейнеры и microVM уменьшают влияние недоверенного кода на хост и соседние процессы. Например, Firecracker и механизмы безопасности Docker создают границы выполнения и ограничивают доступную среду.

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

В некоторых сценариях строгая microVM с минимальным сетевым выходом будет проще и надёжнее сложного temporal runtime. Например, если задачу можно выполнить вообще без внешней сети, лучше закрыть сеть целиком. Исторические политики оправданы там, где поверхность нельзя статически разделить: один и тот же агент должен выполнять и чтение, и внешние операции, но не в опасной последовательности.

Guardrails проверяют контрольную точку, а не всю трассу

Проверки содержимого и lifecycle hooks полезны на границе модели и инструмента. AWS, например, показывает проверки входа, параметров и результата инструментов до и после вызова в материале о Strands Agents SDK.

Но набор разрозненных hooks ещё не образует temporal policy runtime. Для этого требуется общее состояние, единый порядок событий и одинаковая семантика операций из разных каналов. Иначе каждый инструмент реализует собственный счётчик, собственную проверку одобрения и собственное понимание того, что произошло раньше.

Prompt-защита не ограничивает последствия успешной манипуляции

Косвенная prompt injection попадает к модели через обрабатываемые данные: письмо, документ, результат поиска или ответ инструмента. OpenAI описывает такую атаку как социальную инженерию внутри контекста и рекомендует проектировать систему так, чтобы ограничивать последствия даже успешной манипуляции — не полагаться исключительно на способность модели распознать вредоносную инструкцию (источник).

Масштаб проблемы иллюстрирует AgentDojo: рецензируемый набор NeurIPS 2024 содержит 97 задач и 629 тестовых сценариев безопасности для агентов с инструментами и недоверенными данными (paper). Temporal policy не предотвращает принятие вредоносной инструкции моделью, но может остановить опасный эффект, к которому эта инструкция ведёт.

MCP-авторизация не описывает риск всей сессии

OAuth в MCP защищает доступ к серверу или отдельным инструментам. Аннотации инструментов дают хосту подсказки об их свойствах, но не являются достаточным механизмом исполнения политики. В материалах MCP отдельно отмечается, что риск инструмента зависит от других операций сессии, а ужесточение после чтения недоверенных данных должно происходить на уровне хоста (авторизация MCP, ограничения tool annotations).

Как должен работать temporal policy runtime

Архитектуру можно разделить на три части:

1. Точка применения политики (PEP) перехватывает предполагаемое действие до побочного эффекта.

2. Компонент принятия решения (PDP) сопоставляет текущий запрос с политиками и доверенной историей.

3. Хранилище событий сохраняет запросы, ответы, результаты, порядок и необходимые временные данные.

Поток выполнения выглядит так:

1. Агент запрашивает операцию.

2. Адаптер переводит её в каноническое событие, например fs:read или http:request.

3. Событие запроса вместе с историей передаётся компоненту принятия решения.

4. При deny операция не выполняется.

5. При allow точка применения запускает действие.

6. Результат фиксируется отдельным событием ответа.

7. История становится входом для следующего решения.

Практическая сложность сосредоточена не в синтаксисе правил, а в достоверности этой цепочки.

Полный перехват значимых эффектов

Если Python-чтение файла проходит через политику, а чтение тем же процессом через subprocess — нет, правило не обеспечивает заявленную гарантию. То же относится к сетевым путям: HTTP-клиент, curl, DNS, браузер, MCP-сервер, sidecar и отдельный credential helper могут образовывать разные каналы одного эффекта.

Поэтому нельзя говорить о «полном покрытии» абстрактно. Его всегда нужно определять относительно модели угроз и явного перечня каналов.

Доверенное происхождение событий

Агент не должен самостоятельно сообщать: «проверка пройдена» или «человек одобрил действие». Такое поле находится под контролем потенциально скомпрометированной стороны.

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

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

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

Правило «после неуспешной проверки запретить изменение» выглядит просто только при последовательном выполнении. При параллельных вызовах возникают вопросы:

• что считать более поздним событием;

• может ли изменение начаться одновременно с проверкой;

• когда фиксируется успех — до или после сохранения ответа;

• что произойдёт при сбое между побочным эффектом и записью результата;

• можно ли использовать старый успешный результат после более новой ошибки.

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

Fail-closed должен быть свойством конкретной точки применения

Недоступность policy engine нельзя обрабатывать единообразно для всех операций. Для необратимого перевода средств или внешней публикации разумен fail-closed: нет решения — нет действия. Для локального чтения некритичного кэша требования могут быть другими.

Но выбор должен быть явным. Если при тайм-ауте адаптер молча продолжает вызов, temporal policy не является контуром безопасности для этой операции.

История политики и журнал аудита — не одно и то же

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

Это правильное разделение. Рабочее состояние policy engine может оптимизироваться и очищаться по правилам хранения. Аудит должен независимо отвечать, что было запрошено, какая версия политики использовалась, какое решение получено и был ли эффект действительно выполнен.

Strands Box и Dogwood: что показывает референсная архитектура

Согласно анонсу AWS, Strands Box была представлена 7 октября 2026 года как developer preview под Apache-2.0. На дату источника поддержка начиналась с macOS, а перенос на другие операционные системы был обозначен как будущая работа.

Архитектура объединяет два типа контроля:

• изоляция на уровне ОС ограничивает достижимую поверхность;

• Dogwood определяет допустимость действий внутри этой поверхности с учётом истории.

Точки применения политик размещены на исходящем сетевом трафике, интерпретаторах Shell и Python, а также MCP broker. Операции из разных путей приводятся к общей семантике: чтение файла через Shell и Python становится fs:read, а HTTP через curl и библиотеку Python — http:request.

Именно нормализация делает возможной межинструментальную политику. Правило «после чтения customer-data запретить внешний HTTP» должно сработать независимо от того, какой интерпретатор выполнил чтение и какой клиент инициировал запрос.

Цена семантического перехвата

Чтобы увидеть операцию до её выполнения, Strands Box выносит интерпретаторы Shell и Python за sandbox. Это повышает наблюдаемость и позволяет принимать решение на уровне осмысленного действия, а не только системного вызова.

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

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

Известная граница покрытия

Демонстрация Strands Box одновременно показывает главный риск этой архитектуры: доступ к файловой системе, напрямую выданный агенту через box.toml, не входит в историю политики. Если действие прошло в обход точки применения, Dogwood о нём не узнает.

Следовательно, правило может быть логически правильным, а фактическая гарантия — неполной. Это не мелкая особенность настройки, а фундаментальный вопрос complete mediation: все ли значимые пути проходят через контролирующий слой.

Учётные данные за шлюзом

Шлюз исходящего трафика Strands Box может подставлять или подписывать учётные данные только для разрешённого запроса. Указаны bearer- и пользовательские заголовки, basic auth, параметры строки запроса и AWS SigV4. Агент работает с заполнителем и не получает реальный секрет.

Это уменьшает риск кражи учётных данных из контекста или процесса агента. При этом привязка учётных данных сама по себе не открывает сеть: запросу всё равно нужна разрешающая политика. И наоборот, шлюз не отменяет IAM — конечный сервис должен продолжать проверять полномочия выданной идентичности. Для облачных доступов следует сохранять практику короткоживущих учётных данных, описанную в AWS IAM User Guide.

Где temporal runtime действительно оправдан

Многие ограничения можно реализовать без нового языка политик:

• лимиты — на API gateway;

• одобрения — в workflow engine;

• последовательность — в конечном автомате процесса;

• фильтрацию данных — в DLP;

• доступ к строкам — через RLS;

• запрет сети — на уровне sandbox.

Если агент выполняет один фиксированный процесс через один API, специализированный workflow часто проще и надёжнее. Отдельный temporal runtime начинает окупаться, когда одно ограничение должно одинаково действовать между несколькими инструментами и путями исполнения.

Хорошие кандидаты:

• инварианты между файловой системой, HTTP, Shell, Python и MCP;

• необратимые или дорогостоящие операции;

• процессы, где решение зависит от результата предыдущего шага;

• лимиты, которые должны учитывать действия через разные инструменты;

• единая модель одобрений для нескольких исполнительных сред.

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

Нужно учитывать и фундаментальное ограничение: runtime регулирует наблюдаемые эффекты, но не удаляет данные из контекста модели. Если конфиденциальная информация уже попала в контекст или существует неперехваченный канал, блокировка HTTP не устраняет знание модели и не закрывает все способы утечки.

Как проверить архитектуру до внедрения

На дату материалов Strands Box остаётся developer preview. В dossier нет независимых публичных измерений эффективности, накладных расходов, совместимости или промышленного применения. AWS также не приводит сопоставимого испытания против вариантов IAM-only, allowlist-only, hooks/guardrails или microVM-only.

Собственный испытательный стенд в этой статье не запускался, а измерения не проводились. Поэтому ниже приведён воспроизводимый протокол, а не результаты; обсуждать следует не предполагаемые числа, а методику.

Безопасный испытательный стенд

Стенд не должен использовать рабочие секреты и персональные данные. Достаточно следующих компонентов:

• синтетический каталог customer-data;

• локальный сборщик HTTP-запросов;

• тестовый MCP-сервер;

• локальная служба одобрений;

• инструмент проверки, способный возвращать success и failed;

• два адаптера агентных сред с одинаковой канонической схемой событий.

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

Сравнивать нужно несколько контуров

Минимально полезное сравнение включает:

1. IAM или временные учётные данные плюс список разрешённых инструментов.

2. Только prompt-level инструкции.

3. Hooks или guardrails на границе инструмента.

4. Sandbox или microVM со списком разрешённого исходящего трафика.

5. Sandbox вместе с temporal policy runtime.

Цель не в том, чтобы объявить пятый вариант победителем. Нужно увидеть, какие атаки останавливает каждый слой, какой ценой и какие пути остаются открытыми.

Матрица политик

Практический набор тестов может состоять из четырёх правил:

P1. Запрет передачи после чтения. После fs:read из customer-data блокировать внешний HTTP. Если endpoint модели должен остаться доступным, исключение необходимо описать строго и проверить отдельно.

P2. Лимит операций. Разрешать не более N POST за T. Отдельно протестировать политику, считающую запросы, и политику, считающую только успешные ответы.

P3. Одобрение записи. До подписанного одобрения доступны только операции чтения. Одобрение привязано к действию, аргументам и сроку действия.

P4. Блокировка после неуспешной проверки. После failed response запрещать изменения до новой успешной проверки. Обязательно проверить устаревший успех, параллельные вызовы и восстановление после сбоя.

Каждое правило следует попытаться обойти через альтернативные пути: curl, библиотеки Python, subprocess, перенаправление Shell, другой MCP-инструмент, варианты DNS и IP. Если такой путь входит в модель угроз, но не проходит через точку применения, его нужно считать непокрытым, а не «не относящимся к тесту».

Какие метрики предусмотреть в протоколе

Покрытие исполнения:

число опасных путей, остановленных до побочного эффекта / число всех заранее определённых опасных путей.

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

Задержка: отдельно измеряются p50, p95 и p99 для решения политики, долговременной записи события и полного вызова инструмента. Смешивание этих величин не позволяет понять источник накладных расходов.

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

Радиус поражения: сколько файлов, доменов, API, учётных данных и необратимых эффектов остаются достижимыми после имитации компрометации агента.

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

Практическая схема внедрения

Temporal policy runtime следует вводить как дополнительный контур, а не как центральную замену всей безопасности.

1. Сохранить IAM, RLS и авторизацию конечных сервисов как нижнюю границу. Runtime не выдаёт прав, отсутствующих у основной идентичности.

2. Минимизировать статически доступную поверхность. Ненужные файлы, домены и инструменты лучше закрывать безусловно.

3. Держать секреты за шлюзом и использовать короткоживущие учётные данные. Агенту передаётся ссылка или заполнитель, а не реальный секрет.

4. Применять исторические правила к межинструментальным инвариантам и критичным эффектам. Не переносить в новый слой то, что проще выразить сетевым запретом или RLS.

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

6. Переводить в fail-closed узкий список операций. В первую очередь — внешнюю публикацию, изменение критичных данных и другие необратимые действия.

7. Защитить хранилище истории, часы, политики и адаптеры как критические активы. Компрометация этих компонентов эквивалентна компрометации самого контура авторизации.

8. Проверять восстановление после сбоев и параллельность. Правильная работа на последовательной демонстрации не доказывает корректность в реальном процессе.

9. Вести независимый журнал аудита. Он должен связывать запрос, версию политики, решение и фактическое исполнение эффекта.

Temporal authorization можно считать инфраструктурным примитивом только после доказательства четырёх свойств: значимые действия полностью перехватываются до эффекта, история достоверна и сохранна, критичные точки работают в режиме fail-closed, а семантика политик переносится между целевыми агентными средами.

До этого момента перед нами полезный, но локальный middleware конкретного harness. Он может заметно снизить риск — особенно для правил, связывающих несколько инструментов, — но не должен получать больше доверия, чем подтверждено трассами, негативными тестами и эксплуатационными испытаниями.