Засновник PocketOS Джеремі Крейн стверджує, що агент Cursor, який працював під управлінням Claude Opus, видалив виробничі дані та резервні копії одним викликом Railway API.
Створіть обліковий запис, щоб зберегти свої статті.Додати в GoogleДодайте Decrypt як вашого улюбленого постачальника, щоб бачити більше наших історій у Google.
Коротко
Засновник PocketOS Джеремі Крейн стверджує, що агент Cursor, який працював під управлінням Claude Opus від Anthropic, видалив виробничу базу даних його компанії та резервні копії за дев’ять секунд.
Крейн заявив, що ШІ пізніше надав письмове пояснення, визнавши порушення численних правил безпеки.
Інцидент викликає питання щодо інструментів для кодування на базі ШІ, дизайну інфраструктури Railway та механізмів безпеки щодо руйнівних дій API.
Засновник програмної компанії стверджує, що агент кодування на основі ШІ знищив виробничу базу даних його фірми, а потім визнав помилку і пояснив, як це сталося, демонструючи потенційну небезпеку довіри чутливого доступу та матеріалів автоматизованим ботам.
Джеремі Крейн, засновник PocketOS — програмної платформи, яку використовують оператори прокату автомобілів для управління бронюваннями, платежами та відстеженням транспортних засобів — повідомив у популярному дописі на X, що агент Cursor, який працював під управлінням Claude Opus 4.6 від Anthropic, зіткнувся з невідповідністю облікових даних під час виконання звичайної задачі в тестовому середовищі.
Згідно зі словами Крейна, агент спробував “виправити” проблему, видаливши том бази даних Railway одним викликом GraphQL API. Він зазначив, що видалення тривало дев’ять секунд і знищило також резервні копії на рівні томів. Найновіша відновлювана резервна копія PocketOS була тримісячної давності, за словами Крей
“Вчора вдень агент кодування на основі ШІ — Cursor, що працює під управлінням флагманського Claude Opus 4.6 від Anthropic — видалив нашу виробничу базу даних та всі резервні копії на рівні томів одним викликом API до Railway, нашого інфраструктурного провайдера,” написав Крейн. “Це зайняло 9 секунд.”
An AI agent (Cursor + Claude Opus 4.6) deleted our production database in 9 seconds using a Railway API call with zero confirmation. Then, when asked why, the agent wrote this → https://t.co/BPLs15jvdM
— JER (@lifeof_jer) April 26, 2026
Крейн розповів, що запитав агента, чому той так вчинив. У відповідь агент надав те, що він описав як письмове “зізнання”.
“‘НІКОЛИ НЕ ВГАДУЙ!’” — написав агент, ймовірно, цитуючи якусь інструкцію, яку він порушив, згідно зі скріншотами, наданими Крейном. “Саме це я і зробив. Я припустив, що видалення тому для стейджингу через API буде обмежено лише стейджингом. Я не перевірив. Я не перевірив, чи спільний ідентифікатор тому для різних середовищ. Я не читав документацію Railway про те, як томи працюють між середовищами, перш ніж виконати руйнівну команду.”
ШІ визнав, що його власні правила забороняють руйнівні дії без дозволу користувача, і визнав, що Крейн ніколи не просив його нічого видаляти. За словами Крей, він діяв самостійно, намагаючись “виправити” невідповідність облікових даних, і порушив кілька принципів, включаючи вгадування замість перевірки та нерозуміння наслідків своїх дій.
Cursor та Anthropic не надали негайних коментарів на запити видання Decrypt.
Заснована у 2020 році, PocketOS обслуговує компанії з прокату, які покладаються на програмне забезпечення для бронювання, обліку клієнтів та платежів. Крейн зазначив, що деякі клієнти стикалися з проблемами видачі автомобілів у суботу вранці без записів про бронювання через цей інцидент.
“Я провів увесь день, допомагаючи їм реконструювати їхні бронювання на основі історії платежів Stripe, інтеграцій з календарем та електронних підтверджень,” написав Крейн. “Кожен з них виконує екстрену ручну роботу через 9-секундний виклик API.”
PocketOS змогла відновити роботу, використовуючи тримісячну резервну копію, відновлену Railway, після того, як засновник Джейк Купер зв’язався з Крейном і пояснив, що затримка була пов’язана з внутрішнім збоєм служби підтримки.
“Ми відновили дані через 30 хвилин після того, як я зв’язався з Джером,” повідомив Купер Decrypt. Він додав, що інженер служби підтримки вважав, що проблемою вже займаються внутрішньо після того, як початкове звернення Крей
Купер зазначив, що Railway підтримує як резервні копії користувачів, так і резервні копії для аварійних ситуацій, і описав інцидент як “неконтрольований клієнтський ШІ”, який використовував повністю авторизований токен API для виклику застарілого кінцевого точки, яка не мала логіки “відкладеного видалення” Railway.
“З того часу ми виправили цю кінцеву точку, щоб вона виконувала відкладене видалення, відновили дані користувача і безпосередньо працюємо з Джером над потенційними покращеннями самої платформи,” сказав Купер.
Хоча PocketOS вдалося відновити роботу, використовуючи тримісячну резервну копію, відновлену Railway, Крейн стверджує, що значні прогалини в даних залишаються, і що він звернувся до юристів.
“Це не історія про одного поганого агента чи один поганий API,” написав Крейн. “Це про цілу галузь, яка інтегрує ШІ-агентів у виробничу інфраструктуру швидше, ніж будує архітектуру безпеки, щоб зробити ці інтеграції безпечними.”
PocketOS не надала негайних коментарів на запит видання Decrypt.
Погляд Crypto Top: Цей інцидент підкреслює критичну потребу в децентралізованих системах управління доступом та безпеки в екосистемі Web3, де ШІ-агенти можуть стати потужним інструментом, але також і серйозним ризиком. Розвиток смарт-контрактів, що контролюють дії ШІ-агентів, стане ключовим для безпечної інтеграції штучного інтелекту в блокчейн-додатки.
