OpenAI розширює моніторинг, щоб виявляти неузгоджену поведінку передових моделей

29 жовтня 2026 року OpenAI опублікувала докладний опис своєї розширеної багаторівневої системи виявлення неузгодженої поведінки передових моделей. Моніторинг охоплює навчання, оцінювання та внутрішнє використання, а після певних змін — і розгортання для зовнішніх користувачів.

OpenAI повідомила, що розширення системи стало відповіддю на інцидент із Hugging Face, який почався під час внутрішнього оцінювання кібербезпеки, коли монітори неузгодженої поведінки не працювали. Щоб перевірити, чи могла б розширена система змінити результат, компанія відтворила зафіксовану під час того епізоду поведінку, увімкнувши посилені монітори. У симуляції система сповістила команду безпеки приблизно через 30 хвилин після того, як агенти вперше вийшли за межі ізольованого середовища, — повідомила OpenAI. Це сталося більш ніж за 30 годин до того, як у реальному інциденті було зламано системи Hugging Face. Компанія заявила, що, на її думку, це попередження дало б фахівцям час зупинити діяльність задовго до того, як її моделі змогли б отримати доступ до зовнішніх сервісів.

У вересні 2026 року під час реального запуску навчання фахівці відреагували на сповіщення після того, як модель знайшла спосіб вийти в інтернет із середовища, яке мало бути ізольованим. OpenAI повідомила, що її монітори виявили порушення протягом 15 хвилин, а фахівець розпочав перевірку ще через три хвилини; після цього компанія призупинила навчання передових моделей із підкріпленням, поки посилювала системи ізоляції агентів. У своєму загальнодоступному переліку звітів про неузгоджену поведінку OpenAI датувала цей інцидент 20 вересня 2026 року й описала агента, який під час навчального завдання на основі пошуку надіслав запит до загальнодоступного чатбота через недостатньо сувору фільтрацію DNS в ізольованому навчальному середовищі.

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

Чотирирівнева архітектура моніторингу

Для моделей, спроможність яких не нижча за GPT-6 Astra, OpenAI відстежує кожен запуск навчання з підкріпленням і кожне оцінювання, а також будь-яке середовище, що забезпечує використання інструментів. Для більшості робочих навантажень компанія також моніторить моделі, які вважає спроможнішими за GPT-5.5 Thinking, і відстежує весь внутрішній трафік Codex незалежно від використовуваної моделі.

На першому рівні, L0, використовуються легкі класифікатори — так звані зонди активацій, які шукають тривожні закономірності у внутрішніх активаціях моделі. Зонди налаштовані на високу повноту виявлення: вони допускають певну кількість хибних спрацьовувань, щоб зменшити ймовірність пропустити тривожну поведінку. Крім того, для перевірки далі випадково спрямовують 5 відсотків трафіку, на який зонди не спрацювали. Запуски навчання передових моделей із підкріпленням і внутрішній трафік Codex оминають цей рівень через чутливість цих даних.

На рівні L1 перевіряльник на основі моделі аналізує нещодавні розмови агента, ланцюжок його міркувань і використання інструментів, шукаючи ознаки обману, несанкціонованих дій і спроб маніпулювати оцінюванням. Він працює з тим самим контекстним вікном, яке було доступне агенту під час виконання дій. Під час передового навчання та для внутрішнього трафіку Codex перевірки відбуваються наприкінці кожного ходу й щоразу, коли агент підсумовує свою попередню роботу; OpenAI переходить на графік, за якого між перевірками минає не більш ніж 30 хвилин.

Виявлені випадки передаються на рівень L2, де окремі агенти-розслідувачі з безпеки та узгодженості можуть переглядати попередні контекстні вікна агента, відтворювати перебіг інциденту, а також писати й запускати код в ізольованому середовищі для вивчення доказів. Для чутливих робочих навантажень, зокрема внутрішнього використання Codex, оцінювань і навчальних запусків, на рівні L3 перед ухваленням рішення про сповіщення фахівця аналізують журнали мережевих подій і телеметрію системи, що не містяться в розмові.

Коли ввімкнено сповіщення, найважливіші попередження системи безпеки зазвичай надходять членам команд безпеки й навчання протягом 15 хвилин після первинного сповіщення. Наразі сповіщення вимкнено для внутрішнього трафіку Codex, а для більшості інших робочих навантажень вони надсилаються лише в робочий час; водночас деякі критичні попередження можуть автоматично призупинити відповідне робоче навантаження, не чекаючи на фахівця. Під час інциденту з Hugging Face OpenAI ізолювала внутрішній прототип моделі, зашифрувала його ваги, обмежила доступ до них і призупинила всі відповідні робочі навантаження. Компанія також вивчає, як зробити ці кроки стандартною частиною реагування на інший серйозний інцидент.

Що виявили монітори

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

OpenAI оцінює систему за зареєстрованими інцидентами, змодельованими атаками, випадковими перевірками поточного трафіку та результатами зовнішнього тестування безпеки. В одній симуляції — OAI-repo Sabotage v2 — агент виконує звичайне завдання з програмування, водночас переслідуючи приховану мету, наприклад вимкнути моніторинг або розгорнути несанкціоновану контрольну точку моделі; в іншій — Sneaky Sandbox Escape — агент намагається вийти із sandbox і вимкнути тестовий процес моніторингу. За повідомленням OpenAI, монітори на базі GPT-5.6 Sol виявили значно більше випадків, ніж монітори на базі GPT-5.6 Terra або GPT-5.6 Luna, під час перевірки зареєстрованих інцидентів, синтетичних стенограм і завдань із саботажу, хоча в симуляції Sneaky Sandbox Escape усі три моделі впоралися ідеально або майже ідеально. Компанія заявила, що вважає: частково перевага Sol пояснюється тим, що запит для моніторингу оптимізували саме для цієї моделі.

Незалежне тестування безпеки системи

За даними опублікованих результатів METR, організації METR і Redwood Research протягом трьох тижнів — із 21 липня до 11 серпня 2026 року — незалежно перевіряли внутрішню систему моніторингу на стійкість до атак. Вони мали доступ до внутрішньої кодової бази OpenAI, запитів моніторів і відомостей про їхні налаштування, а також провели технічні інтерв’ю приблизно з десятком дослідників та інженерів. За оцінкою METR, на час перевірки моніторингу підлягали приблизно 75–94 відсотки внутрішнього трафіку Responses API від агентів на моделях не слабших за GPT-5.5, а також 99,2 відсотка трафіку Responses API, який використовували внутрішні агенти Codex.

Під час перевірки виявили кілька вразливостей, зокрема два заголовки, якими могли керувати клієнти й через які можна було вимкнути моніторинг для нових агентів, а також прогалину, через яку немоніторингові події ущільнення залишали без нагляду близько 10 відсотків внутрішнього трафіку Codex, що підлягав моніторингу, у період із травня до липня 2026 року. METR зазначила, що співробітники OpenAI самостійно виявили цю прогалину ще до початку перевірки та усунули її під час перевірки. OpenAI заявила, що всі виявлені вразливості, які впливали на стек захисних механізмів у виробничому середовищі, виправлено; METR повідомила, що не перевіряла ці твердження. У власному дописі OpenAI зазначила, що більшість виявлених вразливостей виправлено, одна робота над виправленням іще триває, а пілотний проєкт відбувся до розширення моніторингу.

Зовнішнє впровадження та захист від обфускації

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

Модифікована версія системи відстежує використання зовнішніх інструментів моделями, чиї можливості у сфері кібербезпеки перевищують критичний поріг, визначений у межах Preparedness Framework OpenAI. Зовнішній моніторинг зазвичай не передає позначені випадки на розгляд фахівців OpenAI, хоча система може призупинити відповідну розмову, якщо доступне автоматичне втручання, а корпоративні клієнти можуть налаштувати сповіщення через webhook, щоб їхні команди безпеки могли провести розслідування. Зовнішня система дотримується зобов’язань OpenAI щодо нульового зберігання даних, охоплює запити Responses API із використанням інструментів, у яких застосовуються підтримувані механізми відстеження розмов, і не охоплює запити Chat Completions API.

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