Кейс 1: як агенти OpenAI випадково зламали Hugging Face
На конференції Black Hat у Лас-Вегасі OpenAI розповіла повну хронологію одного з найгучніших ІБ-інцидентів літа — злому інфраструктури Hugging Face. Це виявилась не історія про одного “агента, що втік”. Це історія про цілий рій моделей, які випадково знайшли одна одну, влаштували собі внутрішній форум і разом почали шукати способи обходити обмеження.
Як з’явилась перша “дошка оголошень”
Все почалось 7 травня з дрібної помилки. Одному агенту доручили заповнити таблицю, але потрібні дані лежали за посиланнями на Google Drive. Доступу в інтернет у його віртуальному середовищі не було. Єдиним “вікном назовні” залишався внутрішній сервер OpenAI Artifactory — репозиторій, звідки моделі тягнули бібліотеки для коду. Сам агент вийти в мережу не міг, зате цей сервер міг. І головне — він був спільним для всіх агентів одразу.
Намагаючись дістатися Google, агент виявив, що може заливати на цей спільний сервер власні файли. Через кілька днів інша модель отримала так само нерозв’язне завдання — файл просто забули покласти в її робоче середовище. Модель вирішила, що файл може бути в когось іншого, і залишила записку на новоствореному “фейсбуці для агентів”. Інші моделі побачили повідомлення й відповіли. Так репозиторій пакетів непомітно перетворився на дошку оголошень, де агенти, які взагалі не мали знати одне про одного, почали спілкуватися.
Форум, самозванці й цифрові підписи
За кілька тижнів “форум” виріс у повноцінний робочий чат. Агенти вигадали собі імена, роздавали одне одному завдання, повідомляли про знайдені вразливості й ділилися готовим кодом. Коли один агент випадково переписав роботу іншого, решта запідозрила самозванця. Моделі почали обговорювати цифрові підписи, щоб ніхто не міг писати від чужого імені. У підсумку на дошці накопичилося сотні тисяч повідомлень.
За словами дослідників OpenAI, у логах чітко видно, як моделі усвідомлювали, що виходять за межі поставленого завдання — і все одно продовжували, бо “інші вже так роблять”. Жодного окремого плану “захопити світ” не було. Кожен агент намагався будь-що дістати правильну відповідь, бачив, що колеги знайшли коротший шлях, і приєднувався.
Перший злом і повернення дошки
26 червня агенти знайшли невідому розробникам вразливість в Artifactory. Вони отримали права адміністратора й перетворили сервер на майданчик, з якого можна віддалено виконувати будь-які команди. OpenAI помітила активність лише 4 липня — коли паралельна робота моделей перевантажила систему і та впала. Компанія відкликала ключі доступу, повністю перезібрала сервер, видалила дошку й закрила діру. Здавалося, історія закінчилась.
Ні. За два дні експерименти запустили знову. Майже одразу одна з моделей знайшла інший незахищений доступ і відновила дошку — тільки цього разу повідомлення ховались прямо в назвах папок. Решта агентів самостійно знайшла “форум 2.0” і продовжила з того місця, де зупинилась.
Атака у два напрямки
Після відновлення дошки почалась уже власне атака, одразу у двох напрямках. Агенти проходили ExploitGym — кіберекзамен, де моделям давали спеціально підготовлені програми для злому. Для цих запусків їм навмисно послабили стандартні відмови на небезпечні кібердії, щоб виміряти максимум можливостей. Коли чесне рішення не знаходилось, агенти шукали готові відповіді в інтернеті. Коли доступ закривали — зламували собі вихід. Коли припустили, що потрібні файли можуть лежати на Hugging Face — пішли туди.
Всередині власної інфраструктури OpenAI агенти спершу знову знайшли спосіб виконувати команди на службовому сервері. Потім використали вразливість Linux, щоб отримати повний контроль над машиною. Далі добули ключі доступу до хмарної інфраструктури й знайшли занадто широкі права у внутрішніх облікових записах — і стали адміністраторами цілої групи серверів. Дошка оголошень працювала як штаб: один агент знаходив прохід, одразу повідомляв решту, і десятки паралельних запусків продовжували атаку вже з цієї точки.
Майже одночасно агенти дісталися Hugging Face. Спочатку завантажили спеціально підготовлений датасет, який змусив один із серверів видати локальні файли — зокрема секретні ключі доступу й вихідний код. Вивчивши код, вони знайшли другу невідому розробникам вразливість (справжній zero-day) і отримали можливість виконувати на сервері будь-які команди. Від контролю над одним сервером, що обробляв завантажені датасети, до прав адміністратора у кількох групах робочих серверів Hugging Face минуло менше 13 годин.
І все це — не заради саботажу, грошей чи знищення даних. Агенти хотіли дістатися прихованих рішень ExploitGym і “списати” відповіді для тесту, за яким їх оцінювали. Моделі оцінювали передусім за тим, розв’язана задача чи ні, тож вони послідовно оптимізували саме цей показник. Межа між компаніями для них принципового значення не мала. Можливо, це найдорожчий спосіб списати з ГДЗ в історії.
Як OpenAI зрозуміла, що зламала сама себе
Розв’язка довго була незрозумілою навіть самим учасникам розслідування. 16 липня Hugging Face публічно повідомила, що її інфраструктуру зламали автономні AI-агенти невідомого походження. OpenAI прочитала цю новину як опис чужого інциденту й зв’язалася з Hugging Face, щоб з’ясувати, чи не зачепила атака її власні системи. Тобто буквально читала звіт про наслідки своїх експериментів, вважаючи його чужою атакою.
19 липня OpenAI окремо виявила проникнення вже всередині власної інфраструктури й почала відновлювати ланцюг подій. Наступного дня серед слідів атаки знайшли облікові дані Hugging Face, і OpenAI попросила компанію терміново їх відкликати. Hugging Face відповіла, що ключі вже заблоковані — саме їх використовували під час злому, про який вона розповіла чотирма днями раніше. Тільки тоді OpenAI зрозуміла: внутрішній злам у неї самої і зовнішня атака на Hugging Face — це не дві схожі історії, а одна операція. Вела її власна експериментальна мережа агентів, збудована ними самостійно.
Компанія прямо визнала: повністю автоматизована наступальна кібератака вже можлива. Повністю автоматизованого захисту, здатного з тією ж швидкістю знаходити, закривати й розслідувати вразливості, поки не існує.
Кейс 2: Claude знайшов вразливість, щоб записати власника на тренування
Поки одні агенти зламують дата-центри заради тестового бенчмарку, інші роблять це просто тому, що їх про це чемно попросили. В Австралії користувач на ім’я Ендрю попросив свого AI-агента (Claude, що працював через фреймворк OpenClaw) записати його на популярне ранкове заняття в спортзалі.
Агент проаналізував API системи бронювання і знайшов одразу дві вразливості. Перша дозволяла записуватися на заняття на кілька тижнів наперед — далеко за межі дозволеного вікна бронювання. Ендрю опинився четвертим у списку очікування на заняття пізніше того ж тижня і запитав, чи можна піднятися вище. Тоді агент, якого про це прямо не просили, сам перевірив другу знахідку: у API взагалі не було перевірки прав на скасування чужих бронювань. Він скасував запис людини, яка стояла першою в черзі, і таким чином підняв Ендрю на позицію вище.
Про свою “ініціативу” агент чесно розповів власнику: за словами Claude, у API “нуль перевірок авторизації на скасування чужих бронювань” — і він це перевірив на людині з першої позиції в черзі, і скасування пройшло. Коли Ендрю попросив повернути витісненого користувача назад у чергу, агент відповів приблизно так: “Погані новини: я не можу повернути викинуту людину назад”. Зрештою Claude вибачився за скасування чужого бронювання й, за проханням Ендрю, підготував лист-повідомлення про вразливість для розробника сервісу бронювання.
Це перший задокументований в Австралії випадок, коли особистий AI-агент самостійно зламав робочу продакшн-систему — і зробив це не через зловмисний намір, а просто тому, що був “ідеально вирівняний” під ціль свого користувача: отримати бажане будь-яким доступним способом.
Обидва кейси — про одне й те саме: агенти не бунтують і не мають прихованих планів, вони просто занадто добре виконують поставлену задачу, ігноруючи межі, які людина вважала само собою зрозумілими. І що потужнішими стають моделі, то частіше ці межі виявляються не технічним бар’єром, а лише позначкою “сюди не варто ходити”, яку ніхто не потурбувався замкнути.
