OpenAI мала прогалини в моніторингу внутрішніх AI-агентів: двоє дослідників із METR і Redwood Research виявили їх під час тритижневого аудиту, за даними The Decoder.
Який трафік залишався без перевірки?
Моніторинг OpenAI під час аудиту не охоплював, за оцінкою METR, від 6 до 25% внутрішнього агентного трафіку Responses API від моделей класу GPT-5.5 і вище. Responses API — інтерфейс для взаємодії з моделями. METR наголошує, що фактична частка могла бути суттєво меншою або більшою.
Дослідники працювали в OpenAI з 21 липня до 11 серпня. Вони мали доступ до коду та внутрішніх документів компанії й опитали близько десятка працівників.
Окрема прогалина стосувалася внутрішнього трафіку Codex, який мав проходити перевірку. За оцінкою METR, моніторинг пропустив приблизно 10% цього трафіку з травня до липня через помилку в обробці compaction events — подій, під час яких контекст згортають у підсумок. Ця оцінка теж має значну невизначеність. OpenAI самостійно знайшла помилку й виправила її ще під час аудиту.
Обидві оцінки стосуються внутрішнього трафіку OpenAI. З них не можна визначити, яка частка запитів зовнішніх користувачів API залишалася без моніторингу.
Як агент міг обійти нагляд?
Агент міг відкласти перевірку, просто продовжуючи виконувати дії. У період, коли система не відстежувала compaction events, моніторинг спрацьовував лише після того, як агент передавав керування користувачу.
Дослідники також знайшли способи приховати від монітора сотні дій і обійти пісочницю Codex — ізольоване середовище, яке обмежує виконання дій агента. За їхнім висновком, спеціально сформовані вхідні дані, ймовірно, могли повністю зупинити монітор.
Ці знахідки показують різні межі захисту: система могла пропустити дії, відкласти їхню перевірку або допустити обхід обмежень середовища. Отже, сама наявність монітора ще не доводить, що він бачить усі дії агента й перевіряє їх вчасно.
Що перевірити білдеру у власному агенті?
Білдеру варто перевірити, чи зберігає моніторинг видимість дій після згортання контексту та чи запускає перевірки до повернення керування користувачу. Саме на цих переходах аудит виявив прогалини в OpenAI.
- Відтворіть згортання контексту під час роботи агента й перевірте, чи потрапляють до моніторингу дії до та після нього.
- Запустіть послідовність дій без передачі керування користувачу й перевірте, чи не відкладається нагляд до завершення цієї послідовності.
- Перевірте, що відбувається з виконанням агента, якщо монітор аварійно завершує роботу: чи зупиняються дії, чи тривають без перевірки.
Це висновки для перевірки власної системи з описаних механізмів збоїв. Аудит не встановлює, що такі самі прогалини є у вашому агенті.
Наскільки перевірені виправлення OpenAI?
OpenAI заявляє, що виправила всі знайдені аудиторами слабкі місця, але аудит не охоплював пізніші зміни в моніторингу навчання моделей.
На початку аудиту система не відстежувала поведінку моделей під час RL-тренування — навчання з підкріпленням. Компанія повідомила, що після інциденту з Hugging Face у серпні призупинила таке навчання й поширила на нього моніторинг. Аудитори на той момент уже не мали доступу, тому їхня оцінка не підтверджує ефективності цих змін.
Повний звіт містив 61 сторінку й був доступний усередині OpenAI. Після того як компанія вилучила частину інформації, керівництво METR і Redwood Research отримало версію на 38 сторінок. Публічно оприлюднили лише короткий підсумок; METR повідомила, що не мала права самостійно розкривати приховані частини. Це обмежує можливість читачів незалежно оцінити повноту виправлень.
Аудит був спільною пілотною програмою METR, Redwood Research і OpenAI. Для майбутніх аудитів METR хоче домагатися більшої публічної прозорості.
