Policy Rules (Guardrails)

Кому подходит

• Владельцам и администраторам — централизованно управлять ограничениями без разрозненных полей.
• ИБ и compliance — настраивать content-политики на нужном уровне клиента.
• Разработчикам — понимать, какие правила реально сработали для конкретного API-запроса.

Где настраиваются ограничения

Ограничения по моделям, бюджетам, контенту и rate limits задаются в API .../policy/rules и применяются при каждом запросе к API моделей.

Что можно настроить в одном правиле

Каждое правило — набор модулей:

Пустой белый список в модуле access означает «без дополнительного ограничения по этому измерению» — сужение начинается только когда хотя бы одно правило задаёт непустой список.

Назначение правил: кому применяется

Правило привязывается к клиенту (clientSubject).

Личный аккаунт: в кабинете доступны «вся организация» (organization) и отдельный api_key.

Бизнес-аккаунт: полный набор уровней назначения плюс виртуальные группы (создаются в разделе Виртуальные группы).

Наслоение правил

На один запрос могут одновременно подойти несколько правил разных уровней — например, организация + виртуальная группа + API-ключ. Это не «первое совпадение», а совокупность:

• правило на участника задаёт базовую линию для всех его ключей;
• правило на ключ накладывается сверху и может быть строже;
• правила организации и группы действуют параллельно, если запрос попадает в их scope.

Счётчик бюджета всегда привязан к тому клиенту, для которого создано правило: отдельно «область счётчика» в кабинете не выбирается — она совпадает с clientSubject.

Иерархия и объединение

Для каждого запроса платформа выполняет два шага:

1. Сбор — по лестнице scope и уровням назначения собираются все активные PolicyRule, подходящие к запросу.
2. Объединение — модули сводятся в итоговую политику.

Правила объединения:

Чем больше правил сужает доступ, тем уже итоговый белый список. Чем больше правил задаёт бюджеты, тем больше независимых проверок на каждом запросе.

Примеры бюджета (независимые счётчики)

Бюджеты не делятся между участниками: у каждого клиента свой счётчик на каждое правило.

Пример 1 — правило на участника, 50 000 ₽/день

Правило с лимитом 50 000 ₽/день назначено трём сотрудникам. У каждого свой счётчик 50 000 ₽. Если один исчерпал лимит, остальные продолжают работать в своих пределах.

Пример 2 — расход ключей суммируется для участника

У участника два API-ключа, на каждый — правило 20 000 ₽/день. Ключ A потратил 15 000 ₽, ключ B — 10 000 ₽. По ключам лимиты не превышены, но если на участника тоже действует правило 20 000 ₽/день, его суммарный расход 25 000 ₽ превысит member-лимит — новые запросы с любого его ключа будут отклонены.

Пример 3 — наслоенные лимиты

У участника member-правило 100 000 ₽/день. На ключ — отдельное правило 30 000 ₽/день. Ключ не может потратить больше 30 000 ₽/день, а суммарно по всем ключам участника — больше 100 000 ₽/день. Оба лимита проверяются на каждом запросе; срабатывает тот, который исчерпан первым.

Лестница scope: client × provider × model

Помимо клиента правило может сузить область по провайдеру и модели каталога (8 уровней — как в pricing rules):

Policy rules не останавливаются на первом совпадении по scope — собираются все подходящие уровни, затем объединяются.

Уровни назначения правил

При сборе правил они сортируются от более специфичного клиента к менее:

1. api_key
2. system
3. member
4. virtual_group
5. organization
6. глобальные правила платформы (без clientSubject)

Виртуальные группы и наследование

Виртуальная группа содержит только memberIds и systemIds. API-ключи в группу напрямую не добавляются. Ключ наследует группы через:

• владельца ключа (ownerEmail → member);
• или systemId, если ключ привязан к системе/агенту.

Белый список IP (network)

Модуль network ограничивает доступ к API моделей по IP-адресу клиента. Организация задаёт список разрешённых адресов и подсетей; запросы с других IP блокируются с HTTP 403 и причиной ip_not_allowed.

{
  "network": {
    "allowedIPs": ["203.0.113.10", "10.0.0.0/8", "192.168.1.0/24"]
  }
}

Формат записей: отдельный IPv4/IPv6 или CIDR (10.0.0.0/8). До 200 записей на правило.

Как определяется IP: платформа учитывает адрес, с которого пришёл запрос к API моделей (в том числе через корпоративный прокси, если он передаёт исходный адрес клиента).

Объединение: если несколько правил задают списки IP, адрес должен попадать в каждый список (пересечение). Типичный сценарий — одно правило на организацию с офисными подсетями.

Проверка контента

Модуль content сканирует вход запроса (тексты сообщений, аргументы tool calls) до вызова модели. Ответ модели проходит детокенизацию и повторное маскирование новых ПДн, сгенерированных моделью.

Персональные данные (PII)

Встроенные типы: email, телефон, паспорт, ИНН, платёжная карта, СНИЛС, ОГРН, ОГРНИП, полис ОМС. Дополнительно — свои regex через API (customPatterns).

Действия (в кабинете: блокировать, маскировать, предупреждать):

• block — HTTP 403, запрос не доходит до провайдера;
• mask — обратимая токенизация: каждое совпадение заменяется уникальным суррогатом (<PII_EMAIL_1>), запрос уходит к модели; в ответе суррогаты восстанавливаются в оригинал;
• warn — фиксация срабатывания без блокировки и маскирования.

В REST API значение redact принимается как синоним mask (обратная совместимость); в интерфейсе не отображается.

Allow list (исключения)

Поле content.pii.allowList — массив публичных значений (email, телефон и т.д.), которые не маскируются и не блокируются. Пример: support@company.com, +7 800 123-45-67. Списки из нескольких правил объединяются.

Встроенные regex для PII

При маскировании каждое совпадение получает уникальный суррогат: <PII_EMAIL_1>, <PII_PHONE_2>. Таблица суррогат→оригинал хранится только в памяти на время запроса. После ответа модели суррогаты в тексте ответа восстанавливаются; новые ПДн в output дополнительно маскируются.

Категории контента

Дополнительно к PII: ненормативная лексика, разжигание ненависти, насилие, 18+, незаконная активность. Проверка по ключевым словам (не regex). Настраиваются в мастере на шаге «Категории контента».

Prompt injection

Встроенные OWASP-паттерны и свои regex. В кабинете — шаг Prompt injection в мастере правила. Действия: только фиксировать, маскировать, блокировать.

Рекомендуемый порядок: сначала Наблюдение (content.mode: observe) или действие «Только фиксировать», затем маскирование или блокировка.

Если поле content.promptInjection.patterns пустое, используются встроенные паттерны (регистронезависимые):

При указании своих паттернов в promptInjection.patterns встроенный набор заменяется списком из правила (по одному regex на строку в UI).

Свои паттерны (customPatterns)

Custom regex на шаге Свои паттерны. Действия: block, mask, warn.

Разрешённый синтаксис (RE2): классы символов, квантификаторы, альтернация |, негруппирующие скобки (?:…), якоря ^ $ \b, экранирование.

Запрещено: lookahead (?=…) / (?!…), lookbehind (?<=…) / (?<!…), backreference \1 / \k<name>, паттерны с риском ReDoS вроде (a+)+.

Примеры:

При маскировании замена на [REDACTED]; при блокировке в ошибке — label паттерна или [BLOCKED]. До 100 000 символов на паттерн.

Объединение контент-фильтров

Если на запрос действуют несколько правил с content:

• фильтры объединяются (union): email из одного правила и телефон из другого — оба применяются;
• при разных действиях для одного типа данных побеждает block над mask над warn;
• mode: observe фиксирует срабатывание без блокировки и без маскирования.

Когда запрос блокируется

При срабатывании budget, access, content (block) или rate limit API моделей возвращает 403 или 429. Для content-блокировок в теле ошибки указывается причина (тип PII, категория, паттерн).

Информационные системы и агенты

У информационной системы есть тип: system или agent. В интерфейсе — бейджи IS / Agent.

Персональные и бизнесовые guardrails

• Бизнес: бюджеты организации, доступ к моделям, лимиты для рабочих ключей, группы и участники.
• Личный: правила на всю организацию или отдельный ключ без member/virtual_group.

Про RPM/TPM

Ограничения RPM/TPM — модуль rateLimit в PolicyRule. Платформа применяет скользящее окно RPM на уровне API-ключа; при превышении — 429 Too Many Requests. См. Лимиты и квоты и Policy API.

Что дальше

• Лимиты и квоты
• API-ключи
• Справочник: Policy API
• История изменений