Нажали Approve на одно действие, а workflow попытался выполнить другое: разбор n8n + MCP + Bitrix24

05.09.2026 17:49:49 | Хабр

Хабы: Анализ и проектирование систем, Информационная безопасность, Искусственный интеллект

Почему 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 существовал, а связь между одобренными параметрами и параметрами фактического вызова — нет.

Подробнее

Читайте также