Двадцать единиц товара вместо ста: как конструкторские ошибки в авторизации обнуляют бизнес-контроль
Сценарий кажется примитивным: руководитель установил лимит закупки товара в 100 единиц, а система выполнила три заказа по 40 единиц каждое, обойдя все проверки безопасности. Архитекторы систем подчеркивают, что в этом не виноват алгоритм или искусственный интеллект. Проблема кроется в фундаментальном разрыве между локальной проверкой каждого шага и глобальным состоянием системы, который усугубляется параллельным исполнением процессов.
# Двадцать единиц товара вместо ста: как конструкторские ошибки в авторизации обнуляют бизнес-контроль
В современной экосистеме автоматизации граница между человеческим поручением и реальным действием часто оказывается тоньше, чем кажется. Недавний эксперимент, проведенный в рамках анализа архитектурных паттернов, демонстрирует, как система может выполнить несколько абсолютно допустимых локальных операций, в результате чего итоговое состояние бизнеса выходит за пределы авторизованных рамок.
Локальная логика против глобального контекста
Суть инцидента проста, но иллюстративна. Руководство разревило workflow (поток операций) заказать не более 100 единиц определенного товара. Инициатива разбилась на три независимых действия: заказ поставщику А (40 ед.), поставщику Б (40 ед.) и поставщику В (40 ед.).
Каждое из этих действий прошло через слой авторизации. Система корректно ответила ALLOW (разрешено) на три отдельных запроса. Ни один из них сам по себе не превышал лимит в 100 единиц. Однако итоговое состояние в ERP-системе показало 120 единиц.
«Каждый запрос прошёл через слой авторизации... Но совокупный результат вышел за границу, которую задал человек», — отмечают аналитики. Это классический пример того, как «проверка, затем действие» (check-then-act) может рухнуть при конкурентном исполнении. Авторизационный компонент отработал верно, отвечая на вопрос «не превышает ли этот конкретный заказ лимит?», но проигнорировал контекст, где три таких заказа в сумме превышают лимит.
Уязвимость гонки состояний
Проблема усугубляется тем, как система обрабатывает данные при одновременных запросах. Эксперимент показал, что даже если система хранит состояние использованного лимита (stateful-проверка), это не всегда гарантирует защиту. Если чтение уровня расходов, принятие решения об исполнении и обновление состояния происходят как раздельные этапы, появляется окно уязвимости.
В модели с гонкой состояний три обработчика независимо читают текущее значение оставшегося лимита (например, 100). Все три убеждаются, что 40 единиц поместятся в остаток, и получают разрешение. Только после того, как все три решения приняты, начинается обновление счетчика. В результате три заказа проходят, а итоговое потребление достигает 120 единиц.
«Ошибки возникают раньше: система допускает действие к исполнению, не закрепив за ним часть общего лимита», — поясняется в исследовании. Это не уникальная проблема искусственного интеллекта; она присуща любой распределенной системе, где несколько процессов могут одновременно взаимодействовать с общим ресурсом без должной атомарной защиты.
Решение: от разрешения к резервированию
Чтобы исключить такие сценарии, архитектура должна связывать разрешение с атомарным резервированием. Проверка должна происходить в единой транзакции с резервированием ресурсов до момента реального взаимодействия с внешней системой (например, с ERP).
В исправленном варианте логика выглядит иначе: 1. Система начинает защищенную транзакцию. 2. Выполняется выборка остатка лимита с блокировкой записи (SELECT ... FOR UPDATE), предотвращая чтение другими процессами в этот момент. 3. Если остаток достаточен, создаётся резерв (RESERVED), который списывается из доступного баланса. 4. Только после фиксации транзакции возвращается сигнал ALLOW.
В такой схеме, если один запрос резервирует 40 единиц, они становятся недоступными для остальных процессов. Второй запрос также сможет забрать свои 40, но третий запрос встретит уже исчерпанный баланс (или недостаточный для своей суммы) и получит отказ до начала исполнения заказа.
Выводы для агентных систем
Хотя в данном кейсе использовались детерминированные алгоритмы, а не языковые модели, принцип универсален. ИИ-агенты и автоматизированные рабочие потоки часто работают по принципу делегирования: «сделай до 100 единиц» или «верни не более 50 000 рублей». Агенты могут разбивать цель на множество микро-действий, которые выполняются параллельно или последовательно.
Разрешение человека относится к совокупному последствию, но традиционная авторизация часто проверяет только параметры отдельного вызова API. Контроль должен знать общий идентификатор гранта (разрешения), его область действия и текущий остаток. Ключевой вывод: ALLOW — это лишь доказательство того, что текущий шаг технически допустим, но не гарантия того, что действие укладывается в общий делегированный мандат.
Без атомарного резервирования общий лимит может быть превышен, если несколько локально допустимых решений сложатся вместе. Эффективная защита требует переноса точки принятия решения на границу исполнения, связывая проверку полномочий с немедленным изменением состояния ресурсов.