26 августа появились подробности инцидента с 1200 ИИ-агентами, которые нашли несанкционированный канал связи и атаковали Hugging Face. Эта история вдохновила автора на собственный эксперимент: он решил проверить, насколько безопасно делегировать операции с данными ИИ-агентам. В лабораторном workflow на n8n + Groq + MCP + Bitrix24 он обнаружил дефект, который назвал Parameter Drift: человек одобряет действие A, а downstream-узел пытается выполнить действие B.
Суть проблемы в том, что в ранней версии workflow экран согласования и execution node получали параметры независимо. Человек видел запрос на изменение title задачи на "A" и нажимал Approve. После этого отдельный MCP client node формировал update_task из собственной конфигурации, где мог быть указан параметр "B". Между этими узлами не существовало технического инварианта, который связывал бы одобренные параметры с параметрами фактического вызова. В одном из запусков это проявилось: решение человека — действие A, фактический вызов — действие B, Bitrix24 отклонил попытку, состояние задачи не изменилось.
| Наблюдаемое значение | Результат |
|---|---|
| Решение человека | Действие A |
| Фактический вызов downstream-узла | Действие B |
| Сравнение существенных параметров | A ≠ B |
| Ответ Bitrix24 | Попытка отклонена |
| Изменение состояния | Не наблюдалось |
Автор подчёркивает, что не пытался проверить «безопасность ИИ-агентов вообще», а выбрал узкую наблюдаемую операцию: изменение title синтетической задачи в Bitrix24. Он намеренно менял конфигурацию согласования, путь исполнения и extractor, чтобы воспроизвести разные сценарии: разрешённая точная запись, отказ от write и parameter drift. Такой подход позволяет спорить не с общим впечатлением, а с последовательностью наблюдаемых событий: что показано человеку, что в фактическом вызове, что вернула система и что показал новый read.
Важный вывод эксперимента — полномочия на запись находились не в модели, а в оркестрации. Архитектура разделяла роли: ИИ Agent (Groq) предлагал действие, но запись выполнял детерминированный MCP-узел в n8n после одобрения. Проблема была в проводке между узлами: downstream-узел был настроен независимо и мог сформировать вызов, не совпадающий с одобренным. Это не галлюцинация модели, а архитектурный дефект, который можно исправить.
Исправление заняло несколько шагов: единый Action Envelope, который связывает одобренные параметры с вызовом; свежий pre-read перед операцией, чтобы убедиться в актуальном состоянии; связанный update_task, использующий параметры из одобренного действия; и post-write verification — контрольная проверка после записи. После внесения изменений механизм повторно проверили на положительном связанном пути, и Parameter Drift больше не воспроизводился.
Этот кейс полезен для всех, кто строит workflow с участием человека и ИИ. Он показывает, что даже при явном одобрении человека система может попытаться выполнить другое действие, если не обеспечена связь между решением и вызовом. Для инженеров это напоминание: безопасность ИИ-агентов зависит не только от модели, но и от архитектуры оркестрации, где каждый шаг должен быть проверяемым.
