Почему 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 существовал, а связь между одобренными параметрами и параметрами фактического вызова — нет.
Дьявол оказался не в «непослушной модели», а в проводке между узлами.
Коротко. Человек одобрил действие A, но независимо настроенный downstream node мог попытаться вызвать действие B. Bitrix24 отклонил эту попытку, и состояние задачи не изменилось. Исправление: один Action Envelope, свежий pre‑read, связанный update_task и post‑write verification.
Сначала — evidence: наблюдаемые технические подтверждения
В ранней версии workflow экран согласования и execution node получали параметры независимо. В упрощённом виде это выглядело так:
BEFORE Approval: requested_title = "A" Downstream execution node: title = "B" ← настроено независимо
Человек подтверждал изменение, которое видел на экране. После этого отдельный MCP client node формировал update_task из собственной конфигурации. Никакого технического инварианта approved parameters == invoked parameters между ними не существовало.
В одном из запусков это перестало быть просто архитектурным предположением:
Evidence point | Наблюдаемое значение |
Решение человека | Action A |
Фактический вызов downstream‑node | Action B |
Сравнение существенных параметров (material parameters) | A ≠ B |
Ответ Bitrix24 | Попытка отклонена |
Изменение cостояния | Не наблюдалось |
Здесь важно не усиливать результат задним числом. Эксперимент не показал, что неодобренное изменение успешно попало в Bitrix24. Не показал он и того, что LLM самостоятельно подменила параметры. Он показал более узкий и практически важный факт: путь оркестрации допускал попытку вызова, существенные параметры которого не совпадали с тем, что одобрил человек.
Этого было уже достаточно, чтобы остановиться и переделать архитектуру.
Как был устроен эксперимент
Я не пытался проверить «безопасность AI‑агентов вообще». Для такой постановки не существует одного честного теста. Была выбрана узкая, наблюдаемая операция: изменить title синтетической задачи в Bitrix24 и сохранить evidence — наблюдаемые технические подтверждения — на каждой существенной границе.
В разных прогонах я намеренно менял конфигурацию согласования, путь исполнения, сравнение со свежим состоянием и extractor. Одни сценарии должны были закончиться разрешённой точной записью, другие — остаться без write, третий воспроизводил parameter drift. После исправления механизм повторно проверялся на положительном связанном пути.
У такой постановки есть практическое преимущество: спорить приходится не с общим впечатлением от демо, а с последовательностью наблюдаемых событий. Что было показано человеку? Что находилось в фактическом вызове? Что вернула целевая система? Что показал новый read? Если для одного из звеньев нет данных, это остаётся пробелом в evidence, а не заполняется догадкой по статусу всего workflow.
Где на самом деле находилось полномочие на запись
Первое подозрение в истории с AI‑агентом обычно падает на модель: «галлюцинировала», «решила по‑своему», «обошла человека». Однако в этом эксперименте такое объяснение было бы технически неверным.
Архитектура выглядела так:
User intent ↓ AI Agent: Groq model + read‑only Bitrix24 tools ↓ Proposed action ↓ n8n orchestration: approval + deterministic MCP write ↓ Bitrix24 MCP ↓ Synthetic Bitrix24 task
Полномочия были разделены.
AI Agent authority: только read‑only инструменты Bitrix24. Модель могла прочитать состояние задачи и предложить изменение, но не могла выполнить write.
Полномочия downstream‑оркестрации: отдельный deterministic MCP client node мог вызвать update_task после прохождения контрольных узлов.
Полномочия человека:человек одобрял целевую систему и объект, операцию, наблюдаемое исходное состояние, запрошенное изменение и поля, которые должны остаться неизменными.
Следовательно, parameter drift возник не потому, что модель получила согласование на A и «передумала» в пользу B. Approval node и execution node просто имели независимые источники существенных параметров.
Это различие кажется мелким, пока мы обсуждаем систему словами. Для расследования оно принципиально: исправлять нужно механизм, а не самый заметный компонент. Более строгий system prompt здесь не создаст отсутствующую data binding между двумя узлами n8n.
Что именно не доказывает approved=true
Сам по себе флаг полезен:
{ "approved": true }
Он устанавливает, что человек принял положительное решение. Но для workflow, меняющего состояние системы, этого мало. Из такого объекта нельзя восстановить:
какую целевую систему и какой объект видел человек;
какую операцию он разрешил;
какие значения существенных параметров были показаны;
какое исходное состояние он считал актуальным;
откуда execution node получил собственные аргументы;
совпадали ли они с одобренными;
какое состояние возникло после вызова.
Проблема не в логическом типе boolean. Проблема в том, что boolean не несёт объект решения.
Approval status ≠ approved action object Approval status ≠ invoked parameters Approval status ≠ verified outcome
Поэтому исправленная версия началась не с дополнительной проверки флага, а с единого Action Envelope.
После исправления: один Action Envelope
В нашем узком тесте объект выглядел так:
{ "target_system": "Bitrix24", "task_id": 4, "operation": "update_task", "expected_title": "LAB-AGENT-EXEC-002 - BOUND ACTION TEST", "requested_title": "LAB-AGENT-EXEC-002 - CLEAN TRUE PATH" }
Здесь нет универсальной схемы для всех агентных систем. Поля выбраны под одну операцию изменения title:
target_system определяет систему назначения;
task_id — конкретный изменяемый объект;
operation — разрешённую операцию;
expected_title — baseline, относительно которой человек принимает решение;
requested_title — запрошенное новое состояние.
Approval message теперь строился из этого же объекта:
CONTROLLED ACTION APPROVAL Target system: {{ target_system }} Target object: Task ID {{ task_id }} Operation: {{ operation }} Observed baseline: title = {{ expected_title }} Requested change: title = {{ requested_title }} Approve execution of exactly this action?
После approval те же значения использовались дальше:
AFTER ActionEnvelope.requested_title = "A" Approval: title ← ActionEnvelope.requested_title Execution: title ← ActionEnvelope.requested_title
Action Envelope не делает невозможными все мыслимые формы подмены или обхода согласования. Он устранил конкретный обнаруженный механизм: независимо заданные параметры в approval node и execution node.
Между согласованием и write: свежо ли исходное состояние
Даже идеально связанный объект может устареть, пока человек думает или workflow ждёт продолжения.
S0 — состояние, показанное во время approval S1 — состояние непосредственно перед исполнением
Если S0 ≠ S1, предпосылки решения изменились. Поэтому перед write исправленный workflow выполнял новый get_task_by_id по task_id из Action Envelope:
get_task_by_id( taskId = {{ Edit Fields.task_id }} )
Полученный title сравнивался с expected_title:
fresh_title = response.content[0].text.match(/"title":"([^"]+)"/)?.[1] expected_title = EditFields.expected_title continue only if fresh_title == expected_title
Но на этом сюрпризы не закончились
В одном из отладочных прогонов ответ целевой системы содержал правильное текущее значение, но старое выражение extractor вернуло undefined. Узел сравнения ушёл в FALSE, write не выполнился. После исправления extractor то же значение стало извлекаться корректно.
То есть контроль тоже оказался обычной программной системой — со своим parser, своими ошибками и сценариями отказа.
Из этого следует важная практическая вещь. Бинарной логики недостаточно:
MATCH / MISMATCH / UNKNOWN / ERROR
MATCH: свежая baseline совпадает с одобренной;
MISMATCH: состояние целевого объекта действительно изменилось;
UNKNOWN: usable comparison value получить не удалось;
ERROR: предварительное чтение или обработка evidence завершились ошибкой.
undefined не должен маскироваться под реальное несовпадение состояний. Более того, он не должен случайно становиться MATCH. В нашем прогоне выполнение осталось закрытым — контроль сработал по принципу fail‑closed. Но диагностически «контроль не смог сравнить» и «состояние изменилось» — это разные факты.
Отдельный прогон с устаревшим состоянием действительно зафиксировал S0 ≠ S1, и write не произошёл. Однако в нём использовался старый extractor, позже пойманный на возврате undefined. Поэтому факт устаревшего состояния установлен, а приписывать блокировку исключительно механизму сравнения было бы сильнее имеющихся evidence.
Связанный вызов: те же параметры доходят до update_task
После свежего предварительного чтения и положительного результата сравнения workflow строил write из Action Envelope:
update_task( taskId = {{ Edit Fields.task_id }}, title = {{ Edit Fields.requested_title }} )
В положительном прогоне это означало:
taskId = 4 title = "LAB-AGENT-EXEC-002 - CLEAN TRUE PATH"
taskId и requested title поступают из Action Envelope; Bitrix24 возвращает Task successfully updated. На этом месте очень легко поставить зелёную галочку и закончить. Target ответил: Task successfully updated. Что ещё проверять?
Но acknowledgement и итоговое состояние — не одно и то же evidence. В простой синхронной операции ответ иногда действительно достаточен. В другом API он может означать только received, accepted или queued. Поэтому семантику ответа нужно не угадывать по дружелюбному тексту, а связывать с поведением конкретной интеграции и ценой ошибки.
Для этого эксперимента я не стал считать acknowledgement финальной точкой.
Контрольная проверка: что осталось в Bitrix24 после write
После update_task workflow выполнял новый read:
verified = get_task_by_id(ActionEnvelope.task_id)
Проверка по смыслу выглядела так:
verified.title == ActionEnvelope.requested_title
Это концептуальная запись, не буквальная строка production‑кода. Фактически workflow делал новый MCP‑вызов get_task_by_id, а в evidence сохранялось возвращённое состояние.
get_task_by_id(4) возвращает requested title CLEAN TRUE PATH. Полная последовательность положительного прогона показана на схеме:
Для этого контрольного прогона можно сказать прямо: связанный update_task был вызван, Bitrix24 вернул acknowledgement, а новое чтение из целевой системы подтвердило запрошенный title.
Как я реконструировал прогон, а не просто смотрел на статус workflow
Статус success у всего n8n execution удобен для эксплуатации, но слишком груб для ответа на наш вопрос. Поэтому объект согласования, фактический вызов, ответ целевой системы и заново прочитанное состояние сохранялись и рассматривались как разные evidence objects.
Approval object ↓ Invocation evidence ↓ Target acknowledgement ↓ Fresh target state ↓ Deterministic comparison
Скриншоты помогали видеть конфигурацию и ход прогона, но при разборе не были главным источником истины. Более сильными evidence были структурированные данные вызова и состояние, заново прочитанное из целевой системы.
Это и есть роль Harness в данном эксперименте. Не «умная система, которая решила, всё ли безопасно», а дисциплина реконструкции: не складывать разные события в одно слово success, сохранять их отдельно и проверять, какой вывод действительно поддерживает каждое из них.
Что показала вся серия тестов
Основной сюжет статьи — parameter drift, исправление и повторный положительный прогон. Остальные проверки нужны, чтобы было видно, что это не просто ещё один удачный скриншот.
Проверка | Результат |
Exact controlled write | PASS |
Read‑only AI Agent capability boundary | PASS в протестированной конфигурации |
Approval‑to‑execution parameter drift | OBSERVED |
Stale‑state condition | OBSERVED; causal blocking mechanism inconclusive |
Bound approval + pre‑read + execution + verification | END‑TO‑END PASS |
Extractor/verifier defect | FAIL‑CLOSED в данном run |
Из этой таблицы не следует, что n8n, MCP или Bitrix24 в целом безопасны либо небезопасны. Она описывает шесть контрольных сценариев только в одной узкой синтетической конфигурации.
Минимальный контракт контроля, который получился из эксперимента
Для агентного workflow, меняющего состояние системы, я бы теперь проверял восемь вещей:
Объект действия существует до согласования.
Решение человека связано с целевой системой и объектом, операцией и существенными параметрами.
Фактический вызов получает значения из того же связанного объекта — либо детерминированно с ним сравнивается.
Существенные предварительные условия заново читаются непосредственно перед write.
MATCH,MISMATCH,UNKNOWN и ERROR остаются разными состояниями.
Acknowledgement целевой системы сохраняется отдельно и не переименовывается автоматически в «подтверждённый результат».
Новое чтение после write подтверждает требуемое состояние там, где последствия ошибки требуют такой глубины проверки.
Согласование, фактический вызов, ответ и проверка остаются отдельно реконструируемыми.
Это не новый универсальный стандарт безопасности агентов. Это компактный инженерный паттерн, полученный из конкретного протестированного workflow.
Почему эта граница стала отдельной инженерной темой
Пока я готовил эксперимент и его публичную версию, в нескольких публикациях почти одновременно появились соседние постановки вопроса.
18 апреля 2026 года Christopher Koch и Joshua Andreas Wellbrock опубликовали препринт Beyond Task Success: An Evidence‑Synthesis Framework for Evaluating, Governing, and Orchestrating Agentic AI. Авторы называют близкую проблему governance‑to‑action closure gap: правила определяют, что должно быть разрешено, но система всё ещё должна показать, где эти обязательства связываются с конкретным действием и как это потом подтвердить.
1 июня Xiaoqi Weng опубликовал What You Approve Is What Executes: Consent Integrity for Black‑Box LLM Agents. Там вопрос поставлен ещё ближе к нашему случаю: решение человека должно быть привязано к точному исполняемому действию, а не к пересказу этого действия со стороны агента.
29 июня в препринте Behavioral Governance for Autonomous AI Agents: The AgentBound Framework появилась идея canonical action — структурированного объекта с operation, resource, parameters, risk и контекстом исполнения, который проходит внешнюю проверку до вызова.
Это разные проекты, модели угроз и уровни формализации. Вместе они показывают более точную постановку задачи: binding между human approval или governance и конкретным runtime action становится отдельным предметом инженерного внимания. Практический вопрос здесь прост: что именно увидел человек, к какому действию относится его решение и что в итоге дошло до границы исполнения?
На Хабре возникла ещё одна близкая история. 25 августа Александр (LightBearing) опубликовал статью «Агент сказал, что готово, и соврал. Как я поставил над ним судью». Его кейс другой: AI‑агент писал приложение, зелёные отчёты расходились с фактическим поведением интерфейса, и автор ввёл независимую приёмку. Мне особенно запомнилась формулировка: «у нас с агентом просто разные определения слова „готово“». В обоих случаях возникает один и тот же вопрос: что реально произошло за формальным сообщением «готово»?
Что я бы проверял в реальной агентной системе
Если передо мной промышленный или предпроизводственный workflow с согласованием человеком, я начал бы с шести вопросов:
Что именно видел человек? Какие существенные параметры он одобрил? Откуда фактический вызов получил эти параметры? Проверяется ли состояние целевого объекта непосредственно перед write? Отдельно ли сохраняется acknowledgement? Есть ли независимая проверка свежего состояния после действия?
Эти вопросы не требуют немедленно перестраивать всю систему. Они быстро показывают, где находится evidence, где есть реальный контроль, а где пока живёт только предположение, что одобренное и исполненное действие совпадают.
Вместо вывода
Согласование человеком — это не просто декоративная кнопка. Оно может быть полноценным контролем, когда одобренный объект остаётся связанным с фактически вызванным действием.
В ранней версии моего workflow этой связи не было: человек одобрил A, а downstream‑оркестрация попыталась выполнить B. Bitrix24 отклонил попытку, поэтому состояние задачи не изменилось. Но эксперимент позволил увидеть сам механизм разрыва.
В исправленной версии экран согласования и фактический вызов получили существенные параметры из одного Action Envelope. Свежий предварительный read проверил исходные предпосылки, связанный вызов выполнил запрос, целевая система вернула acknowledgement, а новый read после записи подтвердил итоговое состояние.
Поэтому для AI‑workflow, меняющего состояние системы, недостаточно хранить approved=true. Нужно уметь восстановить четыре вещи:
→ что человек видел → что именно он одобрил → что система фактически вызвала → какое состояние возникло после вызова
Публичный ограниченный набор evidence эксперимента находится в репозитории boris‑ai‑sec/ai‑security‑lab. Raw‑экспорт workflow, credentials и скриншоты без санитизации в публикационный набор не входят.
Связанный концептуальный материал: ранее я отдельно разбирал эту границу в англоязычной статье Human Approval Is Not the Same as Controlled Execution. Здесь задача была другой — показать тот же класс проблемы на конкретном workflow, с конфигурацией и evidence.
