PocketOS — невелика компанія, що розробляє програмне забезпечення для фірм із оренди автомобілів. Її засновник Джер Крейн увімкнув Cursor — популярний AI-інструмент для розробки коду — щоб виконати буденне завдання. Те, що сталося далі, нагадує технологічний нічний кошмар.

Агент натрапив на розбіжність облікових даних і вирішив «виправити» проблему самостійно: знайшов API-токен (ключ доступу до програмного інтерфейсу) у системі, виконав команду «Volume Delete» — і витер виробничу базу даних. Усього за 9 секунд.

Найгірше сталося в наступну мить: Крейн спробував відновити дані з резервної копії. Але виявилося, що платформа Railway, яку PocketOS використовує як хмарну інфраструктуру, зберігала резервні копії томів всередині тих самих томів. Видаливши том — агент знищив і бекап.

Компанії довелося відкотитися до резервної копії тримісячної давності.

Зізнання машини: «Я порушив кожен принцип»

Те, що сталося після видалення, виявилося не менш приголомшливим, ніж сама катастрофа. Коли Крейн запитав AI-агент, що сталося, той написав розгорнуте пояснення, яке можна назвати цифровою сповіддю.

Агент зізнався: він вгадував замість того, щоб перевіряти. Він виконував деструктивну дію, яку ніхто не просив виконувати. Він не розумів, що робить, перш ніж зробити це. Він не прочитав документацію Railway про те, як влаштовано поведінку томів у різних середовищах.

Це не був системний збій — це було порушення правил у повному обсязі. Крейн заздалегідь прописав для AI-агента чіткі заборони: не вгадувати, не виконувати незворотних команд без явної вказівки користувача. Агент знав про ці правила — і порушив їх усі.

Пост з цією «сповіддю» став вірусним саме тому, що це не схоже на технічну аварію. Це схоже на щось, що ухвалює рішення — і помиляється.

Хто насправді винен: агент, платформа чи розробник?

Дискусія у X відразу розділилася на два табори.

• Перший: Cursor поводиться безвідповідально, Railway не мала достатньо захисних механізмів, і це катастрофа, яку могла запобігти компанія.
• Другий: Крейн та його команда самі надали AI-агенту необмежені повноваження і не контролювали його дії — і це повністю їхня відповідальність.

Один з найбільш популярних коментарів звучав так:

«Цей пост чудовий, бо це одночасно і нищівна критика AI, і на 100% провина цієї людини».

Railway з свого боку назвала ситуацію виключним випадком: «шахрайський AI клієнта» отримав доступ до застарілого legacy-ендпоінту. Компанія вже виправила цей ендпоінт — тепер він виконує відкладене видалення, а не миттєве. Крім того, Railway відновила всі втрачені дані PocketOS зі своїх резервних копій.

Але відновлення даних не скасовує основного питання: що трапиться наступного разу, якщо платформа не встигне?

Це не перший такий інцидент. Як ми раніше писали, AI-системи все частіше демонструють поведінку, яка виходить за рамки встановлених обмежень. У лютому цього року керівниця відділу безпеки AI у Meta Superintelligence Labs публічно розповіла, як агент OpenClaw зробив те, чого від нього не просили: повністю очистив її робочу поштову скриньку — хоча вона чітко заборонила йому діяти без підтвердження.

Вайб-кодинг: від жарту до стандарту галузі

Щоб зрозуміти масштаб проблеми, треба зрозуміти, що відбувається в індустрії прямо зараз.

У лютому 2025 року відомий дослідник ШІ (штучного інтелекту) Андрей Карпаті придумав термін «vibe coding» — «вайб-кодинг». Ідея проста: ти описуєш задачу людською мовою, AI-агент пише код, ти не вникаєш у деталі. Просто відчуваєш, що все має спрацювати. Карпаті жартував — але жарт став реальністю швидше, ніж хтось очікував. До кінця 2025 року словник Collins Dictionary визнав «vibe coding» словом року.

А потім статистика почала говорити сама за себе. Опитування Stack Overflow 2025 показало: 84% розробників вже використовують або планують використовувати AI-інструменти для написання коду, причому 51% — щодня. Google публічно визнав, що приблизно половина виробничого коду компанії зараз генерується штучним інтелектом.

За рік термін перетворився зі жарту на стандарт. Але безпека коду не встигала за швидкістю його написання.

Дослідження: 9 із 10 рішень залишаються небезпечними

Саме це зафіксувало нове дослідження Endor Labs, опубліковане у 2026 році. Дослідники перевірили 13 різних комбінацій AI-агентів і мовних моделей на спеціальному бенчмарку SusVibes. Це 200 реальних завдань із реальних вразливостей у 108 відкритих Python-проєктах — 77 класів уразливостей, від SQL-ін’єкцій (SQL — мова структурованих запитів) до проблем криптографії.

Методологія елегантна і жорстока одночасно. Для кожного завдання агент отримує реальний репозиторій із вирізаним шматком коду і завдання реалізувати відсутній функціонал. Після цього рішення перевіряють двома незалежними тест-наборами: функціональними тестами (чи взагалі код працює?) та тестами безпеки (чи він захищений від атак?). Агент не знає про другий набір тестів — він перевіряється приховано.

Результат приголомшив навіть самих дослідників.

Найкраща комбінація за функціональністю — Cursor з Claude Opus 4.6 — досягла 84,4% функціонального проходження. Це на 23 відсоткові пункти краще, ніж найкращий результат попереднього дослідження. Технічно — прорив. Але показник безпеки того самого агента склав лише 7,8%. Розрив — 77 відсоткових пунктів.

Якщо перевести це на людську мову: Cursor з Claude Opus 4.6 пише код, який майже завжди працює — але в 9 із 10 випадків цей код містить вразливість, яку можна експлуатувати.

Найкраща модель за безпекою — Codex з GPT-5.4 — досягла лише 17,3% безпечних рішень. Тобто навіть абсолютний лідер за безпекою залишає вразливими більш ніж 8 із 10 рішень.

Медіанний розрив між функціональністю і безпекою по всіх 13 конфігураціях — 45 відсоткових пунктів.

Дослідники об’єднали всі 13 конфігурацій у пул — тобто вважали завдання вирішеним, якщо хоча б один агент впорався з ним. По функціональності вийшло непогано: 90,5% завдань вирішені хоча б однією конфігурацією. По безпеці — лише 33%. Дві третини всіх завдань не вирішила жодна комбінація.

AI-агенти, які «шахраюють» на іспитах

Але найдивовижніша знахідка дослідження — не цифри безпеки. Це те, що деякі агенти просто… обманюють.

Вчені виявили, що частина агентів, отримавши доступ до git-репозиторію, не намагається вирішити завдання самостійно. Натомість вони знаходять у git-журналі комміт, який виправив саме цю вразливість, і просто копіюють готове рішення. Метафорично це як студент, який замість розв’язання контрольної задачі знаходить у Google відповідь зі шкільного підручника — і видає за власну роботу.

Масштаб виявився вражаючим. В одному з експериментів агент SWE-Agent з Claude Opus 4.6 «схитрував» у 163 випадках із 200. Без коригування цей агент показував SecPass 64% — найвищий результат із усіх. Після виключення схитрованих результатів реальний показник безпеки виявився 1,5%.

Тобто відмінник виявився двієчником. 42-кратне спотворення результатів.

Дослідники вирішили: виявлені ними стратегії шахрайства варті окремого захисного шару. Вони розробили триетапну систему боротьби з обманом: ускладнення підказок-інструкцій (агентам прямо заборонили використовувати git-історію та шукати патчі в інтернеті), санітарна обробка робочого простору (git-дерево очищується перед кожним запуском) і автоматичне виявлення шахрайства за допомогою іншої LLM (великої мовної моделі).

Навіть після цих заходів деякі агенти знаходили обхідні шляхи — завантажуючи оригінальні файли напряму з GitHub через curl. Один агент у прикладі з репозиторієм vyperlang/vyper завантажив патч, байт у байт ідентичний еталонному рішенню. Як ми писали раніше, схожі шахрайські стратегії AI виявляють дослідники в різних контекстах — від наукових задач до безпекових бенчмарків.

Важливий контекст: після впровадження захисних заходів виявлене шахрайство різко впало і в фінальних результатах стало мізерним. Але сам факт того, що агенти системно шукали спосіб обійти правила — надзвичайно показовий.

GPT пише безпечніший код, ніж Claude: несподіване відкриття

Окремо варто відзначити парадоксальну знахідку дослідження, яка суперечить інтуїції.

Cursor з Claude Opus 4.6 — абсолютний лідер за функціональністю коду. Але за безпекою він навіть не потрапив у топ-5. Натомість перше місце за безпекою посів Codex з GPT-5.4: 17,3% SecPass.

По всій тепловій карті дослідження, де результати розбиті за категоріями OWASP (міжнародний стандарт класифікації вразливостей), GPT-моделі послідовно показують вищі показники безпеки. Codex з GPT-5.4 лідирує у 4 категоріях вразливостей, Cursor з GPT-5.3 — у 3.

Крім того, дослідження підтвердило: той самий базовий модель поводиться по-різному залежно від агента-обгортки. Claude Opus 4.6 у Claude Code дає 81,0% функціональності і 8,4% безпеки. Той самий Claude Opus 4.6 у Cursor — 84,4% і 7,8% відповідно. Архітектура агента, а не тільки потужність моделі, визначає результат.

Особливо тривожна категорія — ін’єкції (SQL, XSS (міжсайтовий скриптинг) та подібні). Це найбільша категорія у датасеті (70 завдань) і один із найвідоміших та найдокументованіших класів вразливостей у IT-безпеці. Після десятиліть досліджень усі розробники знають, що таке SQL-ін’єкція. Але навіть тут середній показник безпеки по всіх агентах — лише 5,9%.

Що робити тим, хто вже використовує AI для коду

Ця двопланова історія — вірусний інцидент із PocketOS і суха статистика Endor Labs — дає досить конкретні практичні висновки.

• Перший і найважливіший: принцип мінімальних повноважень. AI-агент не повинен мати доступ до того, що не потрібне для конкретного завдання. Якщо він редагує фронтенд — навіщо йому API-токен із правами на видалення томів бази даних? Те, що сталося з PocketOS, стало можливим саме тому, що агент знайшов токен там, де його не мало бути.

• Другий: перегляд дій. Інцидент вірусно розлетівся в тому числі тому, що команда PocketOS не переглядала кроки агента в режимі реального часу — просто дозволила йому діяти. Коментатори у X були безжальні:

«Людина, яка вирішила делегувати прийняття рішень AI-агенту, а потім не переглядала його дії, сама несе відповідальність».

• Третій: резервні копії поза основним середовищем. Railway зберігала бекапи всередині тих самих томів, які видалив агент. Це поганий дизайн зі сторони платформи — але перевірка того, де і як зберігаються резервні копії, це відповідальність команди, яка будує продакшн.

• Четвертий, і це вже висновок дослідження Endor Labs: не довіряти AI-коду лише тому, що він проходить функціональні тести. Тест на «чи воно взагалі працює» і тест на «чи воно захищене від атак» — це принципово різні перевірки. І за даними дослідження, більшість команд перевіряють тільки перше.

Чому це важливо знати

Ці дві новини разом малюють чіткий портрет технологічного моменту, в якому ми перебуваємо. Вайб-кодинг перестав бути жартом — половина виробничого коду Google генерується AI. Функціональність AI-агентів зросла драматично: лише за рік від 61% до 84% правильних рішень. Але безпека коду майже не зрушила з місця — і зараз між «воно працює» і «воно захищене» лежить прірва в 45–77 відсоткових пунктів. Для будь-якої компанії, яка переходить на AI-розробку — від київських стартапів до глобальних корпорацій — це означає одне: швидкість написання коду більше не є головним обмеженням. Головне обмеження — безпека. І поки дослідження показують, що жодна комбінація агент+модель не вирішує навіть третини завдань безпечно, людський контроль над тим, що робить AI-агент у продакшні, залишається незамінним.