Свежесть состояния — плохой контракт для LLM-агента

Изменение состояния между чтением и записью не всегда делает действие LLM-агента опасным: защита, которая блокирует любую несвежую операцию, отбрасывает и допустимые изменения. Хотя препринт не прошёл рецензирование и числа получили сами авторы, работа Washington University in St. Louis и Southern Methodist University показала: такие проверки лишали систему до 43% безопасных завершений. Для инфраструктурного агента важнее перепроверить смысл операции перед записью, чем сам факт изменения данных.

Как отделили опасную гонку от безвредного изменения

Агент сначала читает состояние ресурса, выбирает действие и только затем пытается его применить. В этот промежуток другой процесс может изменить ресурс: задача сменит статус, политика доступа запретит операцию или предыдущая попытка уже успеет выполнить нужное действие.

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

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

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

Проверка охватила 16 инфраструктурных задач из планировщиков, конвейеров данных, хранилищ и систем управления доступом. Три локальные квантованные модели — Qwen3-4B, Phi-4-mini и Gemma4-8B — сформировали 3456 траекторий в детерминированном симуляторе. Такой масштаб позволяет сравнить защиты в одинаковых условиях, но не переносит результат автоматически на крупные размещённые модели и реальные задержки производственной инфраструктуры.

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

Все три защиты остановили опасные записи. Разница проявилась на безвредных гонках: проверки свежести ошибочно блокировали 92–95% таких ситуаций, тогда как полное семантическое условие не остановило ни одной допустимой операции.

Причина в том, что версия отвечает только на вопрос, менялся ли ресурс. Условие безопасности отвечает на другой вопрос: остаётся ли конкретное действие допустимым прямо сейчас. Для удаления объекта это может означать, что объект по-прежнему ничем не используется; для выдачи роли — что политика всё ещё разрешает доступ; для повтора задачи — что предыдущий запуск не завершился успешно.

Преимущество исчезало вместе с полнотой контракта. Когда из условия убирали одну проверку, защита начинала пропускать именно связанный с ней класс сбоев; доля опасных записей доходила до 7,9%. Механизм исполнял контракт точно, но не мог компенсировать забытое правило.

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

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

Что менять в архитектуре инфраструктурного агента

Работа меняет не выбор LLM, а границу между моделью и системой исполнения. Если агент перезапускает задания, удаляет объекты или меняет права, окончательное решение нельзя строить только на версии прочитанных данных, возрасте снимка или уверенности модели.

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

Практический план состоит из трёх частей:

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

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

Источники

• Stale Does Not Mean Unsafe: Guard Precision for Tool-Using LLM Agents under Infrastructure State Races