Три корректных разрешения привели к превышению лимита: как гонка состояний ломает контроль над ИИ-агентами
Habr AI · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Исследователи продемонстрировали, что стандартные механизмы авторизации могут допускать превышение общего бизнес-лимита при параллельном выполнении задач. Проблема решается не улучшением логики проверки, а атомарным резервированием части разрешения до исполнения действия.
Статья раскрывает архитектурную уязвимость, критичную для внедрения автономных ИИ-агентов в бизнес-процессы. Она показывает, что локальная корректность отдельных шагов не гарантирует соблюдения глобальных ограничений, установленных человеком, что требует пересмотра подходов к управлению правами доступа.
В сфере разработки систем с ИИ-агентами возникает фундаментальный вопрос: как предоставить модели достаточную автономию для выполнения задач, не позволяя ей выйти за рамки делегированных полномочий. Недавний технический разбор демонстрирует конкретный сценарий, в котором человек разрешил workflow заказать не более 100 единиц товара. Система сформировала три отдельных заказа по 40 единиц каждому поставщику. Каждый запрос прошел через слой авторизации и получил статус ALLOW, однако итоговое состояние в ERP-системе составило 120 единиц. Ни один отдельный заказ не превысил лимит, и ни один запрос не обошел контроль, но совокупный результат оказался недопустимым.
Автор исследования объясняет, что проблема кроется в несоответствии между формулировкой разрешения и логикой его проверки. Человек задает общий предел для всей задачи, тогда как простейшая проверка отвечает на вопрос о допустимости конкретного шага. Это приводит к ситуации, где локально допустимые действия складываются в глобально недопустимый результат. Для верификации этого механизма был создан воспроизводимый стенд с детерминированным планировщиком, исключающий влияние качества рассуждений языковых моделей на результаты эксперимента.
В последовательном режиме работы stateful-контроль успешно отслеживает накопленное потребление и блокирует третий запрос, оставляя в системе 80 единиц. Однако при конкурентном исполнении возникает классическая гонка состояний (check-then-act). Три обработчика одновременно читают нулевое значение расхода, принимают решение о разрешении и лишь затем обновляют состояние. В результате все три заказа исполняются, а общий объем превышает лимит. Эта уязвимость не специфична для ИИ и возможна в любом сервисе, где допуск к действию не связан атомарно с общим состоянием.
Решением становится внедрение операции резервирования. В исправленном варианте gateway выполняет транзакцию: блокирует строку данных, проверяет остаток лимита и сразу списывает запрашиваемую величину в статус RESERVED до обращения к внешней системе. Если один запрос зарезервировал 40 единиц, эти единицы становятся недоступны для других операций. При конкурентном прогоне два заказа получают ALLOW, а третий отклоняется с ошибкой DENY_CAPACITY, так как доступный остаток составляет лишь 20 единиц. Итог в ERP остается равным 80, что соответствует заданному лимиту.
Для агентных систем этот подход особенно важен, поскольку люди делегируют не фиксированный список API-вызовов, а результат: «закупи до X единиц» или «верни не более Y рублей». Модель разбивает цель на действия, которые могут выполняться параллельно или передаваться субагентам. Авторизация на уровне отдельных инструментов необходима, но недостаточна. Контроль должен оперировать общим идентификатором разрешения (grant), его скоупом и остатком. Модель не должна сама решать, достаточно ли у нее полномочий; это задача enforcement point на границе исполнения.
Исследователи подчеркивают разницу между различными слоями свидетельств: решение авторизации, вызов исполнителя и устойчивое состояние целевой системы отвечают на разные вопросы. Результаты эксперимента рассчитаны по полным сохраненным записям ERP, прочитанным отдельным компонентом, а не по логам авторизации. Также отмечается важность обработки неизвестных результатов: если внешняя система не ответила после ALLOW, зарезервированное полномочие должно оставаться списанным до завершения процесса согласования (reconciliation).
В заключение автор предлагает пять ключевых вопросов для проверки перед внедрением в production: что именно разрешил человек, как связаны действия с одним grant, связан ли ALLOW с атомарным резервированием, могут ли параллельные ветки потратить один остаток и как подтверждается итог. Эксперимент не доказывает небезопасность агентных систем в целом, но показывает конкретный механизм: если несколько действий расходуют один общий мандат, ALLOW должно быть связано с атомарным изменением состояния до исполнения. Иначе три локально допустимых решения легко превращаются в результат, которого человек не разрешал.