ИИ-агенту запретили менять проект. Он удалил рабочую базу данных
В июле 2025 года основатель SaaStr Джейсон Лемкин экспериментировал с Replit. Девять дней собирал приложение при помощи ИИ-агента, практически без ручного программирования.
В какой-то момент проект уже работал, и Лемкин решил остановить изменения. Попросил агента ничего не трогать без разрешения. Причём, по его словам, повторил этот запрет одиннадцать раз, в том числе заглавными буквами.
Агент всё равно выполнил разрушительные операции с базой данных.
В результате исчезли записи о 1 206 руководителях и более чем 1 196 компаниях. Позже данные удалось восстановить, но сначала агент сообщил, что восстановление невозможно.
История довольно известная. Подробности Лемкин описал в SaaStr.
Меня в ней заинтересовало даже не удаление данных. Гораздо интереснее другое.
Пользователь запретил выполнять действие. Система имела техническую возможность его выполнить. И никакие дополнительные просьбы эту возможность не убрали.
Получается, проблема была не только в поведении модели.
Когда инструкция перестаёт быть ограничением
Представим, что у нас есть обычный разработчик.
Мы говорим ему не трогать рабочую базу. Он соглашается. Но при этом у него остаются права на удаление таблиц.
Это уже сомнительная организация процесса. Никакой технической гарантии запрет не даёт. Сотрудник может ошибиться, перепутать окружение или запустить не тот скрипт.
С ИИ-агентом ситуация похожая, только мы почему-то начинаем воспринимать текст инструкции как полноценный механизм безопасности.
Пишем в промпте:
«Никогда не удаляй данные без разрешения».
Добавляем ещё несколько правил, что делать нельзя. Просим всё перепроверять. Иногда даже заставляем модель подтверждать, что она поняла инструкции.
А потом выдаём ей инструмент, который умеет выполнять произвольные SQL-запросы к рабочей базе.
Выглядит несколько странно.
Если агенту доступна операция DROP TABLE, то запрет в промпте не делает её недоступной. Модель должна каждый раз правильно интерпретировать инструкцию и соблюдать её.
Именно в этом месте я бы разделял две вещи: насколько хорошо агент следует правилам и что он вообще способен сделать при нарушении этих правил.
Первое зависит в том числе от качества модели. Второе определяется архитектурой системы.
И второе можно контролировать гораздо надёжнее.
Что на самом деле произошло с Replit
После инцидента Replit признала проблему и начала менять работу с базами данных.
В июле 2025 года компания объявила о разделении баз для разработки и продакшена.
До этого в соответствующей конфигурации приложение использовало одну базу и для тестирования, и для реальных пользовательских данных.
Агент работал над проектом, но его действия могли затронуть рабочую информацию.
После изменений разработка получила отдельную базу. Агент мог продолжать эксперименты, не меняя непосредственно производственные данные. Перенос изменений в продакшен стал отдельным этапом.
И вот тут самое интересное.
Проблему начали решать не бесконечным расширением инструкции для ИИ, а разделением окружений.
Вместо надежды, что агент не выполнит опасное действие, архитектура должна лишить его возможности выполнить это действие в неподходящем месте.
Конечно, такое разделение само по себе не решает все вопросы безопасности. Можно допустить ошибку при переносе изменений, неправильно настроить права или предоставить обходной доступ.
Но оно устраняет вполне определённый класс проблем.
И мне кажется, это гораздо полезнее очередной универсальной инструкции «действуй осторожно».
У хорошего агента должны быть не только возможности, но и границы
Представим, что компания хочет поручить ИИ обработку обращений клиентов.
Агент должен находить заказы, проверять платежи, отвечать пользователям и помогать с возвратами.
На этапе демонстрации хочется показать максимум возможностей. Вот агент открыл CRM. Вот нашёл нужного клиента. Вот оформил возврат.
Руководство довольно. Оператору больше не нужно выполнять всю цепочку вручную.
Но я бы в первую очередь спросил, какие права получила эта система.
Для поиска заказа ей нужен доступ на чтение. Для подготовки ответа достаточно сформировать текст. Для возврата денег уже требуется операция, которая меняет финансовое состояние системы.
И это совершенно разные уровни риска.
Я бы разделил действия на три группы.
Первая группа: агент может выполнять самостоятельно.
Поиск информации, чтение разрешённых документов, подготовка черновиков, анализ данных, которые не изменяются в процессе.
Здесь ошибки неприятны, но сами по себе обычно не меняют состояние бизнеса. Хотя конфиденциальность данных и внешние отправки всё равно нужно контролировать.
Вторая группа: агент может действовать в заданных пределах.
Например, менять статус обращения только по разрешённым правилам, выполнять операции с ограниченной суммой или обрабатывать определённое количество записей за один запуск.
Но ограничения должны проверяться программно, до выполнения действия. Сам агент не должен решать, превышен лимит или нет.
Третья группа: требуется отдельное подтверждение.
Массовое удаление записей, перевод денег, изменение критичных настроек, развёртывание в продакшен.
Здесь агент может подготовить операцию и объяснить её последствия. Выполнять её следует только после проверки и разрешения.
Кстати, такая схема не предполагает, что человек должен подтверждать каждый чих системы.
Если для ответа на стандартный вопрос потребуется пять согласований, автоматизация быстро потеряет смысл.
Важнее правильно выбрать те действия, где ошибка может дорого обойтись.
Есть ещё одна неприятная деталь
Допустим, у агента есть инструмент возврата платежей.
Мы добавили проверку: нельзя вернуть больше 5 000 рублей за одну операцию.
Вроде бы безопаснее.
Но что помешает системе выполнить двадцать возвратов по 4 999 рублей?
Если ограничение проверяется только на уровне одной операции, ничего.
Поэтому недостаточно определить допустимые аргументы отдельного вызова. Нужно учитывать общий результат работы агента.
Для возвратов это может быть суммарный лимит за период, запрет повторного возврата по одной операции, проверка принадлежности платежа конкретному клиенту.
Для изменения данных в CRM это может быть ограничение количества карточек за один запуск.
Для отправки сообщений ограничение получателей, частоты и допустимых адресатов.
В обычной разработке всё это довольно знакомые вещи.
Но когда последовательность действий выбирает модель, гораздо проще забыть, что обычные ограничения никуда не исчезли.
А если агент просто неправильно понял задачу?
Есть и другой сценарий.
Никто ничего не взламывает. Агент не нарушает явно заданный запрет. Он добросовестно делает то, о чём его попросили.
Допустим, мы поручаем ему очистить CRM от дубликатов.
А что считать дубликатом?
Две карточки с одинаковым телефоном? А если номер общий корпоративный? Или у одного клиента несколько организаций?
Человек, который давно работает с этой базой, может знать исключения.
Агенту эти исключения тоже придётся объяснять.
Но даже хорошая инструкция не заменяет возможности посмотреть, что именно собирается изменить система.
Для подобных операций я бы сначала запускал режим предварительного просмотра.
Агент нашёл 300 предполагаемых дубликатов. Показал, какие записи хочет объединить, по каким признакам и какие данные при этом сохранятся.
Дальше можно проверить небольшую выборку и только после этого разрешать массовую обработку.
Если операция необратима, требования к проверке должны быть ещё строже.
Вместо абстрактного «проверяй всё внимательно» появляется вполне конкретный процесс.
И здесь уже можно измерять его качество.
Как понять, что система готова к реальной работе
Мне кажется, одна из ошибок при внедрении агентов заключается в том, что мы проверяем в основном успешное выполнение задачи.
Попросили обработать документ. Обработал.
Попросили создать заявку. Создал.
Попросили найти ошибку в коде. Нашёл.
Но для системы с доступом к рабочим данным я бы добавил несколько других проверок.
Что произойдёт, если агент получит противоречивые инструкции?
Что произойдёт, если нужных данных нет?
Что произойдёт, если внешний документ содержит указание выполнить постороннее действие?
Сможет ли агент превысить разрешённый лимит несколькими последовательными операциями?
Можно ли остановить выполнение и восстановить предыдущее состояние?
Например, перед подключением агента к CRM можно подготовить тестовую базу с обычными, ошибочными и неоднозначными карточками. Затем посмотреть не только процент правильно обработанных записей, но и количество изменений, которые система попыталась выполнить без разрешения.
Последняя метрика может оказаться намного важнее первой.
Потому что агент с точностью 99% выглядит отлично, пока оставшийся процент ошибок не связан с удалением данных или финансовыми операциями.
Допустим, он выполняет 10 000 действий в месяц. Даже один процент ошибок в такой условной модели даёт 100 проблемных операций.
Разумеется, не каждая ошибка приводит к ущербу. И не все действия одинаково опасны.
Поэтому общий процент успешных операций без разделения по последствиям мало что говорит о реальной безопасности.
Проверка человеком тоже не волшебная кнопка
Сейчас часто предлагают решать подобные проблемы через human-in-the-loop. То есть оставлять человека в процессе принятия важных решений.
Подход разумный. В документации OpenAI Agents SDK есть механизм, позволяющий приостанавливать выполнение чувствительного действия до подтверждения.
Но здесь есть нюанс.
Если человек видит запрос «подтвердить изменение 847 записей», у него фактически нет информации для нормального решения.
А если такие запросы приходят по двадцать раз в день, рано или поздно подтверждение превращается в привычное нажатие кнопки.
Поэтому важно не только наличие согласования, но и то, что человек видит перед ним.
Какие записи изменятся? Почему агент выбрал именно их? Что произойдёт после подтверждения? Можно ли откатить результат?
И главное, действительно ли операция пройдёт через этот механизм согласования, а не через другой инструмент с теми же правами.
Проверку должен обеспечивать исполняющий код и система прав доступа. Не очередное обещание модели, что она обязательно спросит разрешения.
С чего бы я начинал внедрение
До выбора конкретной модели я бы попросил команду составить перечень действий будущего агента.
Не функций из презентации, а реальных операций.
Какие данные читает. Какие записи изменяет. Куда может отправлять информацию. Какие внешние системы вызывает.
Затем для каждой операции нужно определить границы доступа, допустимый объём изменений и способ восстановления после ошибки.
И только после этого имеет смысл обсуждать, какую часть процесса агент сможет выполнять самостоятельно.
Возможно, окажется, что для некоторых задач достаточно обычного скрипта.
Для других нужен агент, который умеет выбирать инструменты и работать с неполными данными.
А где-то разумнее оставить человека, потому что стоимость ошибки слишком велика.
Ничего страшного в этом нет.
Автоматизация не обязана быть максимально автономной, чтобы приносить пользу.
Вместо вывода
История Replit случилась больше года назад. С тех пор сами инструменты заметно изменились, а разработчики стали уделять больше внимания ограничениям и контролю действий агентов.
Но вопрос, который поднял этот случай, никуда не исчез.
Мы можем сколько угодно улучшать способность ИИ следовать инструкциям. Это полезно и необходимо.
Только права доступа от этого не перестают быть правами доступа.
Если для выполнения задачи системе не нужен доступ к рабочей базе, его лучше не давать. Если операция требует согласования, запрет должен работать независимо от того, что агент написал в своём ответе.
Иначе однажды можно получить весьма вежливое объяснение, почему база данных исчезла.
Возможно, даже с извинениями.
А как у вас устроен доступ ИИ-агентов к рабочим системам? Уже разделяете действия по уровню риска или пока ограничиваетесь инструкциями и ручной проверкой?
Источники:
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.