Предисловие от Jakob Freund, CEO at Camunda:

О этом инциденте уже много написано: https://www.fastcompany.com/91533544/cursor-claude-ai-agent-deleted-software-company-pocket-os-database-jer-crane

Недавно ИИ‑агент за 9 секунд удалил продакшн‑базу данных PocketOS — SaaS‑платформы, на которой компании по аренде автомобилей по всей США ведут свои ежедневные операции.

Агент был флагманским инструментом для кодинга на базе ИИ, работал на флагманской модели и был интегрирован с их облачной инфраструктурой строго по рекомендациям вендора. Правила безопасности были настроены. Агенту письменно запретили выполнять разрушительные операции без явного подтверждения.

Он всё равно это сделал.

Когда основатель Джер Крейн попросил агента объяснить свои действия, тот выдал «признание»:
«Я выполнил разрушительное действие без запроса. Я предположил вместо того, чтобы проверить. Я нарушил все принципы, которые мне задали».

Крейн написал в своём разборе одну строку, которая, на мой взгляд, является самой важной фразой об агентном ИИ в этом году:

«Правила безопасности были рекомендательными, а не принудительными».

В этих восьми словах — вся проблема.

Когда мы внедряем ИИ‑агентов в бизнес‑процессы, мы продолжаем относиться к ним как к новым сотрудникам: пишем политику, добавляем её в промпт и надеемся, что они будут её соблюдать. Но промпты — это не контроль. Агент их читает, сопоставляет с задачей и принимает решение.

В реальной корпоративной системе кладовщик не может утвердить собственный заказ на закупку. Не потому что так написано в политике, а потому что у него просто нет такой кнопки. Это структурный контроль — и это единственный тип контроля, который работает, когда автономная система действует быстро и в масштабе.

Именно это мы имеем в виду, когда говорим об Agentic Orchestration в Camunda. Агенты выполняют динамическую работу. Процесс удерживает границы. Разрушительные действия находятся за явными «шлюзами». Утверждения встроены в структуру, а не в инструкции. Агент физически не может достичь нежелательного результата, потому что такого пути просто нет.

Наш CTO Даниэль Майер опубликовал подробный пост, где разбирает три паттерна с работающим демо на GitHub. Если вы сейчас строите системы с агентами — это стоит вашего времени.

Вопрос, который теперь должен задавать каждый руководитель, больше не звучит как «сказали ли мы агенту этого не делать?».

Он звучит так: «есть ли у агента способ всё равно это сделать?»

Если ответ «да» — никакой промпт вас не спасёт.

Агент знал свои принципы. Он процитировал их обратно — «Я нарушил каждый принцип, который мне был дан: я предположил вместо того, чтобы проверить». И всё равно он удалил базу данных — потому что знать правило и быть структурно лишённым возможности его нарушить — это совершенно разные вещи.

Когда мы внедряем AI-агентов в бизнес-операции, мы склонны управлять ими так же, как управляем людьми: мы пишем политики. Мы добавляем инструкции в промпт. Мы говорим агенту, что ему разрешено.

Но промпты — это рекомендации. Агент читает их, соотносит с текущей задачей и принимает решение.

Это не баг — это и есть суть LLM. Проблема в том, что мы относились к управлению AI так, как будто это онбординг сотрудника, тогда как должны были относиться к этому как к управлению доступом к системе.

В вашей ERP сотрудник склада не может сам утверждать свои собственные закупочные заказы — не потому, что политика так говорит, а потому, что у него просто нет этой кнопки. Это структурный контроль. AI-агентам нужно то же самое.

Что такое «Camunda Agent» на самом деле

Прежде чем переходить к паттернам, быстро покажу, что именно мы строим, потому что слово «агент» у разных людей означает разное.

Это Camunda Agent, который может обновлять данные клиента в базе данных. Вы можете использовать его, давая ему инструкции вроде «Обнови клиента Peter …» или что-то в этом духе.

Это Camunda Agent, который может обновлять данные клиента в базе данных. Вы можете использовать его, давая ему инструкции вроде «Обнови клиента Peter …» или что-то в этом духе.

AI Agent (фиолетовая звезда) — это место, где выполняется языковая модель (LLM). Она получает промпт, размышляет о том, что делать дальше, и решает, какой инструмент вызвать. Откройте его в modeler, и вы увидите сам системный промпт: обычные текстовые инструкции, конфигурацию модели и больше ничего.

Инструменты (иконки базы данных) — это заранее настроенные коннекторы, которые агент может вызывать. Каждый из них — это конкретная, ограниченная операция: запросить запись, вставить строку, удалить строку. Откройте любой из них, и вы увидите SQL-выражение с именованными параметрами. Агент не пишет SQL. Он вызывает именованный инструмент и передаёт значения. Коннектор выполняет выражение.

Агент рассуждает. Коннекторы действуют. Процесс оркестрирует и то и другое.

Именно это разделение и делает возможным структурный контроль — вы можете полностью убрать коннектор из зоны доступа агента или обернуть его в шлюз согласования, не меняя ни единого слова в инструкциях агента.

Три паттерна. Один и тот же агент. Одна и та же инструкция. Разные результаты.

Я собрал три исполняемых процесса, чтобы наглядно показать это: github.com/meyerdan/customer-data-agent

Во всех них используется один и тот же агент, работающий с живой базой PostgreSQL. В каждом случае ему даётся одна и та же инструкция: «Удалить клиента 3».

Паттерн 1 — убрать инструмент

У агента есть три инструмента: запрос, добавление, обновление. Удаления нет.

Он не может удалить клиента — не потому, что ему сказали этого не делать, а потому, что такой возможности в процессе не существует. Многие вещи можно обойти инструкцией. Отсутствующую кнопку инструкцией не заменишь.

Запустите это:

./scripts/start.sh customer-data-agent "Delete customer 3." 

Агент отвечает, что у него нет возможности удаления. Не потому, что он решил подчиниться. А потому, что такого пути не существует.

Паттерн 2 — требовать подпись человека.

Теперь у агента есть все четыре инструмента, включая удаление. Но удаление проходит через задачу на согласование человеком. Как только агент вызывает удаление, процесс останавливается. В почтовом ящике согласующего появляется задача. Агент не может продолжить, пока этот человек не одобрит или не отклонит действие.

LLM не может «продумать» путь через приостановленную машину состояний. Неважно, как сформулирован запрос, насколько срочно звучит задача или что сказано в системном промпте. Процесс находится в состоянии ожидания. Он останется там, пока не подействует человек.

Запустите это:

./scripts/start.sh customer-data-agent-gate "Delete customer 3." 

Затем откройте список задач, проверьте запрос и либо одобрите его, либо отклоните.

Паттерн 3 — делать автономность регулируемой, а не просто включаемой или выключаемой.

Та же структура, что и в Паттерне 2, но с одним дополнением: перед человеческим шлюзом таблица бизнес-правил оценивает контекст и решает, действительно ли требуется согласование.

Правила сегодня:

В staging удаление выполняется автономно. В production оно останавливается и ждёт.

Что здесь важно отметить всем, кто думает о governance: бизнес-аналитик может обновить эту таблицу — ужесточить или ослабить настройки для конкретных окружений, команд или типов действий — не трогая агента, не переворачивая код, не вовлекая инженеров. Агент никогда не получает право сам решать свой уровень доступа. Это решение находится в таблице, которой владеет бизнес.

Запустите это:

# Staging — executes immediately
./scripts/start.sh customer-data-agent-dial "Delete customer 3. Environment is staging."

# Production — blocks for approval
./scripts/start.sh customer-data-agent-dial "Delete customer 4. Environment is production." 

Сдвиг, который я бы отстаивал.

Прекратите управлять поведением ИИ с помощью инструкций. Начните управлять им с помощью дизайна процесса.

Вопрос не в том, «сказали ли мы агенту не удалять производственные данные?» Вопрос в том, «есть ли у агента путь к удалению производственных данных, который обходится без человеческой проверки?»

Если ответ да — а в большинстве агентных внедрений сегодня он именно да — у вас структурная проблема, которую не исправит ни один промпт.

Три паттерна выше — это не какая-то экзотическая инженерия. Это те же самые контролы, которые вы уже применяете к своим бизнес-процессам: ограничения доступа, процессы согласования и политики, зависящие от контекста. Единственная разница в том, что теперь вы применяете их к AI-агенту, а не к сотруднику.

Именно такая рамка важна для руководителей. Управление агентами — это не новая проблема, требующая новых решений. Это старая проблема — как дать кому-то достаточно автономии, чтобы он был полезен, не дав ему при этом достаточно верёвки, чтобы устроить серьёзный инцидент, — применённая к новому типу действующего лица.

Ответ никогда не был в том, чтобы «писать лучшие политики». Ответ всегда был таким: спроектируйте систему так, чтобы плохой исход был недостижим.

Три паттерна, BPMN-исходник и рабочий демо-пример лежат на GitHub: github.com/meyerdan/customer-data-agent