Перейти к основному содержанию
Каждый запрос, достигающий OrcaRouter, несёт API-ключ. Этот ключ — не просто учётные данные — это объявление области: какие модели вызывающий может использовать, какие IP могут его предъявлять, сколько он может тратить и какие именно guardrail и политика firewall управляют его трафиком. На этой странице объясняется трёхуровневая иерархия и как политики разрешаются во время запроса.

​
1. Три области

Три концепции вложены друг в друга:
  • Рабочее пространство — граница тенанта. Каждый участник рабочего пространства разделяет один и тот же каталог guardrail и политик firewall. Ничего не пересекает границы рабочих пространств — политика, созданная в рабочем пространстве A, невидима для рабочего пространства B.
  • Политика — именованный набор правил в рамках рабочего пространства (guardrail или политика firewall). Редактирование политики вступает в силу для каждого привязанного к ней ключа при следующем запросе, без передеплоя.
  • Ключ — идентификация плюс привязки. Ключ несёт собственные ограничения и указывает на политики, которые им управляют.
Рабочее пространство — внешняя граница; политики — общие ресурсы внутри него; ключи — идентификации отдельных агентов, связывающие ограничения и политики.

​
2. Что несёт ключ

Каждый API-ключ — это пакет ограничений и привязок. Устанавливайте их в редакторе ключей (/console/token) — создание или редактирование ключей требует роли Developer или выше.
ПолеЧто ограничиваетМинимальная роль для установки
model_limitsОграничивает ключ конкретным списком моделей — любой вызов вне списка отклоняется до выхода из шлюза.Developer
allow_ipsСписок разрешённых IP. Запросы с любого незарегистрированного адреса отклоняются на уровне аутентификации. Пустой означает, что все IP разрешены.Developer
credit_limit_usdЛимит расходов в USD. 0 означает неограниченно. Шлюз применяет это против пожизненных расходов ключа.Developer
expired_timeАбсолютная временная метка срока действия. -1 означает, что ключ никогда не истекает.Developer
environmentПроизвольная метка (например, prod, staging, dev) для организации ключей и фильтрации логов.Developer
guardrail_idПривязывает конкретный guardrail к этому ключу. Каждый вызов этого ключа проверяется этим guardrail’ом.Developer
firewall_policy_idПривязывает конкретную политику firewall к этому ключу. Каждый вызов инструмента этого ключа оценивается этой политикой.Developer
is_firewall_gatewayПомечает ключ как токен с областью шлюза — требуется для вызова маршрутов диспетча MCP и хука evaluate. Обычный ключ получает 403 на этих маршрутах. Чтение открытого текста ключа шлюза требует Admin.Admin (для включения и чтения открытого текста)
Ключи маскируются при отображении в консоли. Открытый текст показывается один раз при создании; ключи с областью шлюза требуют Admin для повторного получения.

​
3. Порядок разрешения политик

Для любого запроса OrcaRouter разрешает активный guardrail и политику firewall независимо:
  1. Привязка ключа — если ключ имеет явный guardrail_id (или firewall_policy_id) и эта политика существует и включена, она применяется.
  2. Default рабочего пространства — если у ключа нет привязки, применяется включённый guardrail или политика рабочего пространства с is_default.
  3. Нет применения — если ни то, ни другое не установлено, запрос проходит без проверки содержимого или применения вызовов инструментов.
Две плоскости отличаются, когда привязанная политика отключена:
  • Отключённая или удалённая привязка guardrail означает, что ключ получает нет guardrail — отключение его является выключателем; оно не откатывается к default’у рабочего пространства.
  • Отключённая привязка firewall откатывается к default-политике firewall рабочего пространства — поэтому отключение привязки firewall возвращает ключ к default’у рабочего пространства, а не отключает применение.
Отсутствующая (0/unset) привязка всегда откатывается к default’у рабочего пространства; ни то ни другое не установлено — означает нет применения.
В каждом рабочем пространстве одновременно не более одного guardrail и одной политики firewall могут быть default’ом. Продвижение нового default’а понижает старый в той же транзакции — вы никогда не можете случайно иметь два default’а.

​
4. Ключи с минимальными полномочиями — один ключ на агента

Самая безопасная конфигурация — дать каждому агенту собственный узко ограниченный ключ вместо использования одного ключа рабочего пространства для всех вызывающих. Хорошо ограниченный ключ для агента, который вызывает только одну модель и выполняет запланированные задачи, может выглядеть так:
  • model_limits: ["openai/gpt-4o-mini"] — агент не может переключиться на более дорогую или более мощную модель.
  • allow_ips: CIDR исходящего трафика планировщика — ни один другой источник не может предъявить этот ключ.
  • credit_limit_usd: недельный потолок бюджета — бесконечный цикл не может исчерпать баланс рабочего пространства.
  • expired_time: конец спринта или жизненного цикла развёртывания — ключ автоматически истекает и не может быть повторно использован.
  • guardrail_id: guardrail, специфичный для чувствительности данных этого агента — жёстче, чем default рабочего пространства.
  • firewall_policy_id: политика, в which-список разрешённых входит только набор инструментов, которые агент законно использует.
Когда этот агент скомпрометирован через prompt injection, радиус взрыва ограничен: он может вызывать только одну модель, только с одного диапазона IP, только до лимита расходов и только инструменты, которые разрешает его политика firewall. Остальная часть рабочего пространства не затронута.
Создавайте ключи с областью шлюза (is_firewall_gateway) только для поверхности диспетча MCP или хука evaluate — никогда для общего вывода. Ключ шлюза на пути вывода даёт вызывающему доступ к маршрутам /api/v1/firewall/*, что является более широкой возможностью, чем ему нужно. Один ключ, одна цель.

​
5. Где создаются политики

Guardrails и политики firewall оба ограничены рабочим пространством и разделяются между всеми участниками, но изменения требуют правильной роли:
  • Читать любой guardrail, политику или ключ — любой участник рабочего пространства.
  • Создавать или изменять guardrails, политики firewall, MCP-серверы, уровни автономии, действия подтверждений и обычные API-ключи — Developer+.
  • Включать is_firewall_gateway на ключе; читать открытый текст ключа шлюза — Admin+.
Рабочее пространство — граница сотрудничества: все могут видеть каталог политик; только Developers и выше могут изменять его; только Admin’ы могут выпускать учётные данные шлюза.

​
6. Дальнейшие шаги

Базовый уровень Secure Agents

Рекомендуемая стартовая позиция — один переключатель уровня автономии, затем настройка из реального трафика.

Получите API-ключ

Создайте свой первый ключ и привяжите guardrail или политику firewall в консоли.
Область — основа стека управления. Чем уже область каждого ключа, тем меньше радиус взрыва при компрометации любого одного агента — и тем чище журнал аудита, показывающий, что каждый агент был авторизован делать.