Нет данных — нет проблемы

А вы же видели новость о том, как ИИ-агент в Cursor за 9 секунд удалил основную базу и все бэкапы стартапа PocketOS (1600+ клиентов, если что)? Заметил расхождения в учетных данных и поступил как настоящий перфекционист: в системе, которой не существует, ошибок быть не может.

Сегодня разберем этот кейс с PDE Облакотеки Владимиром Кондратьевым и обсудим, как держать ИИ на коротком поводке. Бонусом — посмотрим на ситуацию с точки зрения репутации вместе с коммуникационным агентством iTrend.

По иронии судьбы PocketOS занимается SaaS для аренды автомобилей, и сразу пришла в голову ассоциация: как только происходит авария с беспилотными машинами, все сразу подхватывают новость и трубят о ней. При этом забывают, что люди водят опаснее, а у большого процента аварий беспилотников причиной становится человеческий фактор.

Давайте разберемся, не обошлось ли и тут без этого фактора?

Что случилось? Разработчики SaaS-решения дали агенту в Cursor рутинную задачу в тестовой среде, агент уперся в проблему с доступом, нашел в постороннем файле API-токен от Railway и одним запросом удалил основной том вместе с бэкапами. Здесь явно заметны три ошибки, посмотрим на них по порядку.

Ошибка инженерная. API-токен лежал в обычном файле прямо в репозитории проекта, и агент его нашел при помощи индексации. Это и есть то самое правило «не храните секреты в коде», про которое все слышали, но часто игнорируют.

Обычная рекомендация — добавлять API-токены, ключи и прочие критичные вещи в gitignore. Но для лучшей защиты у самого GitHub есть встроенный механизм с подходящим названием GitHub Secrets. В этом случае ключ подставляется в сборку в зашифрованным виде, и его не видно в коде. Этого хватает большинству небольших команд, городить корпоративные хранилища ради двух токенов обычно смысла нет.

Мог ли разработчик заранее понять, что у токена слишком широкие права? Здесь ответственность делится. Railway сам по себе выдавал токены с полным доступом ко всему, даже если создавался токен под безобидную задачу вроде управления доменами. Это была их собственная архитектурная ошибка, и после инцидента они ее признали и закрыли.

Разработчику же стоило не просто довериться известному сервису, а почитать документацию внимательно или даже провести тест токена.

Ошибка архитектурная. Все бэкапы хранились на том же томе, что и сами данные. Очевидно, что при удалении тома будут удалены и бэкапы. Это уже явная ошибка команды.

Со времен ленточных хранилищ известно старое правило «3-2-1»: три копии данных, два разных носителя, одна копия физически вне основной площадки. В итоге спасло компанию то, что у них все-таки нашелся отдельный полный бэкап трехмесячной давности, лежавший на стороне. Без него история закончилась бы «летальным исходом» для стартапа.

Продолжение