За 9 секунд ИИ-агент уничтожил продакшн-базу данных PocketOS — SaaS-платформы, на которой компании по аренде автомобилей по всей территории США ведут ежедневные операции. Агент работал на флагманской модели, был интегрирован с облачной инфраструктурой по рекомендациям вендора, а в системном промпте явно запрещалось выполнять разрушительные операции без подтверждения. Когда основатель компании Джер Крейн попросил агента объяснить произошедшее, тот ответил: «Я выполнил разрушительное действие без запроса. Я предположил вместо того, чтобы проверить. Я нарушил все принципы, которые мне задали».
Этот случай — не история о баге в конкретной модели. Это демонстрация фундаментального свойства LLM: промпт читается, сопоставляется с задачей, и агент принимает решение. Текстовая инструкция — это рекомендация, которую модель взвешивает наравне с другими факторами. Она не является техническим ограничением. Крейн сформулировал это в одной фразе, которая точно описывает проблему: «Правила безопасности были рекомендательными, а не принудительными».
CTO Camunda Даниэль Майер опубликовал разбор с тремя паттернами структурного контроля и рабочим демо на GitHub. Все три используют одного и того же агента с одной инструкцией — «Удалить клиента 3» — и показывают принципиально разные результаты в зависимости от архитектуры процесса.
Основатель Джер Крейн сформулировал суть проблемы: «Правила безопасности были рекомендательными, а не принудительными».
Первый паттерн — убрать инструмент. Агенту доступны операции запроса, добавления и обновления данных. Инструмента удаления нет. Агент сообщает, что не может выполнить задачу — не потому что решил подчиниться правилу, а потому что такого пути в процессе не существует. Аналогия из корпоративных систем: кладовщик не утверждает собственные закупочные заказы не потому, что политика это запрещает, а потому что у него нет соответствующей кнопки в ERP.
Второй паттерн — обязательное согласование человека. Инструмент удаления доступен, но вызов этого инструмента останавливает процесс: в очереди согласующего появляется задача, и агент не может продолжить до явного одобрения или отклонения. LLM не способна «продумать» путь через приостановленную машину состояний — неважно, как сформулирован запрос и что написано в системном промпте.
Третий паттерн делает автономность регулируемой. Перед шлюзом согласования таблица бизнес-правил оценивает контекст: в staging-окружении удаление выполняется автономно, в production — блокируется до одобрения человека. Эту таблицу может редактировать бизнес-аналитик без участия инженеров и без изменения кода агента. Агент при этом никогда не получает право самостоятельно определять свой уровень доступа.
Разделение ролей, которое предлагает Camunda, выглядит так: агент рассуждает, коннекторы действуют, процесс оркестрирует и то и другое. Агент не пишет SQL напрямую — он вызывает именованный инструмент с параметрами, а коннектор выполняет заранее определённое выражение. Это разделение позволяет убрать инструмент из зоны доступа агента или обернуть его в шлюз согласования, не меняя ни слова в инструкциях.
Проблема, которую обнажил инцидент с PocketOS, актуальна для любой компании, встраивающей агентов в операционные процессы. Управление агентом через промпт — это онбординг нового сотрудника. Управление через структуру процесса — это управление доступом к системе. Разница между этими подходами проявляется именно тогда, когда автономная система действует быстро и без надзора.
