メインコンテンツへスキップ
保存済みのガードレールがあり、ワークスペース全体では なく特定の API キーをそれでスクリーニングしたいとします。それが API キーごとの ガードレールバインディングの用途です：キー上に guardrail_id を設定すると、 そのキーで行われるすべての /v1/* 呼び出しが次のリクエストでスクリーニングされます — 再デプロイなし、SDK 変更なしで。 このページはバインディングのみを扱います — どうアタッチするか、解決が有効な ポリシーをどう選ぶか、そしてオフスイッチが何をするか。ルールの種類、アクション、 ステージについてはガードレールリファレンスを参照 してください。

​
1. guardrail_id で API キーごとにガードレールをバインドする

ガードレールはワークスペーススコープですが、強制はキーごとに決定されます。 各 API キーは guardrail_id フィールドを持ちます。それをガードレールに向けると、そのキー — そしてそのキーだけ — がそのポリシーでスクリーニングされます。 これにより、ひとつのワークスペースが異なるキーで異なるポリシーを実行できます：
  • 厳格な pii-blocker にバインドされた本番キー、
  • より軽い flag-only ポリシーにバインドされたステージングキー、
  • 何もアタッチされていない内部キー。
バインディングはゲートウェイのキー上に存在するため、ガードレールを編集すると バインドされたキーが次のリクエストで反映されます。あなたのアプリケーションは 以前と全く同様に https://api.orcarouter.ai/v1/chat/completions を呼び出し 続けます。
リレーキー（sk-orca-…）はあなたのアプリが送信するものです。それにガードレールを アタッチするのは、あなたのセッションで認証されるコンソール / トークン API アクションです — リレーキー自体でガードレールを設定することは決してありません。

​
2. コンソールでアタッチする

コンソールからバインディングを設定します（ロールゲート：キーとガードレールの編集には Developer+ が必要）。
1

キーを開く

/console/token に移動し、スクリーニングしたい API キーを作成または編集します。
2

ガードレールを選ぶ

キーエディタで、Guardrail ドロップダウンからガードレールを選びます。 これはキー上に guardrail_id を設定します。
3

保存する

バインディングはそのキーの次のリクエストで有効になります。再デプロイ不要。
その後、バインドされたキーでの通常のリレー呼び出しは自動的にスクリーニングされます： 
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"}
    ]
  }'
バインドされたガードレールが入力ステージで email をマスクする場合、アップストリーム モデルは [EMAIL] を見て、アドレスを決して見ません — 同じ呼び出し、クライアント 変更なし。
ひとつではなくワークスペースのすべてのキーをスクリーニングするには、各キーを バインドするのではなくガードレールをワークスペースデフォルトに設定します。 アカウントデフォルトガードレールを参照。

​
3. 解決が有効なガードレールをどう選ぶか

すべてのリクエストで、ゲートウェイはこの順序で正確にひとつの有効な ガードレール（または none）を解決します：
キーの guardrail_id がガードレールを指し、かつそのガードレールが 存在し、かつ有効である場合、それが適用されます。明示的アタッチメントは 権威的です — ワークスペースデフォルトに決してサイレントにフォールバックしません。
キーにアタッチメントがない場合（guardrail_id が 0 / 未設定）、設定 されていればワークスペースの有効なデフォルトガードレールが適用されます。
強制なし。リクエストはこの機能を一度も有効化していないワークスペースと バイト単位で同一です — 何もブロック、マスク、ログ記録されません。
判定はホットパス上のひとつのインデックス付きルックアップであり、フェイルオープン です：解決が一時的なエラーに遭遇した場合、ゲートウェイはリクエストを失敗させる のではなく強制なしに劣化します。安全性は劣化しますが、可用性は維持されます。

​
4. オフスイッチ：アタッチメントを無効化、フォールバックなし

これは人々が見落とす部分です。明示的なキーアタッチメントはそれ自体が権威です — そのためアタッチされたガードレールを無効化すると、そのキーの強制が OFF に なり、ワークスペースデフォルトにフォールバックしません。
キーの状態何がリクエストをスクリーニングするか
guardrail_id → 有効なガードレールそのガードレール
guardrail_id → 無効なガードレール何もなし（フォールバックなし）
guardrail_id → 削除済み / 欠落何もなし（フォールバックなし）
guardrail_id = 0 / 未設定ワークスペースデフォルト（あれば）
アタッチされたガードレールの無効化はそのキーのオフスイッチであって、 デフォルトへのダウングレードではありません。キーをワークスペースデフォルトに フォールバックさせたい場合は、そのアタッチメントをクリアします（guardrail_id を 0 に設定）— それが指すガードレールを単に無効化するのではなく。
これはファイアウォールとの意図的な違いです：無効化された アタッチ済みファイアウォールポリシーを持つキーはワークスペースデフォルトの ファイアウォールポリシーにフォールバックしますが、無効化されたアタッチ済み ガードレールは none に解決されます。同じ考え方、逆のフォールバック — ガードレール vs. ファイアウォールを参照。

​
5. バインディングをデタッチまたはクリアする

特定のガードレールでキーをスクリーニングするのを止めるには、異なる結果を持つ 2 つの異なる手があります：
  • アタッチメントをクリアする — キーの guardrail_id を 0 に設定します。 キーは（存在すれば）ワークスペースデフォルトに、なければ none に解決されます。
  • ガードレールを無効化する — ガードレールの enabled をオフに切り替えます。 それに明示的にアタッチされたすべてのキーは（§4 のとおり）none に解決され、 一方それをワークスペースデフォルトとして頼っていたキーは強制なしに流れ落ちます。
キーをワークスペースベースラインに乗せたいときはクリアを、その名前付き アタッチメントである場所すべてでポリシーを一時停止したいときは無効化を 選びます。

​
6. スクリーニングされたリクエストにかかる（かからない）コスト

ガードレールが解決すると、そのルールがリクエストを決定します。バインドされた キーについて知っておく価値のある 2 つの結果：
  • block は、発火したガードレールとルールを示しつつ、エラーコード guardrail_blocked とともに HTTP 400 を返します。クォータは消費されません — 入力ステージのブロックはメータリングの前に発火し、出力ステージのブロックは 事前消費されたクォータを返金します — そして skip-retry とマークされます。
  • mask はマッチを型付きタグ（例：[EMAIL]）に書き換え、サニタイズされた リクエストを通します。アップストリームモデルが元のものを目にすることはありません。
正確なレスポンス形状については guardrail_blocked エラー ページを、ストリーミングされたレスポンスで出力ルールがどう振る舞うかについては ストリーミングカバレッジを参照 してください。

​
7. 次にどこへ

最初のガードレールを作成する

キーにバインドするポリシーを構築します。

アカウントデフォルトガードレール

ワークスペースのすべてのキーを一度にスクリーニングします。

ガードレールリファレンス

ルールの種類、アクション、ステージ、PII、judge、グラウンディング。

キー、ポリシー、ワークスペース

バインディングがゲートウェイ全体でどうスコープされるか。