Перейти к основному содержанию
У вас есть сохранённый guardrail, и вы хотите, чтобы конкретный API-ключ проверялся им — а не всё рабочее пространство. Именно для этого нужна привязка guardrail на каждый API-ключ: установите guardrail_id на ключе, и каждый вызов /v1/*, сделанный этим ключом, проверяется на следующем запросе, без передеплоя и без изменений SDK. Эта страница охватывает только привязку — как привязать, как разрешение выбирает эффективную политику и что делает выключатель. Типы правил, действия и стадии см. в справочнике Guardrails.

​
1. Привяжите guardrail на каждый API-ключ через guardrail_id

Guardrail ограничен рабочим пространством, но применение решается на каждый ключ. Каждый API-ключ несёт поле guardrail_id. Укажите его на guardrail, и этот ключ — и только этот ключ — проверяется этой политикой. Это позволяет одному рабочему пространству запускать разные политики на разных ключах:
  • production-ключ, привязанный к строгому pii-blocker,
  • staging-ключ, привязанный к более лёгкой политике flag-only,
  • internal-ключ без привязки.
Привязка живёт на ключе в шлюзе, поэтому редактирование guardrail смещает привязанный ключ на его следующем запросе. Ваше приложение продолжает вызывать https://api.orcarouter.ai/v1/chat/completions ровно так же, как раньше.
Relay-ключ (sk-orca-…) — это то, что отправляет ваше приложение. Привязка к нему guardrail — это действие в консоли / token-API, аутентифицированное вашей сессией; вы никогда не настраиваете guardrail самим relay-ключом.

​
2. Привяжите в консоли

Настройте привязку из консоли (с ограничением по роли: редактирование ключей и guardrails требует Developer+).
1

Откройте ключ

Перейдите в /console/token и создайте или отредактируйте API-ключ, который хотите проверять.
2

Выберите guardrail

В редакторе ключа выберите свой guardrail из выпадающего списка Guardrail. Это задаёт guardrail_id на ключе.
3

Сохраните

Привязка вступает в силу на следующем запросе этого ключа. Без передеплоя.
После этого обычный relay-вызов с привязанным ключом проверяется автоматически: 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Reply to jane@acme.com please"}
    ]
  }'
Если привязанный guardrail маскирует email на стадии input, вышестоящая модель видит [EMAIL] и никогда — адрес. Тот же вызов, без изменений клиента.
Чтобы проверять каждый ключ в рабочем пространстве, а не один, задайте guardrail как default рабочего пространства вместо привязки каждого ключа. См. Default guardrail аккаунта.

​
3. Как разрешение выбирает эффективный guardrail

На каждом запросе шлюз разрешает ровно один эффективный guardrail (или ни одного) в таком порядке:
Если guardrail_id ключа указывает на guardrail, и этот guardrail существует, и он включён — применяется он. Явная привязка авторитетна: она никогда не откатывается молча на default рабочего пространства.
Если у ключа нет привязки (guardrail_id равен 0 / не задан), применяется включённый default-guardrail рабочего пространства, если он задан.
Нет применения. Запрос побайтно идентичен рабочему пространству, которое никогда не включало функцию — ничего не блокируется, не маскируется и не логируется.
Решение — это один индексированный поиск на горячем пути, и он fail-open: если разрешение наталкивается на временную ошибку, шлюз деградирует до отсутствия применения, а не проваливает запрос. Деградирует безопасность; доступность сохраняется.

​
4. Выключатель: отключите привязку, без отката

Это часть, которую люди упускают. Явная привязка ключа — это собственная авторитетность, поэтому отключение привязанного guardrail выключает применение для этого ключа, и оно не откатывается на default рабочего пространства.
Состояние ключаЧто проверяет запрос
guardrail_id → включённый guardrailэтот guardrail
guardrail_id → отключённый guardrailничего (нет отката)
guardrail_id → удалённый / отсутствующийничего (нет отката)
guardrail_id = 0 / не заданdefault рабочего пространства, если есть
Отключение привязанного guardrail — это выключатель для этого ключа, а не понижение до default. Если вы хотите, чтобы ключ откатывался на default рабочего пространства, очистите его привязку (установите guardrail_id в 0) — не просто отключайте guardrail, на который он указывает.
Это намеренное отличие от firewall: ключ с отключённой привязанной политикой firewall откатывается на default-политику firewall рабочего пространства, тогда как отключённый привязанный guardrail разрешается в none. Та же идея, обратный откат — см. Guardrails vs. firewall.

​
5. Отвяжите или очистите привязку

Чтобы перестать проверять ключ конкретным guardrail, у вас есть два различных действия с разными исходами:
  • Очистите привязку — установите guardrail_id ключа в 0. Теперь ключ разрешается в default рабочего пространства (если он существует) или в none.
  • Отключите guardrail — переключите enabled guardrail в off. Каждый ключ, явно привязанный к нему, теперь разрешается в none (по §4), а ключи, которые полагались на него как на default рабочего пространства, проваливаются в отсутствие применения.
Выбирайте очистку, когда хотите вернуть ключ на базовый уровень рабочего пространства; выбирайте отключение, когда хотите приостановить эту политику везде, где она является именованной привязкой.

​
6. Сколько стоит (и не стоит) проверяемый запрос

Как только guardrail разрешён, его правила решают судьбу запроса. Два исхода, которые стоит знать для привязанного ключа:
  • block возвращает HTTP 400 с кодом ошибки guardrail_blocked, называя guardrail и сработавшее правило. Он не стоит квоты — блокировка на стадии input срабатывает до учёта, блокировка на стадии output возвращает предварительно списанную квоту — и помечается как skip-retry.
  • mask переписывает совпадение в типизированный тег (например, [EMAIL]) и пропускает запрос очищенным; вышестоящая модель никогда не видит оригинал.
См. страницу ошибки guardrail_blocked для точной формы ответа и Покрытие потоков о том, как правила выхода ведут себя на потоковых ответах.

​
7. Куда дальше

Создайте свой первый guardrail

Постройте политику, которую привяжете к ключу.

Default guardrail аккаунта

Проверяйте каждый ключ в рабочем пространстве сразу.

Справочник Guardrails

Типы правил, действия, стадии, PII, judge, grounding.

Ключи, политики и рабочие пространства

Как привязки ограничиваются по шлюзу.