Перейти к основному содержанию
Любой промпт, который ваше приложение отправляет модели, может нести персональные данные, которых там быть не должно — email, вставленный в тикет поддержки, SSN в заметке CRM, номер карты, который пользователь напечатал в чате. Как только этот текст достигает вышестоящего провайдера, он выходит из-под вашего контроля: логируется, кэшируется, возможно используется для обучения. Ответ модели тоже может вернуть PII обратно, повторяя или выводя детали, которые затем попадают в логи вашего приложения. Эта страница показывает, как остановить утечку PII в LLM на шлюзе с помощью PII-guardrail — правила в рамках рабочего пространства, которое маскирует или блокирует чувствительные сущности в запросе до того, как модель их вообще увидит. Это контентный аналог Agent Firewall, и он не требует изменений в коде вашего приложения.
PII-guardrail проверяет текст промптов и ответов. Чтобы управлять действиями, которые агент совершает с данными — инструменты выборки, egress-хосты — см. Эксфильтрация данных. Две плоскости комбинируются; большинство команд используют обе.

​
1. Как происходит раскрытие

PII достигает вышестоящего провайдера через обычный, благонамеренный трафик:
  • Пользователь вставляет свои контактные данные в чат, а ваше приложение пересылает всё сообщение дословно.
  • RAG-конвейер извлекает документ, содержащий записи клиентов, и помещает его в промпт в качестве контекста.
  • Агент читает строку базы данных и включает необработанные поля в аргумент инструмента или последующий промпт.
  • Ответ модели повторяет или выводит PII, которые ваше приложение затем записывает в собственные логи.
Ничто из этого не является атакой — это нормальная форма LLM-приложений. Решение — политика, которая проверяет каждый запрос и ответ в одной контрольной точке, вместо аудита каждого места вызова в вашем коде.

​
2. Защита от утечки PII в LLM с помощью PII-guardrail

Guardrail — это именованная контентная политика в рамках рабочего пространства. Правило pii внутри него обнаруживает чувствительные сущности и применяет одно действие к каждому совпадению:
ДействиеЭффект
maskЗаменить каждое совпадение типизированным тегом — jane@acme.com → [EMAIL] — и переслать очищенный текст. Модель никогда не видит оригинал.
blockОтклонить весь запрос с HTTP 400 guardrail_blocked. Используйте, когда PII вообще не должны достигать провайдера.
flagНичего не менять в трафике; записать совпадение. Измерьте раскрытие до того, как начнёте применять.
Набор детекторов встроен и детерминирован — чистое сопоставление паттернов, без сетевого вызова, безопасно на горячем пути. Встроенные сущности: 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. При действии mask каждое совпадение отображается как его типизированный тег — [EMAIL], [SSN], [CREDIT_CARD] и т.д. — так что структура промпта сохраняется, а значение исчезает.
Нужен детектор, которого нет среди встроенных (внутренний ID сотрудника, номер счёта)? Добавьте пользовательскую сущность — regex с опциональной контрольной суммой Luhn, до 25 на правило — прямо рядом со встроенными. См. Справочник Guardrails.

​
3. Конкретный пример — маскирование PII в запросе

Самый быстрый старт — пресет PII Shield: единственное правило pii, которое маскирует email, phone, ssn, credit_card и ip. Настройте его в консоли — без изменений кода, без ключа на этом шаге.
1

Создайте guardrail

В консоли откройте Guardrails и нажмите New guardrail. Выберите пресет PII Shield из категории pii или вручную напишите одно правило pii с действием mask для сущностей выше. Сохраните. (Запись требует роли Developer или выше.)
2

Проверьте в песочнице

Откройте вкладку Test, вставьте «reply to jane@acme.com», выберите этап input и запустите. Песочница возвращает reply to [EMAIL] — локально, без вышестоящего вызова и без расхода квоты.
3

Привяжите к ключу

В API Keys отредактируйте ключ и выберите guardrail из выпадающего списка Guardrail, или установите guardrail как дефолт рабочего пространства, чтобы каждый непривязанный ключ его унаследовал. Привязка живёт на ключе в шлюзе.
4

Вызовите шлюз как обычно

Используя этот ключ, ваш relay-вызов не меняется:
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": "Draft a reply to jane@acme.com"}
    ]
  }'
Шлюз переписывает email в [EMAIL] до пересылки. Вышестоящая модель никогда не получает адрес.
PII Shield — это правило этапа both, но на сегодня поставляется живое маскирование на этапе запроса — шлюз маскирует промпт до того, как он уходит к модели. Маскирование на этапе вывода (ответа) на живом relay в дорожной карте. Чтобы проверить, как ведёт себя правило этапа ответа, оцените его во вкладке Test. Про стриминг см. §5.

​
4. Маскируйте большинство, блокируйте худшее — переопределения по сущностям

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

​
5. Что работает на стриминге сегодня

Действие и этап по-разному взаимодействуют со стримингом — узнайте матрицу до того, как начнёте на это полагаться:
Полностью живое. Промпт проверяется до вышестоящего вызова, так что маскирование и блокировка работают одинаково, независимо от того, стримится ли ответ. Это поверхность, которую PII Shield применяет сегодня.
Применяется как к стриминговым, так и к нестриминговым ответам. На стриме сканер обрывает поток на лету и выдаёт замещающее сообщение до того, как какой-либо заблокированный контент достигнет клиента; блокировка вывода возвращает предварительно списанную квоту.
В настоящее время только нестриминг. На стримящемся ответе оригинальный фрагмент проходит немаскированным — переписывание потока в полосе является запланированным улучшением. Для маскирования ответа сегодня используйте нестриминговые запросы или полагайтесь на маскирование на этапе входа. Сначала проверьте вашу точную комбинацию этап/стрим во вкладке Test.

​
6. Посмотрите, что было поймано

Каждое сработавшее правило записывает совпадение — его тип, действие, этап и строку детализации — видимое в ленте Matches рабочего пространства (GET /api/guardrail/match, открыто любому участнику). Оттуда вы можете группировать, фильтровать, экспортировать в CSV и помечать ложные срабатывания.
Необработанные значения по умолчанию не логируются. Переключатель Log raw content у guardrail выключен — позиция, консервативная к приватности — так что лента Matches записывает, что сработало PII-правило и какая сущность, но не совпавшую подстроку (сам адрес email). Включайте его для каждого guardrail отдельно только тогда, когда значение нужно для триажа; настройка не ретроактивна. Захват PII в собственный журнал аудита для отладки утечки PII был бы самоопровержением.

​
7. Развивайте дальше

Для полного контроля резидентности, удержания и права на удаление — включая установку комплаенс-пакета, материализующего эти guardrails для GDPR, HIPAA или PCI DSS — начните со справочных страниц ниже.

Справочник Guardrails

Каждый тип правила, этап, действие, пользовательские сущности, версионирование и evaluation-харнесс — глубокий справочник за этой страницей.

Утечка секретов

Аналог в форме учётных данных — токены AWS, OpenAI, GitHub — ловимый guardrail-ом Secrets Blocker.

Небезопасный вывод

Проверка того, что модель отправляет обратно, а не только того, что получает.

Guardrails vs Firewall

Когда проверять текст, а когда управлять действиями — и почему обычно нужно и то, и другое.