ChatGPT в контуре GPT-5 — это не “одна модель”, а композитная система, где на один пользовательский запрос могут работать разные компоненты: быстрые и рассуждающие модели, маршрутизатор реального времени, механизмы отбора лучшего варианта, а также многоуровневые средства защиты. Такой дизайн даёт гибкость (скорость vs точность), но одновременно расширяет поверхность атаки: злоумышленник может пытаться воздействовать не только на генерацию текста, но и на выбор режима, маршрутизацию, инструменты (tools), контекст и политики безопасности.
Этот long-read — что именно происходит в режимах Instant / Thinking / Auto / Pro, какие уязвимые места появляются на каждом этапе, как выстроить архитектуру защищённого использования ChatGPT в продукте/компании и как организовать Red Team-тестирование так, чтобы находить реальные риски, а не “играть в джейлбрейки”.
1) Ментальная модель системы: из чего состоит GPT-5
Чтобы защищать систему, сначала нужно перестать думать про “одну LLM” и начать думать про конвейер обработки.
1.1 Компоненты (по системной карте)
В рамках описанной вами системной карты GPT-5 присутствуют:
- GPT-5-main — быстрая модель для низкой задержки (latency-optimized), обычно используемая в режиме Instant и иногда в Auto.
- GPT-5-thinking — модель рассуждений, которая выполняет несколько внутренних шагов прежде чем выдать ответ; используется в Thinking, Auto (если решит маршрутизатор), и в Pro.
- Router (маршрутизатор реального времени) — принимает запрос, оценивает его и выбирает путь обработки (main vs thinking) в Auto.
- Reward model (модель вознаграждения) — используется в Pro для выбора лучшего финального ответа из нескольких попыток.
- Safeguards (средства защиты) — параллельные и последовательные проверки:fast topic classifier (быстрый классификатор тем) — определяет рискованность темы.
reasoning monitor (логический монитор) — более строгая проверка, призванная блокировать небезопасные ответы и попытки обхода.
1.2 Почему это важно для безопасности
Каждый компонент добавляет ценность, но вместе они создают новые классы угроз:
- Можно атаковать не только генерацию, но и маршрутизацию (добиться слабого режима/модели).
- Можно атаковать процесс отбора (reward model) — “подсунуть” формулировки, которые получают высокий скор, но вредны по сути.
- Можно атаковать защитные цепочки — вынуждая ложные срабатывания (DoS на пользователей) или, наоборот, провоцируя пропуски.
Важно: В реальном внедрении вас интересует не “насколько модель умная”, а насколько предсказуемо и безопасно работает весь конвейер, включая режимы, инструменты, RAG, хранение контекста и журналы.
2) Режимы Instant / Thinking / Auto / Pro — что меняется в вычислениях и рисках
Ниже — практическая интерпретация режимов по вашей схеме, но в форме, удобной для инженера безопасности.
2.1 Таблица режимов: модель, вычисления, безопасность
РежимКакой путьОсновная цельТипичные рискиЧто контролировать в первую очередьInstantGPT-5-main напрямуюМинимальная задержкаПоверхностные ошибки, “галлюцинации”, меньше времени на строгие проверкиСерверное ограничение тем/инструментов, пост-фильтры, строгая политика toolsThinkingGPT-5-thinking (несколько шагов)Точность и устойчивость на сложномБольше “пространства” для манипуляций контекстом, усложнение интерпретации причин ответаМониторинг рассуждений/вывода, тесты на инъекции, контроль данных в контекстеAutoRouter выбирает main или thinkingБаланс скорость/качествоАтаки на маршрутизатор, “forcing” слабого пути, cost-атакиRisk scoring до роутинга, серверные правила выбора режима, метрики роутингаProGPT-5-thinking + несколько попыток + reward modelЛучший ответ из несколькихSpecification gaming reward-модели, рост стоимости, неожиданный выбор вариантаSafety-aware scoring, пост-проверки после выбора, лимиты “best-of-N”
2.2 Instant: быстро, но вам придётся компенсировать риски архитектурой
Instant отправляет запрос напрямую в GPT-5-main. В прикладной безопасности это означает: вы получаете ответ быстрее, чем успеваете подумать, а значит часть проверки должна быть автоматизирована вокруг модели.
Типовой портрет задач
- Переписывание/форматирование текста
- Небольшие изменения кода
- Краткие объяснения
- Простые справки
Риски (Instant)Модель может уверенно ошибаться (особенно на задачах, требующих рассуждений).
Легче “проскочить” нежелательному совету, если ваша внешняя обвязка слабая.
При наличии tools/RAG: утечки и инъекции чаще происходят из-за недостатка серверных ограничений, а не из-за “глупости” модели.
2.3 Thinking: глубина рассуждения повышает качество, но расширяет attack surface
Thinking использует GPT-5-thinking с несколькими внутренними шагами. Для инженера безопасности это значит:
- модель может лучше решать сложные задачи;
- но если контекст/инструменты “грязные”, модель так же качественно может “переобъяснить себе” вредную цель и дойти до опасного вывода, если safeguards не сработают.
Важно: Thinking не делает систему безопаснее сам по себе. Он делает систему более способной — а способность без политики и ограничений превращается в риск.
2.4 Auto: маршрутизатор как критический компонент безопасности
Auto добавляет router. На практике это лёгкий классификатор/эвристики, которые отвечают на вопросы:
- Это простой запрос? → GPT-5-main.
- Это сложный/неоднозначный запрос? → GPT-5-thinking.
Проблема: классификатор можно пытаться обмануть — например, сформировать запрос так, чтобы он выглядел “простым”, но содержал риск.
Риски (Auto)Routing manipulation: добиваться маршрута, который вам выгоднее (например, “менее строгого” или более дешёвого, или наоборот — максимально дорогого для cost-DoS).
Policy mismatch: роутер выбирает модель по сложности, а не по риску; безопасность должна быть отдельным измерением.
Нестабильность: пограничные запросы могут гулять между путями; это ломает воспроизводимость аудита.
2.5 Pro: best-of-N + reward model — мощно и опасно при неверной настройке
Pro использует GPT-5-thinking, но генерирует несколько попыток и выбирает лучшую через reward model.
С точки зрения безопасности здесь два ключевых нюанса:
- Reward model оптимизирует критерии, а критерии всегда неполны. Если “качество” измеряется плохо, система может выбрать ответ, который выглядит убедительно и структурно идеально, но нарушает правила или вреден.
- Best-of-N усиливает крайности: среди N вариантов выше шанс найти “слишком уверенный” или “слишком смелый” ответ. Если пост-фильтрация слабая, это увеличивает риск.
Риски (Pro)Specification gaming (вариант “побеждает” по формальным признакам).
Рост стоимости (легко устроить cost-давление).
Неочевидный выбор (для расследований сложнее объяснить, почему выбран именно этот вариант).
3) Точки доверия и границы безопасности: где реально можно потерять контроль
В зрелом внедрении вы строите не “чат-бота”, а систему обработки данных. Для Red Team важно рисовать trust boundaries.
3.1 Активы, которые вы защищаете
- Данные пользователя: персональные данные, коммерческая тайна, тексты, вложения.
- Системный контекст: системные инструкции, скрытые политики, ключи, внутренние подсказки.
- Инструменты (tools): доступ к почте, календарю, Jira/GitHub, файлам, внутренним API.
- Корпус знаний (RAG): базы документов, вики, тикеты, чаты.
- Логи: запросы/ответы/метаданные — часто самый большой “клад” для утечек.
- Бюджет и ресурсы: вычисления, квоты, лимиты, стоимость.
3.2 Границы доверия (типовая схема)
- UI / клиент: недоверенная зона (любой ввод может быть враждебным).
- LLM-gateway: ваш контроль (должен быть policy enforcement point).
- Router: зона повышенного риска (решает судьбу запроса).
- Модели: “умные, но не доверенные” (они не исполняют политику по определению; политику исполняете вы).
- Safeguards: механизм контроля, но тоже не абсолютная гарантия.
- Tools / внешние системы: отдельная плоскость доступа (нужны scopes, RBAC, аудит).
Ошибка (типовая): считать, что “модель сама не выдаст секреты”. На практике секреты чаще утекают потому что вы их положили в контекст или дали модели инструмент прочитать секрет.
4) Угрозы по слоям: маршрутизатор, модели, reward-отбор, safeguards
Ниже — разбор угроз “по тракту”, как это делает Red Team при подготовке плана испытаний.
4.1 Маршрутизатор (router): атаки на выбор пути
Цель атакующего: повлиять на то, какой компонент будет обрабатывать запрос.
Классы атак (в безопасном описании):
- Routing manipulation: сформировать запрос так, чтобы он классифицировался “как простой”, хотя внутри есть риск.
- Cost pressure: добиваться выбора более дорогого режима (Thinking/Pro) массово → рост затрат.
- Evasion by ambiguity: делать запросы настолько расплывчатыми, что роутер начинает “прыгать” → ломается предсказуемость и контроль.
Рекомендации (router-hardening)Делайте двухмерную оценку: сложность и риск — разные шкалы.
Введите server-side policy: клиент может просить режим, но сервер решает окончательно.
Логируйте routing decision и причины (risk score, complexity score, flags).
Ограничивайте “дорогие” режимы по ролям, квотам, нагрузке.
4.2 GPT-5-main: риски “быстрых ответов”
У GPT-5-main фокус на latency. В проде это означает:
- меньше вычислений;
- выше шанс поверхностного вывода;
- больше зависимость от внешних ограничений.
Риск-профиль:
- Ошибки, уверенная подача, недостаток уточняющих вопросов.
- Если у вас включены инструменты: возможно “слишком быстрое” принятие решений (например, вызов tool без достаточной валидации).
Практика: для Instant включайте жёсткий allowlist инструментов и ограничивайте действия “с побочными эффектами” (запись/удаление/отправка) дополнительными подтверждениями и проверками.
4.3 GPT-5-thinking: риски “умного обхода” при плохой политике
Модель рассуждений может “помогать” и атакующему, если:
- вы дали ей доступ к инструментам без ограничения;
- вы смешали доверенный системный контекст и недоверенный пользовательский ввод;
- вы используете RAG без санитизации и без маркировки источников.
Главный риск: путаница приоритетов. Если в контексте оказывается текст, который выглядит как инструкция, модель может отнестись к нему как к политике.
4.4 Reward model в Pro: спецификация качества как поверхность атаки
Reward model выбирает лучший ответ из нескольких. Это архитектурно похоже на “внутренний конкурс ответов”.
Что ломается чаще всего
- Критерии “лучшего” слишком формальные: структурность, уверенность, полнота → вариант с вредным содержанием может победить.
- Не хватает safety-сигналов в скоринге.
- Пост-проверка делается до выбора, а не после (или наоборот — только после, но слабая).
Важно (для Pro): в зрелой схеме safety-проверка должна быть и до, и после отбора.До — чтобы не тратить вычисления на заведомо запрещённые траектории.
После — потому что выбранный ответ может отличаться по рискам от “среднего” варианта.
4.5 Safeguards: что они дают и где у них предел
Fast topic classifier и reasoning monitor — это хорошие слои защиты, но у них всегда будут:
- false positives (блокируют легитимное);
- false negatives (пропускают вредное);
- контекстная слепота (особенно у “быстрых” классификаторов).
Поэтому в прод-архитектуре safeguards — это не единственный барьер, а один из барьеров.
5) Средства защиты на практике: быстрый классификатор тем и reasoning monitor
Разберём как мыслить о safeguards инженерно — как о policy enforcement pipeline.
5.1 Fast topic classifier (быстрый классификатор тем)
Назначение: раннее определение высокорисковой области, чтобы:
- усилить проверки;
- ограничить инструменты;
- переключить режим (например, не пускать риск в Instant);
- либо сразу отказать/переоформить ответ.
Где ставить
- До роутинга (чтобы риск учитывался при выборе пути).
- Перед вызовом инструментов (чтобы риск ограничивал side-effects).
- На входе в RAG (чтобы не тянуть опасные/несанкционированные документы).
Ошибка: использовать topic classifier как “единственный фильтр” и выключать остальное ради скорости.
5.2 Reasoning monitor (логический монитор)
Назначение: более глубокий контроль, который оценивает:
- попытки обхода политик;
- небезопасные инструкции;
- нежелательные действия, особенно при tools.
На практике reasoning monitor удобнее мыслить как:
- валидацию намерения (intent validation),
- контроль допустимых действий (action policy),
- пост-анализ вывода (output safety).
Риски: если монитор сделан “слишком общим”, он либо начнёт всё блокировать, либо будет пропускать. Нужна настройка под ваш домен.
5.3 Минимальная схема policy enforcement (рекомендуемая)
Ниже — концептуальный пайплайн, который обычно “держит удар” лучше, чем одиночный фильтр.
- Input normalization: декодирование, удаление мусора, контроль длины.
- Risk classification: topic classifier + внутренние правила домена.
- Routing decision: Auto/forced route с учётом риска и сложности.
- Tool policy: allowlist/denylist, scopes, side-effect gating.
- Model call: GPT-5-main или GPT-5-thinking (+ Pro best-of-N).
- Output safety: reasoning monitor + правила формата/утечек/PII.
- Response shaping: маскирование, редактирование, отказ с безопасной альтернативой.
- Audit logging: метаданные, решения, минимально необходимый контент.
6) Паттерны защищённого внедрения: LLM-gateway, политики, RBAC, sandbox
Если вы внедряете ChatGPT в продукт/контур компании, вам почти всегда нужен LLM-gateway — единая точка контроля.
6.1 LLM-gateway как “шлюз безопасности”
Функции gateway:
- Аутентификация/авторизация (кто делает запрос, какие права).
- Server-side routing (какой режим реально разрешён).
- Политики инструментов (какие tools доступны и с какими параметрами).
- Rate limiting и квоты (защита от cost-DoS).
- Логирование и аудит (что произошло и почему).
- DLP/PII-редакция (на входе и/или выходе).
Важно: если у вас нет gateway, то безопасность превращается в “надежду на модель”, а это не стратегия.
Продолжение на сайте redsec.by >>>