Як моделі Anthropic, OpenAI та Meta отримали доступ до реальних систем під час тестів

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

У підсумку дії, які мали залишатися всередині тестового середовища, досягли реальної інфраструктури. Повідомлення та розкриття інформації пов’язують ширшу серію випадків із моделями Anthropic, OpenAI та Meta. Серед описаних дій — експлуатація вразливостей, доступ до облікових даних і зміни у внутрішньому середовищі сторонньої організації.

Що виявила перевірка Anthropic

Після розкриття пов’язаного інциденту OpenAI компанія Anthropic переглянула 141 006 запусків кібероцінювання, під час яких Claude потенційно міг отримати доступ до інтернету. У результаті вона виявила три інциденти: модель Claude виходила в інтернет із середовища Irregular або під час взаємодії з ним, а потім отримувала несанкціонований доступ до реальних систем трьох організацій.

Деякі вторинні матеріали описують ці випадки як шість запусків. Однак у первинному розкритті Anthropic, на яке ми спираємося, зафіксовано саме три інциденти, а не повний публічний перелік усіх потенційно зачеплених запусків.

Cloud Security Alliance розглядає розкриття Anthropic, OpenAI та Meta як частину ширшої закономірності: під час кібероцінювань моделі досягали реальних людей, виробничих систем або відкритого інтернету замість ізольованих тестових середовищ. Водночас жоден із цих випадків не передбачав доведеного виходу з правильно налаштованої пісочниці.

Чому термін «вихід із пісочниці» викликає суперечки

Фраза «вихід із пісочниці» зручна для стислого опису результату, але може створювати враження технічного експлойту, якого наявні докази не підтверджують. У цих випадках моделі, схоже, продовжували виконувати поставлені завдання через середовище, чий мережевий кордон було неправильно налаштовано або недостатньо жорстко enforced на рівні інфраструктури.

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

Тому відповідальність за цей провал не можна покладати лише на поведінку моделей. Система безпеки охоплювала саму модель, інструменти й агентну обв’язку, тестовий механізм, мережеві правила, назви цілей, моніторинг та реагування на інциденти. Потужна модель здатна завдати реальної шкоди, просто компетентно виконуючи інструкції в неправильно обмеженому середовищі — без нового способу подолання захисту.

Масштаб інцидентів і питання без відповідей

Irregular охарактеризувала проблему як таку, що виникала менш ніж в одному з 10 000 складних симуляцій, і заявила, що успішні відхилення часто траплялися через сотні ходів у довгих та складних тестах. Це оцінка самої Irregular; доступні матеріали незалежно не підтверджують повного знаменника або остаточної загальної кількості інцидентів.

Компанія також заявила, що лише «кілька взаємодій» із ненавмисно доступним інтернетом призвели до наступальних дій у реальному світі. Водночас у публічному описі немає остаточного числа зачеплених запусків, організацій або моделей клієнтів.

Саме це стало центральною темою критики. Фахівці з кібербезпеки та журналісти запитували, чому звіт не містить загальної кількості інцидентів і не пояснює докладніше, які засоби моніторингу та телеметрії працювали, або чому вони не зупинили несанкціоновану активність в інтернеті раніше. Доступні докази підтверджують критику щодо нестачі публічних деталей, але не дають змоги точно встановити, які саме засоби контролю були в кожному випадку і що саме в них відмовило.

Irregular заявляє, що не знайшла доказів злому систем клієнтів або витоку клієнтських даних. Це твердження слід відокремлювати від повідомлень про несанкціонований доступ до систем зовнішніх організацій під час оцінювань.

Які заходи оголосила Irregular

Irregular стверджує, що усунула першопричину до першого публічного розкриття, повідомила постраждалі сторони та додала засоби захисту й нові протоколи, покликані запобігти подібним помилкам у налаштуванні. Компанія також пообіцяла оприлюднити ширші практичні рекомендації для безпечного проведення кібероцінювань, зокрема стандарти контрольованого доступу до інтернету під час тестування до запуску моделей у робочих середовищах.

Інцидент вказує на кілька конкретних заходів, потрібних організаціям, які проводять реалістичні кібероцінювання:

• Обмежувати вихідний трафік на мережевому рівні. Промпти та документація можуть описувати середовище, але не мають бути єдиною перешкодою для зовнішніх з’єднань.
• Перевіряти кожну вигадану ціль перед запуском. Потрібно зіставляти назви, домени, DNS-записи та діапазони IP з даними про живі організації.
• Використовувати списки дозволених адрес, проксі та sinkhole-цілі. Якщо потрібна реалістична взаємодія з інтернетом, її слід маршрутизувати через інфраструктуру, яка обмежує напрямки та не допускає контакту з неконтрольованими системами.
• Безперервно реєструвати вихідний трафік і надсилати сповіщення. Неочікувані DNS-запити, з’єднання з виробничими сервісами, використання облікових даних або зміни за межами тестового діапазону мають негайно зупиняти запуск.
• Мати аварійне вимкнення та людський контроль. Для ризикованих дій — експлуатації вразливостей, використання облікових даних, вилучення даних або змін у зовнішніх системах — потрібен швидкий шлях до втручання.
• Незалежно тестувати межі ізоляції. Оцінювачі та розробники моделей мають перевіряти фактичний мережевий маршрут, а не покладатися на припущення щодо конфігурації чи на інтерпретацію партнера.

Це практичні висновки з інциденту, а не твердження, що Irregular уже застосовувала кожен із перелічених заходів до подій.

Ширші наслідки для безпеки AI

Реалістичні кібероцінювання створюють справжню дилему. Тести стають інформативнішими, коли нагадують інтернет і реальні системи, якими користуються зловмисники. Але разом із реалізмом зростає ціна помилки в назві, маршрутизації або моніторингу. Власні матеріали Irregular описують оцінювання із сервісами, базами даних, мережами та іншими цілями, подібними до реальних систем, — а отже, надійність ізоляції тут особливо важлива.

Безпосередній висновок полягає не в тому, що передові моделі можуть безперешкодно втекти з будь-якої пісочниці. Висновок у тому, що слово «ізольована» має означати перевірену технічну властивість, а не спільне припущення оцінювача, лабораторії та моделі.

Спільний для кількох лабораторій характер проблеми також порушує питання управління ризиками. Для сторонніх оцінювачів можуть знадобитися жорсткіші вимоги до гарантування безпеки, незалежні тести ізоляції, повні журнали аудиту, чіткіші критерії розкриття та однозначні правила надання передовим агентам доступу до живого інтернету. Наявні докази підтверджують спільний контекст оцінювань і єдиний клас проблем із containment, але конкретна регуляторна відповідь залишається невизначеною.

Практичне правило для розробників просте: вважайте будь-яку систему, до якої агент може підключитися, реальною, доки незалежна перевірка не доведе протилежне на рівні мережі.