Перейти к основному содержанию
Вы строите SaaS, где много клиентов-тенантов разделяют одну кодовую базу и одно рабочее пространство OrcaRouter. Каждый тенант отправляет промпты и запускает агентов через ваш шлюз, и трудная проблема — это радиус поражения: утёкшему ключу тенанта, убегающему агенту тенанта или PII одного тенанта, приземляющемуся в логи другого, нельзя дать перелиться через границу. Этот рецепт настраивает три контроля, которые делают общий шлюз безопасным для тенантов, — ограниченный ключ на тенанта, политику уровня рабочего пространства, которую наследует каждый тенант, и пер-тенантные переопределения, где одному тенанту нужно больше, — всё из консоли, с нулевыми изменениями в коде вашего приложения.
Всё здесь привязывается к вашему рабочему пространству и настраивается из консоли. Ваше приложение продолжает вызывать https://api.orcarouter.ai/v1/chat/completions с ключом sk-orca-... каждого тенанта — меняется только политика в шлюзе. Действия по конфигурации требуют ролей, указанных на каждом шаге; только вызовы ретрансляции /v1/* используют ключ тенанта.

​
1. Модель мультитенантной ИИ-безопасности

У мультитенантного шлюза форма угрозы иная, чем у одиночного приложения. Риски, которые важны, масштабируются с числом тенантов:

Утечка ключа = радиус поражения одного тенанта

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

Межтенантное протекание данных

PII одного тенанта, приземляющийся в общие логи или в ответ, маршрутизированный другому тенанту, ломает ваше обещание изоляции данных.

Шумный агент тенанта

Агент одного тенанта, зацикливающийся на инструменте или извлекающий произвольные хосты, не должен ухудшать шлюз для всех остальных.

Пер-тенантный комплаенс

Регулируемому тенанту может понадобиться маскирование PII и резидентность данных, которых не нужно остальным вашим тенантам.
Модель ниже — это два слоя: базис рабочего пространства, который наследует каждый ключ тенанта, плюс пер-ключевая область и переопределения, которые ужесточают одного тенанта, не касаясь остальных. См. области: ключи, политики, рабочие пространства для полных правил разрешения.

​
2. Базис: одна политика рабочего пространства, которую наследует каждый тенант

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

Default-guardrail

В Guardrails → New guardrail создайте одну именованную политику (например, tenant-baseline) и пометьте её default рабочего пространства (is_default). Добавьте правило PII, стадия input, действие mask, чтобы запрос ни одного тенанта не нёс сырой PII вышестояще:
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
Любой ключ тенанта без явной привязки guardrail откатывается к этому default. Создание guardrail требует роли Developer.
2

Default-политика firewall

Если ваши тенанты запускают агентов, сделайте то же на плоскости действий: в Firewall → Policies создайте default-политику или — быстрее — откройте Firewall → Posture и примените уровень автономии balanced (уровень автономии). Это аудирует вызовы инструментов каждого тенанта и флагирует PII по всему рабочему пространству, запрещая при этом самые деструктивные действия, так что вы наблюдаете реальное поведение тенанта перед широким применением. Роль Developer.
Выкатывайте базис в порядке observe → shadow → enforce, чтобы новое правило не могло сломать тенанта на лету. Политика firewall поддерживает пер-политический флаг shadow_mode (применяющие вердикты логируются как [shadow] would …); начинайте правила guardrail с действия flag. См. режимы применения.

​
3. Один ограниченный ключ на тенанта

Это ядро изоляции тенантов: никогда не разделяйте ключ между тенантами и никогда не давайте тенанту ваш ключ уровня аккаунта. Выпустите по одному ключу на тенанта, ограниченному ровно тем, что этому тенанту можно делать. В API Keys → New key задайте:
Установите credit_limit_usd на потолок этого тенанта (0 = без лимита). Это самый важный мультитенантный контроль: утёкший или злоупотреблённый ключ тенанта может сжечь только бюджет этого тенанта, никогда ваш аккаунт. См. denial-of-wallet.
Включите model_limits (model_limits_enabled) и перечислите только модель(и), которую включает план этого тенанта, — так что утёкший ключ не может запустить дорогую модель, за которую тенант никогда не платил.
Установите environment (свободный лейбл деплоя, например prod / staging), чтобы трафик тенанта был атрибутируем в ваших логах и вы могли отличать ключи production от тестовых с одного взгляда.
Установите allow_ips на egress-IP бэкенда этого тенанта, если он вызывает с фиксированного сервера, и expired_time для пробных или ограниченных по времени тенантов (-1 = никогда не истекает).
Каждый ключ тенанта автоматически наследует guardrail tenant-baseline рабочего пространства и default-политику firewall — вы выпустили ограниченный ключ, и он уже управляется. Ключ маскируется при отображении после создания, так что скопируйте его один раз, когда провизионируете тенанта.

​
4. Пер-тенантные переопределения — ужесточите одного, не касаясь остальных

Большинство тенантов едут на базисе. Когда одному нужно больше — регулируемому тенанту, корпоративному тиру, тенанту в списке на испытательном сроке — привяжите более строгую именованную политику к тому ключу только:
Установить на ключеЭффект для этого одного тенанта
guardrail_idПодставляет более строгий именованный guardrail (например, block-on-PII).
firewall_policy_idПодставляет более плотную политику firewall (например, default-deny инструментов).
Разрешение различается между двумя плоскостями — знайте разницу:
Явный guardrail_id (когда он существует и включён) всегда применяется и никогда не откатывается молча. Если этот привязанный guardrail отключён, ключ получает никакого guardrail — он не падает к default рабочего пространства. Оставьте guardrail_id неустановленным (0/null), чтобы унаследовать default tenant-baseline.
Привязанный firewall_policy_id применяется, когда он существует и включён; если эта политика отключена, ключ откатывается к default-политике firewall рабочего пространства. (Это противоположность поведения off-переключателя guardrail — по дизайну.)
Редактирование именованной политики смещает каждый привязанный к ней ключ на следующем вызове. Если несколько тенантов разделяют одну более строгую политику, правка бьёт по всем сразу. Используйте отдельную именованную политику на класс изоляции, а не одну гигантскую общую политику, когда тенантам нужны действительно разные правила.

​
5. Конкретный двухтировый пример

Скажем, вы запускаете бесплатный тир и регулируемый корпоративный тир на одном рабочем пространстве:
  1. Базис рабочего пространства — guardrail tenant-baseline (маска PII на input, блок на карте/SSN) как is_default, плюс уровень автономии firewall balanced. Каждый тенант это наследует.
  2. Ключ тенанта бесплатного тира — нет guardrail_id (наследует базис), model_limits закреплён на openai/gpt-4o-mini, низкий credit_limit_usd.
  3. Ключ корпоративного тенанта — guardrail_id, установленный на более строгий guardrail enterprise-pii (PII block, не mask, на input; блок секретов на стадии output), firewall_policy_id с более плотным allow-list инструментов, более высокий кредитный кап и allow_ips, закреплённый на их бэкенд.
Оба тира вызывают тот же endpoint /v1/chat/completions со своим собственным ключом. Шлюз разрешает правильную политику для каждого ключа — ваш код приложения идентичен для каждого тенанта.

​
6. Пер-тенантный комплаенс и резидентность

Регулируемому тенанту часто нужна аттестация, которой не нужно остальным. Комплаенс работает как сосед рабочего пространства guardrails и firewall:
  • Просмотр каталога фреймворков и готовности открыт любому Member и бесплатен — подтвердите покрытие для фреймворка, о котором спрашивает тенант (soc2, hipaa, gdpr, iso_27001, pci_dss и других).
  • Установка пака (POST /api/compliance/packs/:key/install) материализует соответствующие guardrails и политики firewall в ваше рабочее пространство; она требует Admin рабочего пространства и платного плана.
  • Резидентность данных привязывает регион артефакта отчёта комплаенса (us / eu / uk / ap / cn / global) через PUT /api/compliance/residency (Admin). Межрегиональные чтения отклоняются.
Резидентность здесь управляет артефактом отчёта комплаенса, а не гео-привязкой данных инференса. Что до истории request-логов: логи хранятся по умолчанию 30 дней (жёсткий потолок 180), а самоудаление пользователя запускает 30-дневную отсрочку, затем скраб PII, который каскадирует на совпадения guardrail и request-логи этого пользователя.
Для полного аудируемого прогона доказательств см. сгенерируйте доказательства SOC 2 и разверните для HIPAA.

​
7. Наблюдайте за каждым тенантом из одного рабочего пространства

Вся наблюдаемость ограничена рабочим пространством, так что один набор лент покрывает всех ваших тенантов — фильтруемый до одного:
  • Guardrails → Matches (любой Member) — каждое сработавшее правило по всем тенантам: тип, действие, стадия, деталь. Совпавшая подстрока записывается только, если для этого guardrail включено Log raw content (выключено по умолчанию — консервативная по приватности позиция, которая важнее всего в мультитенантности). Отметьте ложное срабатывание, чтобы настроить (Admin).
  • Firewall → Events / Runs (Developer+) — каждый вызов инструмента, свёрнутый по прогону агента, так что цикл шумного тенанта или новый egress выделяется.
  • Лента аномалий (Member) — всплески частоты/стоимости, оценённые против обученного базиса по часу недели, ловят одного тенанта, выгорающего вне паттерна, даже когда каждый вызов индивидуально разрешён.
Заблокированный запрос возвращает HTTP 400 (guardrail_blocked / firewall_blocked), не стоит этому тенанту квоты и помечается skip-retry — граница удержалась, не взимая с тенанта плату за отказ.

​
8. Куда углубиться

Область ключей, политик, рабочих пространств

Полный порядок разрешения для привязки ключа и дефолтов рабочего пространства.

Справочник Guardrails

Каждый тип правила, PII-сущность и пер-сущностное переопределение полностью.

Справочник Firewall

Вердикты, поверхности, уровни автономии и плоскость политик.

Остановите эксфильтрацию данных

Ограничьте исходящий egress агента тенанта.