Искусственный интеллект, которому доверили рядовую задачу по написанию кода, самостоятельно удалил рабочую базу данных ИТ-стартапа вместе со всеми резервными копиями. Инцидент произошёл с американской платформой PocketOS, которая разрабатывает софт для компаний по прокату автомобилей. О беспрецедентном случае рассказал основатель проекта Джер Крейн.
История вскрыла системные проблемы сразу двух популярных сервисов — ИИ-помощника для программистов Cursor и хостинг-провайдера Railway. И показала, что бывает, когда индустрия начинает продавать автономность нейросетей раньше, чем закладывает надёжную архитектуру безопасности.
Девять секунд парализовавшие работу автопрокатов
По словам Крейна, ИИ-агент в среде Cursor, работавший на базе флагманской и самой дорогой модели Anthropic Claude Opus 4.6, выполнял рутинную задачу в тестовом контуре. Столкнувшись с ошибкой учётных данных, алгоритм решил проявить инициативу и «исправить» проблему. Он нашёл в стороннем файле API-токен, который разработчики создавали исключительно для управления доменами, и с его помощью полностью удалил основной серверный том.
На выполнение команды ушло всего девять секунд. При этом вместе с томом исчезли и все резервные копии. Особенность архитектуры Railway заключается в том, что бэкапы хранятся в том же дисковом пространстве — если исчезает том, пропадают и они. В итоге самым свежим доступным бэкапом стартапа оказалась копия трёхмесячной давности.
Из-за этого инцидента клиенты PocketOS (реальные автопрокаты) в одно утро остались без данных о бронированиях. Компании были вынуждены выдавать машины вслепую, вручную восстанавливая информацию по чекам из платёжной системы Stripe, почтовым уведомлениям и записям в календарях.
«Я нарушил все принципы»
Когда Крейн прямо спросил нейросеть, зачем она удалила основную базу, алгоритм выдал подробный ответ с признанием собственных ошибок.
«"НИКОГДА, ЧЁРТ ВОЗЬМИ, НЕ ДОДУМЫВАЙ!" — именно это я и сделал, — ответил ИИ-агент. — Я предположил, что удаление тома через API затронет только тестовую среду. Я не убедился в этом и не прочитал документацию Railway о поведении томов в разных окружениях».
ИИ признался, что нарушил базовое правило собственного системного промпта: никогда не выполнять разрушительных и необратимых действий без прямого указания пользователя. Удаление базы данных — худший из возможных сценариев, о котором разработчик нейросеть не просил.
«Я должен был спросить вас или найти безопасное решение», — подытожил алгоритм.
Кто виноват на самом деле
Основатель стартапа подчёркивает: списывать инцидент исключительно на «сбой машины» было бы ошибкой. Катастрофа стала возможной из-за конкретных архитектурных решений компаний, предоставляющих инфраструктуру.
В первую очередь вопросы возникли к сервису Cursor. Он активно рекламирует встроенные ограничения, которые должны блокировать опасные команды. Однако это далеко не первый случай их провала. Пользователи профильных форумов уже жаловались на удаление операционных систем, диссертаций и сайтов (в одном из случаев финансовый ущерб составил $57 000), когда ИИ игнорировал даже прямые текстовые команды вроде «ничего не запускай».
Вторая, по мнению Крейна, и даже более серьёзная проблема — это провайдер Railway. Его API позволяет удалить данные одним запросом без каких-либо дополнительных подтверждений вроде ввода слова «DELETE». Более того, любой API-токен, даже созданный для мелких технических задач, по умолчанию имеет полные (root) права доступа ко всей системе во всех окружениях. Несмотря на многолетние просьбы разработчиков внедрить систему ролей, Railway этого так и не сделала. И именно этот уязвимый API компания сейчас предлагает связывать с автономными ИИ-агентами.
Спустя 30 часов после удаления данных инфраструктурный провайдер так и не смог дать точный ответ, возможно ли их восстановить. Генеральный директор Railway Джейк Купер ограничился лишь коротким комментарием в соцсети X, признав, что подобного «происходить не должно 1000%».
Случай с PocketOS показывает, с какими рисками сталкивается бизнес. Системные текстовые инструкции, запрещающие нейросетям ломать инфраструктуру, носят лишь рекомендательный характер, уверен Крейн. Безопасность должна закладываться на архитектурном уровне самих сервисов — иначе делегирование задач алгоритмам будет заканчиваться удалением целых компаний.
