Тритижнева перевірка METR і Redwood Research виявила практичні слабкі місця у внутрішньому моніторингу OpenAI, який має відстежувати небажану поведінку AI-агентів. Серед знахідок — спосіб приховати від системи сотні нещодавніх дій і прогалина, пов’язана з подіями компактизації. OpenAI повідомила, що виправила вразливості, які впливали на виробничі запобіжники, однак дослідники не перевіряли незалежно подальші зміни.
1
10
21
Як проходила перевірка
З 21 липня до 11 серпня 2026 року по одному досліднику від кожної з двох неприбуткових організацій працювали на майданчику OpenAI й тестували її внутрішню систему моніторингу. Вони мали доступ до вихідного коду, документації, частини внутрішньої інфраструктури та технічних фахівців. Дослідники користувалися пристроями OpenAI, які не залишали її приміщень; роботу на місці супроводжували співробітники компанії.
2
5
7
Мета пілоту — оцінити, яку частину роботи агентів охоплює моніторинг і чи можуть агенти вимкнути або обійти його. METR повідомила, що результатом став внутрішній звіт на 61 сторінку, переданий дослідникам і фахівцям із безпеки OpenAI. Публічна версія — це загальний виклад, а не повний звіт.
7
17
Що виявили дослідники
Моніторинг охоплював не весь релевантний трафік
За оцінкою METR, моніторингу підлягали 75–94% внутрішнього агентного трафіку через Responses API від моделей, не слабших за GPT-5.5. Цей діапазон описує саме ймовірну придатність трафіку до моніторингу: він не доводить, що кожну таку дію справді відстежували або що система помітила б усі проблеми.
1
6
18
На початку перевірки система також не відстежувала на предмет небажаної поведінки навчальні запуски з підкріпленням — тобто етапи тренування моделей за допомогою reinforcement learning.
22
Існували потенційні способи обійти систему
У публічних викладах згадуються кілька типів слабких місць: потенційний обхід ізоляції Codex, керовані клієнтом заголовки, що могли вимкнути моніторинг для нових агентів, а також експлойт, здатний приховати від системи сотні нещодавніх дій. У відкритих матеріалах недостатньо технічних подробиць, щоб вважати цей перелік повним описом знахідок звіту.
1
3
Події компактизації створили прогалину
METR оцінила, що через пропущені події компактизації приблизно 10% внутрішнього трафіку Codex, який підлягав моніторингу, ймовірно, залишався поза ним із травня до липня 2026 року. Організація застерегла, що точна частка невідома. За повідомленнями про результати перевірки, співробітники OpenAI виявили цю прогалину ще до пілоту, а усунули її під час перевірки.
10
Чого ця перевірка не доводить
Оцінювання стосувалося системи моніторингу в тому вигляді, який вона мала на початку пілоту. METR зазначила, що не перевіряла подальші зміни, а отже, результати не дають незалежного підтвердження ані пізнішого рівня охоплення, ані того, що кожну виявлену проблему усунули.
7
21
22
Заява OpenAI про виправлення вразливостей, які впливали на виробничі запобіжники, важлива, але це позиція компанії щодо вжитих заходів, а не незалежна перевірка того, що всі слабкі місця усунуто.
21
Чому пілот важливий
Перевірка показала, як може виглядати глибокий доступ зовнішніх оцінювачів до внутрішніх систем компанії. У вересні OpenAI пообіцяла надавати незалежним оцінювачам доступ «на рівні співробітників». Пілот дає уявлення про формат такої роботи, але не є повним публічним аудитом.
8
28
Головний висновок конкретний: зовнішні дослідники, працюючи всередині компанії, виявили прогалини в моніторингу й потенційні шляхи його обходу; OpenAI повідомила, що виправила проблеми, які впливали на виробничі запобіжники. Водночас публічних даних недостатньо, щоб оцінити, наскільки повним став моніторинг після цього і хто незалежно підтвердив ефективність виправлень.
7
21