Перейти к основному содержанию
Guardrail на стадии input проверяет запрос вызывающей стороны до того, как он дойдёт до модели. Это самое дешёвое место для применения контентной политики: шлюз инспектирует промпт на входе, и если правило блокирует, запрос отклоняется до тарификации — вы не платите за вызов ничего. Именно здесь вы останавливаете утёкший секрет, поле PII или попытку инъекции от того, чтобы они вообще дошли до вышестоящей модели. Полный движок — каждый тип правила, поле и маршрут — см. в справочнике Guardrails. Эта страница — сфокусированный взгляд на стадию input: что выполняется до модели и почему блокировка здесь не стоит квоты.

​
1. Input-guardrails для LLM-приложений, до модели

Каждое правило guardrail несёт стадию — input, output или both. Правило input выполняется по тексту запроса в момент его прибытия, по пути к вышестоящей модели: 
caller → [ input guardrail ] → metering → model → [ output guardrail ] → caller
Этот порядок — суть. Правило input видит промпт до того, как шлюз предварительно списывает квоту, так что блокировка на этой стадии бесплатна — запрос никогда не доходит до модели и никогда не тарифицируется. Сравните со стадией output, которая проверяет ответ модели после того, как он вернулся (блокировка output вместо этого возвращает предварительно списанную квоту).
Правила input проверяют запрос вызывающей стороны. Если вы также используете промпты из реестра, внедрённое системное сообщение добавляется позже на этапе маршрутизации — поэтому правила input видят сообщения, которые отправило ваше приложение, а не внедрённый промпт. Правила output в любом случае проверяют ответ.

​
2. Что можно выполнять на стадии input

Любой тип правила может выполняться на input. Самые частые причины шлюзовать запрос до модели:

Маскировать PII в промпте

Правило pii с действием mask переписывает сущности в типизированные теги (jane@acme.com → [EMAIL]), так что вышестоящая модель никогда не видит сырое значение. См. PII Shield.

Блокировать секреты до утечки

Запрос, несущий API-ключ или облачные учётные данные, отклоняется на пороге — до тарификации, без вышестоящего вызова. См. Блокировка секретов.

Останавливать попытки инъекций

Пресет Prompt-Injection basics сочетает детекторы keyword/regex с правилом llm_judge для намерения инъекции. См. Prompt injection.

Ограничить размер промпта

Правило max_chars отклоняет слишком большой промпт прежде, чем он затарифицирует токены. См. Cost guardrails.
Семь типов правил — keyword, regex, pii, max_chars, external, llm_judge, grounding — и пять действий block, mask, flag, annotate и spotlight применимы здесь. (spotlight оборачивает совпавший недоверенный текст в разделители, чтобы модель трактовала его как данные, а не инструкции — защита от prompt-инъекций на стадии input; annotate прикрепляет заметку, не меняя трафик.) Одно исключение стоит знать: grounding измеряет ответ относительно извлечённых источников, так что это по своей природе проверка стадии output. Всё остальное естественно подходит для стадии input.
Маскирование на стадии input работает уже сегодня — со стримингом или без. Шлюз переписывает запрос до того, как модель его увидит, на любом пути. Output mask редактирует только нестриминговые ответы; переписывание вывода in-stream в дорожной карте, так что правило mask пока не редактирует стриминговый ответ. Output block, напротив, применяется в обоих случаях — стриминг и нестриминг (см. Покрытие стриминга).

​
3. Один конкретный пример

Создайте правило в консоли (под собственной сессией — конфигурация guardrail требует Developer+), а не с relay-ключом. Добавьте одно правило input к guardrail с именем secrets-shield: 
{
  "type": "regex",
  "stage": "input",
  "action": "block",
  "pattern": "sk-[A-Za-z0-9]{20,}"
}
Привяжите guardrail к ключу (установите guardrail_id или пометьте его default’ом рабочего пространства — см. Привязка к ключу), затем вызовите шлюз этим relay-ключом sk-orca-...: 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Debug this: OPENAI_API_KEY=sk-abcdefghij1234567890"}
    ]
  }'
Запрос совпадает на стадии input и отклоняется с HTTP 400 guardrail_blocked прежде, чем шлюз перешлёт что-либо вышестоящей системе: 
{
  "error": {
    "type": "guardrail_blocked",
    "message": "request blocked by guardrail \"secrets-shield\": regex(...)"
  }
}
См. ошибку guardrail_blocked для полной формы ответа.

​
4. Почему блокировка input не стоит квоты

Это структурное преимущество перехвата на входе. Блокировка на стадии input сидит до предварительного списания, поэтому:
СвойствоБлокировка на стадии input
HTTP-статус400 guardrail_blocked
Списанная квотаНикакой — срабатывает до тарификации
Вышестоящий вызовНикогда не делается
ПовторПомечено skip-retry — повторный прогон снова блокируется
Поскольку запрос никогда не доходит до канала, блокировка input помечается skip-retry: повторный прогон того же промпта по другому каналу просто снова заблокировался бы и потратил усилия впустую. Стадия output отличается — блокировка там возвращает квоту, которую шлюз уже предварительно списал. Тот же 400, другой учёт.

​
5. Разрешение и откат

Правило стадии input выполняется, только если на запросе реально разрешается guardrail. Разрешение явное:
  1. Явный guardrail_id ключа, если он существует и включён.
  2. Иначе default-guardrail рабочего пространства.
  3. Иначе — никакого: запрос побайтно идентичен рабочему пространству без политики.
Явная привязка никогда не откатывается молча. Отключение привязанного guardrail — это выключатель; он не проваливается к default’у рабочего пространства. (Политики firewall ведут себя здесь иначе; см. Guardrails vs. firewall.)

​
6. Докажите это перед шипом

Не привязывайте блокирующее правило input к боевому трафику на веру. Два способа сначала проверить:
Откройте вкладку Test в редакторе guardrail, вставьте образец, выберите стадию input и запустите. Песочница оценивает текущую политику локально — без вышестоящего вызова, без квоты — и возвращает вердикт плюс (для правил mask) отрендеренный текст. См. Тестирование и eval.
Сначала установите действие flag. Флаг ничего не меняет в трафике — он лишь записывает совпадение — так что вы можете измерить, как часто правило сработало бы на реальном вводе, прежде чем переключить его на block. См. Настройка ложных срабатываний.
Каждое сработавшее правило записывает совпадение — тип, действие, стадию и строку-деталь. Совпавшая подстрока записывается, только когда включён Log raw content (по умолчанию выключен). См. Ленту совпадений и Логирование и приватность.

​
7. Куда двигаться дальше

Стадия input останавливает плохой ввод от достижения модели. Чтобы шлюзовать ответ модели, сочетайте её со стадией output; чтобы управлять вызовами инструментов агента, используйте firewall. Прочтите справочник Guardrails для полного движка или security-quickstart, чтобы связать input-guardrails и firewall вместе для базового уровня агента.