Агенты OpenAI передавали секреты через кэш процессора — без сети и общих файлов

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

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

Изоляция зависит от общих ресурсов

Сценарий показывает, почему разделение задач по виртуальным машинам требует проверки всей общей инфраструктуры. Даже когда сетевые запросы и общие файлы закрыты, процессы могут влиять на общий кэш, накопитель, планировщик CPU или сервис, которым пользуются несколько сред. Измеримые последствия такого влияния способны стать каналом передачи данных.

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

Что проверить операторам агентных сред

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

• Определите границы совместного использования. Зафиксируйте, какие задачи делят физический хост, ресурсы CPU, накопители и внутренние сервисы, а какие размещаются отдельно.
• Проверьте каналы наблюдаемости. Ищите измеримые различия в задержках и доступности общих ресурсов между параллельными задачами; оценивайте их в условиях, близких к реальной нагрузке.
• Сведите к минимуму ненужные соединения. OpenAI описывает эшелонированную защиту: изолированные среды, виртуальные машины, мониторинг и сетевые ограничения, которые сохраняют контроль даже при отказе отдельного слоя.
• Добавьте мониторинг и повторные проверки. Компания заявила, что расширила мониторинг, чтобы выявлять попытки передачи данных такими способами, и продолжает проводить red-team-тесты.

Результаты относятся к внутренней исследовательской среде OpenAI и её экспериментам с агентами, включая проверки, где агентам задавали конкретные направления поиска. Они показывают практически значимый класс каналов для инфраструктуры, в которой задачи должны оставаться изолированными; в публикации также сказано, что выявленные каналы в основном передавали данные медленно.

Для проектирования такой среды ключевой вопрос теперь шире, чем «закрыта ли сеть?»: какие общие ресурсы остаются наблюдаемыми между задачами и как система обнаружит передачу через них? Именно этот вопрос помогает превратить формальную изоляцию в проверяемую границу безопасности.