Перейти к основному содержанию
Вы написали guardrail и политику firewall для своего рабочего пространства. Теперь вы хотите, чтобы этот один ключ — тот, что использует ваш финансовый агент, — выполнял более строгую политику содержимого и более тесный список разрешённых инструментов, чем остальное рабочее пространство. Именно это делают два поля привязки на ключе: привяжите guardrail и политику firewall к одному ключу, и каждый запрос, который делает этот ключ, проверяется и применяется ровно этими политиками — без изменений в коде агента, без передеплоя. Эта страница покрывает два поля, как они разрешаются во время запроса, и одно правило разрешения, на котором люди спотыкаются: отключённая привязка firewall ведёт себя иначе, чем отключённая привязка guardrail.

​
1. Политика безопасности на ключ: два поля на ключе

Guardrail проверяет текст, который проходит через модель (PII, секреты, jailbreak’и). Политика firewall управляет вызовами инструментов, которые выпускает агент (какие инструменты, какие MCP-серверы, какие хосты). Оба — именованные политики в рамках рабочего пространства — написаны один раз, общие в пределах рабочего пространства — и ключ выбирает конкретную через два поля:
ПолеПривязываетЗадаётся в консоли
guardrail_idGuardrail, который проверяет промпты и ответы этого ключа.Developer+
firewall_policy_idПолитику firewall, которая вычисляет вызовы инструментов этого ключа.Developer+
Оба задаются в редакторе ключа на /console/token. Установка любого из них — действие Developer+; сами политики тоже пишутся на уровне Developer+ (см. Область и ключи).
Эти два поля независимы. Ключ может прикрепить guardrail и не прикреплять политику firewall, наоборот, оба или ни одного — каждая плоскость разрешается сама по себе. Оставить поле незаданным (0) — не то же самое, что отключить применение; см. §3.

​
2. Один конкретный пример

Скажем, default-guardrail вашего рабочего пространства флагирует PII, но пропускает её, а default-политика firewall аудирует каждый вызов инструмента. Это нормально для большинства агентов — но ваш финансовый агент работает с SSN клиентов и никогда не должен вызывать shell-инструмент. Напишите более строгий finance-guardrail (блокирует PII напрочь) и finance-firewall (разрешает только три нужных ему инструмента), затем привяжите оба к ключу этого агента: 
# Configure via the CONSOLE (UserAuth — your session), not a relay key.
# This is the key-update call the editor at /console/token makes.
PUT /api/token
{
  "id": 4127,
  "name": "finance-agent",
  "guardrail_id": 12,          // finance-guardrail (PII = block)
  "firewall_policy_id": 8      // finance-firewall (3-tool allow-list)
}
Начиная со следующего запроса трафик этого ключа проверяется guardrail’ом 12, а его вызовы инструментов вычисляются политикой 8 — при этом каждый другой ключ в рабочем пространстве продолжает выполнять дефолты рабочего пространства. Собственный код агента не меняется; он продолжает вызывать https://api.orcarouter.ai/v1/... со своим ключом sk-orca-… ровно как раньше.
Это паттерн минимальных полномочий: один узко ограниченный ключ на агента, каждый привязан к политикам, которые реально нужны его задаче. Когда этот агент скомпрометирован, радиус поражения — это всё, что было разрешено его ключу, и ничего больше. См. чек-лист минимальных полномочий.

​
3. Разрешение: правило, на котором люди спотыкаются

Для каждого запроса шлюз разрешает активный guardrail и активную политику firewall независимо. Порядок выглядит одинаково для обоих — сначала привязка, потом default рабочего пространства — но они расходятся в одном случае.

​
Разрешение guardrail

guardrail_id ключа указывает на guardrail, который существует и включён. Этот guardrail проверяет запрос.
Отключение привязанного guardrail — это выключатель. Ключ получает никакой проверки содержимого — он не откатывается к default рабочего пространства. Это сделано намеренно: привязать guardrail и отключить его — это и есть способ выключить проверку для этого ключа.
На ключе нет guardrail_id. Применяется включённый default-guardrail рабочего пространства, если он задан.
Нет привязки и нет default рабочего пространства → запрос проходит без проверки содержимого.

​
Разрешение firewall

firewall_policy_id ключа указывает на политику, которая существует и включена. Эта политика вычисляет вызовы инструментов ключа.
Вот в чём разница. Отключённая привязка firewall откатывается к default-политике firewall рабочего пространства — она не выключает применение. Отключение привязки firewall возвращает ключ к default рабочего пространства; оно не оставляет ключ без защиты.
На ключе нет firewall_policy_id → применяется включённая default-политика firewall рабочего пространства.
Отключение привязанной политики несимметрично. Отключённая привязка guardrail означает никакого guardrail для этого ключа. Отключённая привязка firewall означает откат к default рабочего пространства. Если вы хотите, чтобы ключ действительно не выполнял применение firewall, вы не доберётесь туда отключением его привязки — убедитесь, что default-политика firewall рабочего пространства не задана (или ограничьте ключ так, чтобы он не выпускал управляемых вызовов инструментов).
Не более одного guardrail и одной политики firewall на рабочее пространство могут быть default’ом в любой момент; продвижение нового default’а понижает старый в той же транзакции, так что у вас никогда не может случайно оказаться двух.

​
4. Как выглядит блокировка

Когда привязанная политика отклоняет запрос, вызывающий видит структурированную ошибку — агент может среагировать вместо падения:
ПлоскостьКод ошибкиHTTPСтоимость
Guardrailguardrail_blocked400Нет — блокировка на входе срабатывает до тарификации; блокировка на выходе возвращает средства. Помечена skip-retry.
Firewall (inbound)firewall_blocked400Блокировка inbound срабатывает до вызова модели, так что нет токенов модели. Skip-retry.
Firewall (удержано)firewall_approval_pending400Удержано для подтверждения человеком; агент опрашивает и повторно отправляет после одобрения.
Оба тела ошибок в форме OpenAI и называют политику и причину, так что ваш агент может ветвиться по коду. См. глубокие справочники для полной записи события и того, как логируются совпадения.

​
5. Куда идти дальше

Область и ключи

Полная трёхуровневая модель — рабочее пространство, политика, ключ — и каждое поле, которое несёт ключ.

Объект токена

Каждое поле на ключе: model_limits, allow_ips, credit_limit_usd, expired_time и две привязки политик.

Guardrails

Напишите политику содержимого, которую вы привязываете через guardrail_id — правила, PII-сущности, действия и пресеты.

Firewall

Напишите политику вызовов инструментов, которую вы привязываете через firewall_policy_id — вердикты, поверхности и уровни автономии.
Хотите задать всю позицию рабочего пространства одним движением вместо привязки ключей по одному? Уровень автономии пишет обе плоскости — guardrails и firewall — сразу. Затем прикрепите более строгие политики на те немногие ключи, которым нужно зайти дальше default рабочего пространства. См. Guardrails vs Firewall.