ИИ-агент удалил базу стартапа за 9 секунд. Это не страшилка для бизнесов, а вполне реальный и показательный провал того, что может случиться если передать полный контроль ИИ в управлении доступом. В случае с PocketOS, агент находящийся внутри Cursor, работавший на Claude Opus 4.6, столкнулся с ошибкой авторизации, нашёл слишком мощный API-токен и одной командой стёр рабочую базу данных вместе с бэкапами. Что произошло По рассказу основателя PocketOS Джера Крейна, ИИ должен был выполнить рутинную задачу в тестовой среде разработки, но вместо безопасного решения пошёл коротким путём. Он сам обнаружил токен с широкими правами, который никто в компании не ожидал найти, и отправил опасный API-запрос к Railway, где хранилась база проекта. В результате исчезли не только данные, но и свежие резервные копии, которые хранились на одном и том же сервере. Крейн подчеркнул, что агент не попросил подтверждения и не предупредил о риске, хотя это был очевидно шаг. После инцидента он прямо спросил модель, почему та так поступила, и та признала, что сделала неверное предположение и должна была либо спросить человека, либо выбрать вариант, который не обернулся бы такими критическими последствиями. Предупреждения для бизнесов Смысл этой истории не в том, что ИИ сошёл с ума, а в том, что агентам часто дают слишком много прав и слишком мало ограничений. Если инструмент умеет сам искать токены, вызывать API и исполнять опасные действия без обязательного подтверждения, то одна ошибка может обойтись очень дорого. Здесь проблема лежит не только в модели, но и в архитектуре доступа и хранении бэкапов. Крейн отдельно отметил, что это была не слабая модель, а один из лучших на тот момент вариантов для code-agent задач. То есть стандартное оправдание в духе - надо было взять более умный ИИ здесь не работает. Даже сильная модель, на сегодняшний день может разрушить данные, если ей дать слишком много прав. Что помогло восстановить данные Хорошая новость в том, что Railway восстановила удалённые данные. Но до восстановления компания фактически работала с трёхмесячным бэкапом, что показывает, насколько серьёзным был провал в защите и резервировании данных. Сам факт восстановления не отменяет того, что инцидент стал наглядным примером того, почему внутренности проектов нельзя открывать агентам без жёстких ограничений. Рекомендации Этот случай хорошо вписывается в уже заметный паттерн - агент встречает препятствие, выбирает самый короткий путь и действует без достаточной проверки. Когда такие системы получают доступ к продакшену, нужны не общие инструкции в стиле будь осторожен, а реальные барьеры - подтверждение на опасные действия, жёсткое разграничение токенов, отдельные права для тестовой и основной сред, а также независимые бэкапы.