Перейти к основному содержанию
Когда вам нужно замаскировать чувствительные данные, которые несёт llm-промпт — emails, номера карт, национальные ID, секреты — шлюз переписывает каждое совпадение на месте до того, как модель его увидит. Замаскированное значение становится типизированным тегом (jane@acme.com → [EMAIL]), так что модель по-прежнему читает связный промпт, а сырое значение никогда не покидает ваше рабочее пространство. Эта страница — сфокусированный взгляд на то, что рендерит маскирование, как изменить тег и как замаскировать одни сущности, блокируя другие, на одном правиле. Полный движок — каждый тип правила, стадия и маршрут — см. в справочнике Guardrails, а для маскирования на запросе конкретно — Правила стадии input.

​
1. Маскируйте чувствительные данные llm-промптов типизированными тегами

Правило pii с действием mask детектирует сущность и заменяет каждое совпадение типизированным тегом редактирования — меткой в верхнем регистре в скобках, которая называет, что было удалено, не раскрывая значения:
СущностьОтрендеренный тег
email[EMAIL]
credit_card[CREDIT_CARD]
ssn[SSN]
Полный набор встроенных детекторов — email, phone, credit_card, ssn, ip, iban, mac_address, jwt, aws_access_key, api_key_openai, bitcoin_address, плюс региональные jp_mynumber, kr_rrn и cn_resident_id — каждый рендерит свой собственный тег в скобках ([PHONE], [IBAN], [JP_MYNUMBER] и так далее). Тег детерминирован: одна и та же сущность всегда рендерит одну и ту же метку, так что нижестоящие промпты остаются стабильными, а ваши логи читаются чисто.
Типизированные теги бьют общий [REDACTED] для качества модели. Модель по-прежнему знает, что смотрит на email против номера аккаунта против номера телефона, так что может продолжать рассуждать о форме данных — «reply to [EMAIL]» остаётся выполнимой инструкцией — никогда не держа реальное значение.
Маскирование input полностью живое — шлюз переписывает промпт до того, как он дойдёт до модели, со стримингом или без. Маскирование output живо на нестриминговых ответах тоже: правило mask на стадии output переписывает завершение до того, как оно вернётся. Только маскирование стримингового вывода в дорожной карте; на стримированном ответе предпочитайте block на стадии output. См. Покрытие стриминга для точной матрицы стадии/потока.

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

Создайте правило в консоли под собственной сессией — конфигурация guardrail требует Developer+, а не relay-ключа. Добавьте одно правило pii к guardrail с именем pii-shield: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ssn"]
}
Привяжите его к ключу (установите 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": "Reply to jane@acme.com about her SSN 123-45-6789"}
    ]
  }'
Шлюз переписывает промпт в «Reply to [EMAIL] about her SSN [SSN]» перед пересылкой. Вышестоящая модель никогда не видит адрес или номер. Сначала докажите точный рендеринг во вкладке Test редактора (без вышестоящего вызова, без квоты) — см. Тестирование и eval.

​
3. Переопределите тег через mask_with

Встроенные сущности рендерят фиксированный тег. Пользовательские сущности — ваши собственные regex-детекторы, наслоённые поверх встроенного набора — позволяют задать текст замены самостоятельно через mask_with: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "custom_entities": [
    {
      "name": "employee_id",
      "pattern": "EMP-[0-9]{6}",
      "mask_with": "[STAFF_ID]"
    }
  ]
}
mask_with — это дословная строка замены для совпадений этой сущности. EMP-004217 становится [STAFF_ID]. Оставьте его пустым, и совпадение рендерит тег по умолчанию [<UPPERCASE_NAME>] — здесь [EMPLOYEE_ID] — так что пользовательский детектор всегда производит читаемое типизированное редактирование даже без переопределения.
name (строчные ASCII / цифры / подчёркивание, должно начинаться с буквы), pattern (регулярное выражение Go RE2 — линейное время, без обратных ссылок), опциональная checksum (luhn валидирует числа в форме карт) и опциональная mask_with. До 25 пользовательских сущностей на правило — каждая это скан по всему тексту, так что лимит держит горячий путь линейным. См. Пользовательские сущности PII.
name попадает в журналы аудита и ленту Matches без кавычек, так что держите его в строчных ASCII-буквах, цифрах и подчёркиваниях, начиная с буквы (например, employee_id, internal_ticket). Валидатор отклоняет всё остальное.

​
4. Маскируйте одни сущности, блокируйте другие — entity_actions

Одно правило pii может применять разные действия к разным сущностям через entity_actions, вместо стопки трёх перекрывающихся правил. Классическая форма: маскировать низкочувствительные контактные данные, но блокировать высокочувствительные поля целиком. 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
Здесь email, phone и ip следуют верхнеуровневому mask правила и рендерят [EMAIL] / [PHONE] / [IP]; совпадение credit_card или ssn вместо этого блокирует весь запрос с HTTP 400 guardrail_blocked.
ПолеПравило
КлючиДолжны быть сущностью, объявленной на правиле (встроенной или пользовательской).
Значенияblock, mask, flag или annotate.
Заблокированный запрос не стоит квоты — блокировка на стадии input срабатывает до тарификации. Замаскированный запрос проходит с очищенным текстом. Так что одно правило может тихо редактировать рутинные поля и жёстко останавливать регулируемые, с единственной привязкой и без изменения приложения.

​
5. Mask против block против flag

Маскирование — одно из действий, которое может принять правило (или переопределение по сущности). Выбирайте по тому, насколько вы хотите потревожить трафик:

mask

Отредактировать совпадение в типизированный тег и пропустить запрос с очищенным текстом. Модель никогда не видит сырое значение.

block

Отклонить весь запрос с HTTP 400 guardrail_blocked. Ничего не доходит до модели. Используйте для данных, которые никогда не должны проходить транзитом.

flag

Ничего не менять в трафике — только записать совпадение. Измерьте, как часто правило сработало бы до того, как вы его применяете.
Хорошее развёртывание — flag → mask → block: flag, чтобы оценить влияние, mask, как только вы доверяете детектору, и приберегите block для полей, которые вы вообще не можете пропустить. См. Действия и Настройку ложных срабатываний.

​
6. Проверьте, что замаскировалось

Каждое сработавшее правило записывает совпадение в ленте Matches рабочего пространства — тип правила, действие, стадия и строка-деталь. Сама совпавшая подстрока (сырой email, фактический номер карты) записывается только, когда включён Log raw content, который по умолчанию выключен — консервативная по приватности позиция, поскольку весь смысл в том, чтобы держать сырые значения вне ваших логов.
Включайте Log raw content только когда вам действительно нужна подстрока для сортировки, и только для каждого guardrail. С ним выключенным лента доказывает, что [CREDIT_CARD] был замаскирован, ни разу не сохранив номер. Переключатель не ретроактивен. См. Логирование и приватность.

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

Прочтите справочник Guardrails для полного движка или раскрытие PII и утечку секретов для угроз, которые маскирование создано сдерживать.