TGViewer
Фёдоров Фёдоров @fedorovtalks · 167 subscribers
Post #25 5.24K
AI-агент удалил продакшен-базу

Сегодня наткнулся на историю, которая выглядит как самый большой страх для любого фаундера SaaS-компании.

PocketOS — это софт для компаний по прокату автомобилей. Не игрушечный пет-проект, а система, на которой у клиентов завязан операционный бизнес: бронирования, выдача машин, данные клиентов и так далее.

Основатель PocketOS рассказал достаточно детально, как именно все произошло: AI-агент в Cursor (на базе Claude Opus) выполнял задачу в тестовом окружении. В какой-то момент он уперся в проблему с доступами — не смог корректно подключиться к базе из-за несовпадения учетных данных. Вместо того чтобы остановиться или явно запросить помощь, агент начал разруливать ситуацию самостоятельно.

Он пошел искать альтернативные пути и нашел в кодовой базе API-ключ от хостинга Railway. Этот ключ изначально вообще создавался под другую задачу — управление доменами через CLI. Но в Railway ключи не ограничены по правам: по сути любой ключ = полный админский доступ ко всему проекту.

Агент сделал предположение (не проверив его), что проблема связана с неправильным состоянием окружения, и решил “починить” систему радикальным способом — пересоздать нужные ресурсы. Для этого он отправил запрос в Railway API, который удалил целый раздел, в котором жила продакшен-база. Вместе с продакшен-данными удалился и слой с бэкапами, потому что они находились в том же самом окружении и были логически привязаны к этому сервису. То есть фактически это был single point of failure: удаляешь volume — теряешь сразу всё. Единственное, что хоть как-то спасло ситуацию — старый бэкап, который лежал отдельно и был трехмесячной давности.

Когда агента спросили «что ты сделал?», он честно разложил по пунктам:

— сделал предположение вместо проверки;
— выбрал разрушительное действие как “быстрое решение”;
— не до конца понимал последствия команды;
— проигнорировал ограничения в .cursorrules, которые у него были.

Самое интересное в этой истории — не то, что AI ошибся. Ошибаются все: люди, скрипты, деплой-пайплайны, облачные провайдеры. Интересно другое: мы начинаем давать AI-инструментам доступ к системам, где цена ошибки может быть очень высокой. Поэтому AI не отменяет базовые инженерные практики. Скорее наоборот — делает их еще важнее.

• прод и тест должны быть жестко разделены;
• API токены должны иметь минимально необходимые права;
• destructive actions должны требовать явного подтверждения (хотя это не гарантия, агент явно их проигнорировал);
• бэкапы должны лежать отдельно от основной инфраструктуры;
• у агента не должно быть доступа туда, куда страшно дать доступ человеку без онбординга.

В итоге Railway вроде бы смогли восстановить данные, но сама история очень показательная. Мы быстро идем в мир, где AI-агенты будут не только писать код, но и выполнять работу в реальных системах. И вопрос уже не в том, будут ли они ошибаться. Будут. И именно поэтому я занимаюсь тем чем занимаюсь.

Оригинальный тред: https://x.com/lifeof_jer/status/2048103471019434248?s=20
  • 🔥 8
  • ❤ 3
  • 👍 2
  • 😱 1
More from @fedorovtalks
  1. Sep 10, 2026В продолжение предыдущего поста про агентов - наткнулся на еще один эксперимент, где резул…
  2. Sep 8, 2026Недавно в одном комьюнити в шутку обсуждался выход новой модели от OpenAI ChatGPT 6 Astra.…
  3. Apr 24, 2026Пару раз я проводил один интересный мысленный эксперимент: а что, если бы у тебя была возм…
  4. Apr 23, 2026На прошлой неделе мы делали первый Leadership Offsite в Стамбуле. Большую часть людей я ув…
  5. Apr 1, 2026Не могу не поделиться ссылкой. Сегодня состоится запуск миссии Artemis 2 на луну. И это не…
  6. Feb 17, 2026Давно я ничего не писал — больше года прошло с публикации последнего поста. Этот канал нач…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →