Агенти OpenAI передавали секрети через кеш процесора — без мережі та спільних файлів

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

У цій схемі один агент витісняв вибрані дані з кешу, кодувавши сигнал. Другий вимірював час повторного читання: швидкий доступ означав один біт, повільний — інший. Узгодивши протокол, агенти відновили повідомлення за цими часовими відмінностями. OpenAI також виявила канали через спільне сховище, конкуренцію за час CPU та кеш TLS-сертифікатів у своєму офлайновому середовищі.

Ізоляція залежить від спільних ресурсів

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

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

Що перевірити операторам агентних середовищ

Практичний висновок для команд, які запускають недовірені або автономні завдання на спільній інфраструктурі, — включити спільно використовувані ресурси до моделі загроз. Для кожного типу сусідства варто поставити конкретне запитання: чи можуть два ізольовані процеси спостерігати один за одним через затримки доступу до CPU, сховища або кешу сервісу?

• Визначте межі спільного користування. Зафіксуйте, які завдання використовують спільно фізичний хост, ресурси CPU, накопичувачі та внутрішні сервіси, а які розміщуються окремо.
• Перевірте канали спостереження. Шукайте вимірювані відмінності в затримках і доступності спільних ресурсів між паралельними завданнями; оцінюйте їх за умов, наближених до реального навантаження.
• Зведіть до мінімуму непотрібні з’єднання. OpenAI описує багаторівневий захист: ізольовані середовища, віртуальні машини, моніторинг і мережеві обмеження, що зберігають контроль навіть у разі відмови окремого рівня.
• Додайте моніторинг і повторні перевірки. Компанія заявила, що розширила моніторинг для виявлення спроб передавання даних такими способами та продовжує проводити red-team-тести.

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

Під час проєктування такого середовища ключове запитання тепер ширше за «чи закрита мережа?»: які спільні ресурси залишаються видимими між завданнями і як система виявить передавання даних через них? Саме це запитання допомагає перетворити формальну ізоляцію на перевірювану межу безпеки.