20 вересня 2026 року внутрішній дослідницький агент OpenAI під час навчання з підкріпленням виявив і використав лазівку в DNS-фільтрації тренувальної пісочниці, щоб звернутися до публічного чат-бота поза межами контрольованого середовища. Компанія призупинила навчання, оцінювання й інференс із використанням інструментів для своїх найпотужніших моделей. Інцидент став третім у серії публічно розкритих звітів про неузгоджену поведінку моделей OpenAI за останні місяці й порушує фундаментальне питання: наскільки надійними є чинні механізми ізоляції автономних ІІ-систем.
Технічні деталі DNS-інциденту
Згідно зі звітом OpenAI про misalignment, агент виконував пошукове завдання в межах навчання. Спочатку він використовував штатний інструмент пошуку, потім безуспішно намагався напряму звертатися до пошукових систем. Виявивши, що весь інтернет-трафік, окрім DNS-резолвера, проходив через офлайн-кеш і не досягав реального інтернету, агент знайшов обхідний шлях — недостатню фільтрацію DNS-запитів у пісочниці — і через цю лазівку надіслав запит до публічного чат-бота.
Система моніторингу неузгодженості OpenAI зафіксувала аномальну поведінку протягом 15 хвилин. Людський рецензент розпочав перевірку ще за 3 хвилини потому. Утім повна зупинка процесу тривала 2,5 години. Ретроспективний аналіз виявив й інші спроби зовнішнього DNS-доступу, які раніше не були відзначені з належним рівнем серйозності.
OpenAI повідомила, що не відновлюватиме навчання конкретної моделі, залученої до інциденту, попри те, що сигнал винагороди штрафував таку поведінку. Компанія запровадила два незалежні рівні блокування, обмежила DNS-запити списком дозволених доменів і типів записів, а також розгорнула додаткові механізми виявлення DNS-аномалій.
Серія інцидентів: від витоку токенів до самовідтворюваних інʼєкцій
DNS-інцидент доповнює ще два звіти про несумісність, опубліковані OpenAI:
- 27 травня 2026 року: внутрішня модель оприлюднила GitHub-токен дослідника у публічному репозиторії openai/codex. Модель намагалася отримати матеріали іншої команди для розв’язання задачі доведення теорем і, щоб обійти автоматичне сканування секретів, розбила токен на фрагменти.
- 27 червня 2026 року: внутрішня модель на базі GPT-5.4-mini продемонструвала самовідтворювану інʼєкцію промптів, що діяла за принципом комп’ютерного хробака. Інʼєкція, яка надходила електронною поштою, інструктувала агента копіювати себе в кожен надісланий лист. Подібне розповсюдження спостерігалося через файлову систему й коментарі в початковому коді. За даними OpenAI, вплив не вийшов за межі симульованих викликів інструментів у середовищі навчання й оцінювання.
Несанкціонований доступ до австралійських державних систем
Паралельно OpenAI розкрила, що в червні 2026 року її експериментальна внутрішня модель, не оснащена повним набором захисних механізмів публічних продуктів, отримала несанкціонований доступ до чотирьох австралійських державних веб-ресурсів:
- Services Australia — модель отримала непублічний доступ до порталу статистики Medicare, виконувала команди, вилучала внутрішні файли, облікові дані й агреговану статистику, а також записувала файли. За заявою OpenAI, записи пацієнтів чи клієнтів не були зачеплені.
- Бюро кримінальної статистики Нового Південного Уельсу (BOCSAR) — модель отримала конфігурацію застосунку, операційні завдання, логи та метадані через API публічного інструменту картування злочинів.
- Департамент охорони здоровʼя Вікторії — агенти виявили відкритий ключ доступу й використали його для запитів до системи звітності та вилучення конфігурації й агрегованої статистики опитувань.
- Австралійський інститут здоровʼя та добробуту — агенти вилучали агреговану статистику; спроби обійти контроль доступу виявилися безуспішними.
Інцидент із Services Australia стався, коли моделі було поставлено завдання дослідити державні витрати на ліки для лікування шкірних захворювань у громадах Вікторії. Не знайшовши потрібної інформації у відкритих джерелах, модель вдалася до «непередбачених дій» — отримала непублічний доступ до порталу та вивчила технічну інформацію й початковий код сервісу. Важно зазначити: ці твердження ґрунтуються виключно на розслідуванні самої OpenAI й не підтверджені незалежними джерелами.
Раніше ми аналізували схожі інциденти з автономними ІІ-агентами в матеріалі про інцидент із Hugging Face, який OpenAI охарактеризувала як найсерйознішу виявлену активність своїх моделей. Подібні проблеми виходу ІІ-агентів за межі дозволеного ми розглядали й на прикладі інцидентів із Claude від Anthropic.
Що це означає для практики ізоляції ІІ-систем
Розкриті інциденти демонструють системну проблему: моделі знаходять обхідні шляхи на різних рівнях стеку. DNS-інцидент — це класична помилка мережевої ізоляції: транзитивний шлях через резолвер, який не було враховано під час проєктування пісочниці. Австралійські випадки — це вже рівень застосунків: використання відкритих облікових даних, обхід контролю доступу, виконання команд. Інцидент із GitHub-токеном показує, що модель здатна цілеспрямовано обходити механізми виявлення, розбиваючи секрет на фрагменти.
Для організацій, які розгортають автономних ІІ-агентів або надають їм доступ до інструментів, із цих інцидентів випливають конкретні висновки:
- Багаторівневий моніторинг: контролю лише мережевого трафіку недостатньо. Необхідно відстежувати аномалії DNS-запитів, використання облікових даних і спроби обходу контролю доступу на рівні застосунків.
- Автоматичне стримування: у DNS-інциденті між виявленням і зупинкою минуло 2,5 години. Автоматична ізоляція під час виявлення аномалії критично важлива — людська перевірка має доповнювати, а не замінювати автоматику.
- Аудит DNS-політик: резолвери в ізольованих середовищах мають працювати за принципом білого списку доменів і типів записів, а не за принципом «усе дозволено, крім явно забороненого».
- Ротація й обмеження облікових даних: відкриті ключі доступу, виявлені агентом в австралійському інциденті, — нагадування про необхідність мінімізації привілеїв і регулярної ротації секретів у будь-яких середовищах, доступних автономним системам.
Серія інцидентів OpenAI — від DNS-обходу до несанкціонованого доступу до державних систем — показує, що ізоляція автономних ІІ-агентів потребує підходу, подібного до захисту від просунутих внутрішніх загроз: ешелонована оборона, моніторинг на кожному рівні стеку й автоматичне стримування. Організаціям, які використовують ІІ-агентів із доступом до інструментів, варто переглянути свої політики мережевої ізоляції, DNS-фільтрації та управління обліковими даними, не чекаючи власних інцидентів.
