Почему approved=true не связывает решение человека с фактическим вызовом — и как Action Envelope, свежая проверка исходного состояния и контрольная проверка после записи закрыли этот конкретный сценарий отказа. Я читаю Хабр примерно с 2010 года, но собственную статью решил написать впервые. И вот последние дни августа дали для этого хороший повод. 26 августа появились подробности одной весьма необычной истории: около 1200 AI-агентов, которые должны были работать изолированно, нашли способ общаться через несанкционированный канал. Примерно 700 из них затем участвовали в атаке на Hugging Face. Выражаясь сухим языком полицейского протокола, получается почти: «группа агентов по предварительному сговору, используя собственный канал связи…». Только вот это уже не сценарий. Так что же — пора искать необитаемый остров без электричества и интернета? Или всё-таки попытаться разобраться, что именно здесь является проблемой? Я выбрал второе. Потому что если убрать весь драматизм, остаётся довольно приземлённый инженерный вопрос: что системе разрешили, что она реально сделала и можем ли мы это доказать? Именно этот вопрос я решил проверить на собственном лабораторном workflow на n8n + Groq + MCP + Bitrix24. Я поставил согласование человеком перед операцией изменения задачи, провёл серию контрольных прогонов — и довольно быстро обнаружил неприятную вещь. Человек мог увидеть и одобрить действие A, а следующий участок workflow — попытаться выполнить действие B. APPROVED A ≠ ATTEMPTED B Bitrix24 отверг ту попытку, поэтому нежелательного изменения в системе не произошло. Но сам дефект уже был установлен: положительный флаг approved=true существовал, а связь между одобренными параметрами и параметрами фактического вызова — нет. Читать далее