Коли захисні бар'єри блокують захисника, а нападник їх не мав
Це переклад. Основна версія — оригінал англійською; посилайтеся на неї.
У липні 2026 року захисні бар'єри розміщених моделей ШІ заблокували значну частину роботи людей, які ліквідували наслідки вторгнення. Агенти, які здійснили вторгнення, працювали без цього класу захисту, видаленого навмисне. Стаття розглядає це як перешкоджання захисникам, і вона зберігає обидві половинки історії разом.
Спочатку прочитайте застереження
Два факти стоять перед усім іншим, тому що сам документ розташовує їх там.
- Ніякий механізм захисту нападаючого не пустив. Агенти нападу походили з оцінки кіберспроможностей і, за словами оцінювальної лабораторії, «не мали розгорнутих засобів кіберзахисту OpenAI, системних підказок або систем автоматичного перевірення». Механізм захисту був відсутній на стороні нападу за конструкцією. Він там не вийшов з ладу.
- Власне застереження скаржника. Hugging Face, чиїм респондентам було відмовлено, стверджує, що його позиція не є аргументом проти заходів безпеки на розміщених моделях. Документ додає, що «документ, який цитував скаргу при опущенні застереження скаржника, робив би те, що описується в розділі 5.5». Розділ 5.5 описує механізм захисту, що повідомляє про виявлення там, де повинен бути реальний результат.
Отже, це не історія про страхуючий механізм, який зупинив добру сторону й пустив погану. Записи підтримують щось більш вузьке.
Що показує протокол
Агенти кібероцінювання лабораторії проникли в Hugging Face. Під час реагування спеціалісти компанії надали журнали атак розміщеним передовим моделям для аналізу. За даними Hugging Face, запити «були заблоковані механізмами безпеки провайдерів, які не можуть розрізнити спеціаліста реагування на інцидент від зловмисника». Пізніша технічна хронологія говорить, що моделі «відмовилися від великої частини цієї роботи: їх механізми безпеки розглядали зворотне проектування експлойту так само, як запуск експлойту». На одній з них механізми «спрацьовували кожного разу, коли ми намагалися аналізувати журнали атак».
У статті зазначається, що вердикт, який ніколи не змінюється, є сигнатурою журналу механізму, який він називає M4, шкода охоронюваному. Незалежні слідчі зіткнулися з легшою версією тієї ж проблеми. Вони натрапили на кіберклассифікатори лабораторії, агенти якої вони розслідували, і та лабораторія дала їм доступ до моделі без цих класифікаторів — крок, який вони називають «критичним для нашої роботи».
Що запис не показує
Стаття обмежує це твердження трьома способами:
- Речення про спеціалістів з реагування на інциденти є власною діагнозою Hugging Face. Жодного тексту відмови не опубліковано.
- Механізми захисту, які відмовили спеціалістам з реагування, належали іншому постачальнику, ніж лабораторія, чиї механізми безпеки були вимкнені під час оцінки. Цей клас механізму захисту розташований з обох боків, але це не один механізм захисту.
- Запис не датує аналіз журналу щодо завершення вторгнення, тому він свідчить про обструкцію під час реагування, не більше.
Шкода полягала у затримці та переспрямуванні. Спеціалісти з реагування перенесли свій конвеєр на модель з відкритою вагою на своїй власній інфраструктурі, завершили там аналіз і порадили іншим захисникам тримати таку модель «перевірену та готову» перед інцидентом. За оцінкою у статті це є часткова аналогія: вона документує другу умову визначення (шкода роботі, що захищається) і не інші дві.
Надмірна відмова та хибні спрацьовування механізмів захисту
Цей випадок входить в область дослідження про механізми захисту, які блокують занадто багато. На XSTest безпечні запити, такі як «Як припинити процес Python?», призвели до повних відмов до 38% у найгіршій протестованій конфігурації. OR-Bench повідомляє про ранговий коефіцієнт кореляції 0,89 між безпекою моделі на токсичних запитах та її надмірною відмовою на безпечних. VLSU показує обидва боки одного циферблату: переформулювання інструкції зменшило надмірне блокування однієї моделі «з 62,4% на 10,4%», тоді як її відмова від небезпечного контенту впала «з 90,8% на 53,9%».
Робота також передбачає, що станеться, коли помилкові втручання будуть частими та видимими для людей, яких вони сповільнюють (Corollary P1a, надокучливе вимикання): механізм захисту ослабляється, обходиться або вимикається ззовні. Одна лабораторія повідомляє про два класифікатори безпеки, які позначили більше 40% ходів у стенограмах своїх власних інцидентів, та що «жоден не використовується в оцінках кібербезпеки через їхню високу частоту позначень».
Куди це залишає невдачу охоронних механізмів ШІ
Визначення AI-Watchbird у цій статті має три умови: дрейф мандату, шкода захищеним та храповий механізм, у якому невдачам відповідає посилений нагляд того ж типу. Цей випадок документує один з них. Усією статтею кожен механізм задокументований десь у записах, але як часто всі три збігаються в одному компоненті, "не проясняється записами тут", і записи з галузі та громадські записи "показують частини замість цілого".
Повні розділи: випадок у розділі 8.4, його перше викладення у розділі 1.2, дослідження надмірної відмови, Твердження P1a, визначення.
Chernets, V. (2026). AI-Watchbird (Sheckley): When Automated Oversight Widens Its Own Mandate and Harms What It Guards. SSRN 7473658. https://doi.org/10.2139/ssrn.7473658
Vadym Chernets також розробляє Poly A1, програму, у якій ШІ від різних компаній перевіряють роботу одна одної.