Новости AI Security · · 7 мин чтения
AWS AgentCore ввёл temporal policies: история действий влияет на разрешение агента
AWS описал stateful-проверки последовательности инструментов, суммарного риска и одобрения человека. Разбираем урок для локального GrantTap без заявления о равенстве функций.
Агент может выполнить несколько по отдельности разумных вызовов инструментов, которые вместе создают опасный результат. За чтением недоверенного источника может последовать неожиданная передача данных в сеть. Несколько небольших операций способны превысить общий лимит, хотя ни одна отдельно его не нарушает. 6 августа 2026 года AWS опубликовала подробный разбор temporal policies для Amazon Bedrock AgentCore. Изменение состоит в том, что запрос через AgentCore Gateway можно оценить в контексте прежних событий той же trajectory, а не только по текущим аргументам.
Это новость об AWS gateway, а не объявление новой функции GrantTap. Нынешний Project Governance GrantTap применяет allow, ask и deny к поддерживаемым возможностям локальных coding-агентов, а каждый компьютер сообщает покрытие. Мы не заявляем AWS-подобное состояние trajectory, суммарные лимиты сделок или универсальный gateway для всех native действий провайдера. Но схема AWS даёт сильный вопрос и для локального контроллера: знает ли место принятия решения достаточно истории для этого действия и может ли агент обойти его? Ответ зависит от маршрута, а не от слова «policy» в меню.
Что опубликовала AWS
AWS описывает temporal policies как stateful-авторизацию запросов к целям AgentCore Gateway. Текущий запрос проверяется вместе с предыдущими событиями ограниченной agent trajectory. Статья разбирает порядок вызовов, сравнение нового аргумента с прошлым ответом инструмента, свежесть данных, общий лимит операций, одноразовое подтверждение привилегированного действия и потерю права на запись после долгого отсутствия человека. Примеры даны для гипотетического банковского сценария; их нельзя выдавать за измеренные результаты реального финансового внедрения.
Точка применения названа точно. Policy работает на периметре AgentCore Gateway, вне кода агента, для трафика, который действительно проходит через gateway. Она возвращает allow или deny и записывает контекст решения. Session связана с principal и session ID; публикация описывает ограниченное окно просмотра истории. Детали важны: новая сессия или маршрут вне gateway меняют то, что видит правило. Официальная документация AgentCore остаётся источником текущей конфигурации и ограничений сервиса.
Почему одной проверки вызова мало
Представьте coding-агента, которому разрешено читать внутренний документ и пользоваться внешним HTTP client. Простое allow для каждого инструмента не отвечает, допустимо ли отправлять текст документа по этому адресу. Правило с историей могло бы запретить защищённую последовательность, если оба действия проходят через одну enforcing boundary и нужное происхождение данных представлено в событиях. Последнее условие принципиально: gateway не сможет оценить невидимую локальную shell-команду только потому, что мы хотим видеть её в журнале.
Другой пример — повторная публикация. Человек мог одобрить один релиз, а агент попытался выполнить три. Для одноразового approval его нужно привязать к точной identity действия или погасить после использования; иначе широкое состояние «одобрено» покрывает больше задуманного. В статье AWS эту схему показывает сделка большой стоимости. Для coding-задачи аналогичный вопрос: покрывает ли согласие именно эту команду, репозиторий, ветку, назначение и время? Разбор approval в GrantTap начинает с границы исполнения.
Что GrantTap контролирует сейчас
GrantTap применяет Project Governance к поддерживаемым локальным интеграциям. Правило Project может разрешать, запрашивать или запрещать типы возможностей: skills, MCP servers, shell и scripts, запись файлов, deployment и сеть. Именованное правило относится к одной возможности. Телефон создаёт ревизию, зашифрованный маршрут доставляет её компьютерам Project, а каждый компьютер сообщает свою ревизию и статус типа: enforced, observed only, unsupported или unknown. Глобальный deny провайдера остаётся сильнее allow Project. Локальный hook оценивает покрытое действие до запуска.
Это другая единица контроля, чем AWS temporal policy. GrantTap помогает человеку решать и проверять происходящее на собственных coding-компьютерах, прежде всего по основным маршрутам Claude Code и Codex. Мы не утверждаем, что продукт восстанавливает всю причинную историю вызовов или разрешает новое действие сравнением с прошлым ответом. Native путь вне hook остаётся вне enforcement GrantTap. Выбранная policy без ответа host — намерение, а не применённое правило. Эти ограничения полезны тем, что их можно испытать вместо вывода гарантии из снимка телефона.
Сначала соберите цепочку evidence
Для разумного правила с историей нужны надёжные события. Какой процесс сделал вызов? Какая identity и версия инструмента использовалась? Инструмент завершился, упал или только получил approval? Изменился ли файл? Runtime GrantTap различает историю Invocations и подтверждённые filesystem effects; неподтверждённые изменения файла сейчас остаются неизвестными. Это правильная основа для будущего анализа, даже если из-за неё интерфейс говорит меньше. Policy engine, который питается неоднозначными событиями, может стать сложнее, но не надёжнее.
Для одного локального Project нарисуйте таблицу из четырёх колонок: запрошенное действие, действующее правило, решение host и наблюдаемый итог. Испытайте безопасную запрещённую shell-операцию и проверьте локальный отказ. Затем выполните разрешённую операцию и подтвердите результат в репозитории. Сохраните версию провайдера и ревизию policy. Если следующее действие зависит от первого, отметьте, где эту зависимость сегодня можно проверить, а где нельзя. Такое упражнение полезнее абстрактной надписи «stateful governance».
Учитывайте новые режимы ошибки
Stateful-авторизация приносит вопрос границ session. Если агент продолжил работу с новым идентификатором, наследуются ли прошлые одобрения или история пуста? Что происходит с активной session при изменении policy? Будет ли поздний ответ инструмента записан до следующего запроса? AWS отдельно обсуждает session identity, ограничение истории и сброс состояния после обновления правил. Любая система с trajectory должна документировать эти свойства, испытывать одновременные запросы и не делать старые approvals бесконечными молча.
Локальная coding-работа добавляет границы компьютера и checkout. Task в GrantTap может продолжиться на другой машине, но новое execution получит иные инструменты, coverage, credentials и revision репозитория. Историю одного host нельзя автоматически считать разрешением привилегированного действия на другом. Гид по handoff объясняет ограниченные факты, которые передаются сегодня. Если будущая policy когда-либо будет учитывать историю после передачи, ей понадобятся чёткая identity, свежие сведения host и явный предел того, какие старые события действуют.
Как читать новость без преувеличения
Примеры AWS показывают перспективный способ ограничить агентов на управляемом gateway, если через него проходят все существенные вызовы. Они не доказывают, что любое действие любого агента теперь безопасно или что prompt injection решён. GrantTap решает более узкую повседневную задачу: показывает поддерживаемую локальную coding-работу, помогает принимать ограниченные решения и сообщает coverage enforcement host, не приравнивая выбранную policy к подтверждённому использованию. Подходы могут сосуществовать, потому что покрывают разные маршруты. Практическая проверка — пройти за одним чувствительным действием от запроса агента до инструмента и найти процесс, способный отказать.
Локальную сторону раскрывают Project Mesh, руководство по Governance и usage evidence. Для AWS внедрения читайте текущую документацию сервиса и повторите пример gateway на безвредных инструментах до работы с секретами. Для GrantTap повторите запретное локальное действие на действительном провайдере и компьютере. В обоих случаях видимый отказ на конкретной границе сильнее общего описания policy.
Есть и полезный вопрос о времени: если решение человека пришло позже, чем запрос агента, какая сторона отвечает за его срок действия? Одобрение без точного идентификатора вызова может случайно оказаться разрешением для следующей попытки. В локальном сценарии проверьте, что повторённая команда создаёт новый понятный запрос, а host не принимает старое согласие как бессрочное. В сценарии AgentCore следуйте опубликованным правилам session и trajectory. История приносит пользу только тогда, когда границы её действия так же точны, как сама проверка.
