Инженер OpenAI вайбкодил шпионский жучок — и попал под следствие ФБР

Вайбкодинг опасность шпион OpenAI ФБР показывает на одном громком примере: код, собранный через нейросеть, может быстро превратиться из игрушки в устройство наблюдения, если человек не проверяет его назначение, разрешения и последствия. The Decoder рассказал о случае с инженером OpenAI, который якобы вайбкодил шпионский жучок и оказался связан с расследованием ФБР. Я, Арина Михална, разложу здесь не сплетню про конкретного человека, а главный урок: ИИ ускоряет сборку, но не принимает за тебя юридические и этические решения.

Что известно о случае с инженером OpenAI

The Decoder вынес в заголовок формулировку с оговоркой alleged, то есть речь идёт об утверждении, а не о судебном решении, которое можно пересказать как установленный факт. По публикации, инженер OpenAI использовал аккаунт своей жены в чат-боте, чтобы с помощью вайбкодинга создать устройство наблюдения. Материал также связывает историю с расследованием ФБР.

На этом месте многие уже мысленно открывают попкорн. Но аккуратный разбор выглядит скучнее и полезнее: есть публикация источника, есть описанный в ней эпизод, а есть детали, которые нельзя додумывать за журналиста. Мы не знаем из переданных материалов точную конструкцию устройства, его возможности, мотивы разработчика и процессуальный статус дела.

Это не мелкая придирка к словам. В новостях про ИИ очень легко превратить «сообщается о расследовании» в «ФБР доказало преступление». А потом такой текст начинает жить собственной жизнью.

The Decoder здесь важен как первичный источник этой конкретной истории. Официальная документация OpenAI Codex подтверждает только существование инструмента для работы с кодом. Она не подтверждает детали описанного инцидента и не связывает документацию с действиями конкретного инженера.

Почему вайбкодинг быстро доходит до опасной зоны

Вайбкодинг выглядит почти магически. Ты описываешь идею обычными словами, нейросеть пишет файлы, исправляет ошибки, объясняет команды. Через вечер уже есть работающий прототип. Я сама видела, как человек радуется первой кнопке в приложении, а потом обнаруживает, что вместе с кнопкой проект получил ещё десяток непонятных зависимостей. Радость была короткой, зато папка node_modules пережила многое.

Проблема не в том, что модель пишет код. Проблема в скорости и масштабе доступа.

Обычный скрипт может:

• отправлять данные на внешний сервер;
• читать файлы в выбранной папке;
• обращаться к камере, микрофону или геолокации;
• запускать системные команды;
• хранить ключи и пароли в открытом виде;
• подключать сторонние библиотеки с неизвестным поведением.

Человек, который понимает код, хотя бы знает, где искать такие места. Новичок часто смотрит на результат: «оно включилось, значит работает». Но работающий код не равен безопасному коду.

Именно поэтому история с предполагаемым устройством наблюдения бьёт не только по OpenAI. Она показывает неприятную вещь: технический барьер для создания работающего прототипа стал ниже, а барьер ответственности никуда не делся.

Что проверить перед запуском кода

Минимальная проверка занимает меньше времени, чем потом искать, куда ушли данные. Держи три слоя.

1. Разрешения

Посмотри, к чему обращается программа:

Зона риска	Что искать в проекте	Почему это важно
Микрофон и камера	вызовы устройств, запись аудио и видео	программа может собирать данные без ожидаемого сценария
Сеть	HTTP-запросы, веб-сокеты, неизвестные домены	данные могут уходить наружу
Файлы	чтение каталогов, архивов и документов	агент может получить лишнее
Системные команды	запуск shell, PowerShell или терминальных команд	ошибка затронет систему, а не только проект
Секреты	токены, ключи, пароли в коде	доступ можно случайно отправить в репозиторий

Если нейросеть добавила такой блок, попроси её объяснить каждую строку. Не «проверь, что всё безопасно», а конкретно: какие данные читаются, куда уходят и кто может вызвать функцию.

2. Зависимости

Сгенерированный проект может подтянуть библиотеки, которые ты не просил. Открой файл зависимостей и выясни:

• зачем нужен каждый пакет;
• откуда он устанавливается;
• какие разрешения получает;
• можно ли убрать его без потери основной функции.

Тут пригодится отдельная проверка на prompt injection. Если агент читает README, сайт или внешний документ, текст внутри источника может попытаться изменить его поведение. Я подробно разбирала этот класс атак в материале про prompt injection и защиту ИИ-агентов.

3. Среда запуска

Первый запуск делай не на рабочем ноутбуке с фотографиями, документами и сохранёнными сессиями. Нужна отдельная папка, тестовый аккаунт и минимальные права. Для проекта, который работает с устройствами, лучше добавить физический индикатор включения записи и кнопку полного отключения.

Это не паранойя. В новостях уже были случаи, когда агенты получали слишком широкий доступ к проектам и репозиториям. Например, The Verge описывал атаку, которая дошла до GitHub-репозиториев OpenAI через Claude. Это другой сценарий, но принцип тот же: агентная система может сделать больше, чем человек ожидал.

Где заканчивается прототип и начинается ответственность

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

Нейросеть не может заменить ответ на эти вопросы. Она может написать функцию записи звука. Но она не знает автоматически:

• согласны ли люди на запись;
• можно ли размещать устройство в конкретном месте;
• сколько времени разрешено хранить данные;
• кто получит доступ к архиву;
• что делать при утечке;
• не нарушает ли проект правила организации или закон.

Именно здесь вайбкодинг становится опасным не из-за «злого ИИ», а из-за человеческой привычки нажимать Enter, пока всё собирается.

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

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

Что эта история меняет для обычного вайбкодера

Не нужно после новости удалять все нейросети и возвращаться к печатной машинке. Но доверять коду только потому, что его написала известная модель, тоже нельзя.

Держи рабочий порядок:

1. Опиши задачу и ограничения до генерации кода.
2. Попроси модель перечислить все доступы и внешние запросы.
3. Запусти проект в отдельной среде с тестовыми данными.
4. Проверь файлы зависимостей и команды установки.
5. Отключи всё, что не нужно для основной функции.
6. Перед публикацией пройди код вручную или отдай его специалисту на ревью.

Это скучная часть. Зато именно она отделяет «собрал за вечер» от «случайно сделал устройство для наблюдения и теперь объясняю его происхождение следователю».

Арина Михална постоянно говорит о скорости ИИ, но скорость имеет смысл только там, где ты понимаешь, чем рискуешь. Сгенерировать больше кода легко. Сгенерировать меньше проблем, увы, пока приходится самому.

По материалам: публикация The Decoder о предполагаемом устройстве наблюдения, официальная документация OpenAI Codex, материал The Verge об атаке на GitHub-репозитории OpenAI.

Читайте также

• OpenAI Astra: киберугрозы и риски ИИ-агентов
• OpenAI замедлила развитие моделей что это значит?
• Агент OpenAI взломал систему: что дальше
• На портале «Мастерская нейросетей»: ИИ-агенты для бизнеса: автоматизация Claude против OpenAI Presence в 2026

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