Policy Rules (Guardrails)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иерархия и объединение (collect + merge)

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

1. Collect — по лестнице scope и client tiers собираются все активные PolicyRule, подходящие к запросу.
2. Merge — модули объединяются в EffectivePolicy.

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

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

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

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

Пример 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 — собираются все подходящие уровни, затем merge.

Уровни клиентов (client tiers)

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

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

Virtual Groups и наследование

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

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

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

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

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

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

Действия:

• mask — подстановка метки, запрос уходит к модели;
• block — HTTP 403, запрос не доходит до провайдера;
• warn — фиксация срабатывания без блокировки и маскирования.

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

При маскировании подстановка: [PII:тип] (например [PII:email]).

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

Дополнительно к 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 gateway возвращает 403 или 429. Для content-блокировок в теле ошибки указывается причина (тип PII, категория, паттерн). В pipeline metadata (если включена) видны стадии policy / content / rate_limit.

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

У ClientSystem есть kind: system или agent. В интерфейсе — бейджи IS / Agent; в resolver оба остаются tier system.

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

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

Про RPM/TPM

Ограничения RPM/TPM — модуль rateLimit в PolicyRule. Gateway применяет sliding-window RPM на уровне API-ключа (429, pipeline stage rate_limit). Для счётчиков нужен Redis (REDIS_URL). См. Лимиты и квоты и Policy API.

Что дальше

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