メインコンテンツへスキップ
ソース制限のないキーは、純粋なベアラー資格情報です：その文字列を持つ者は誰でも、どこからでも それを提示できます。allow_ips フィールドは、キーを IP ホワイトリスト API キーに変えます — あなたがリストしたソースアドレスから提示されたときだけ機能します。攻撃者のマシン、住宅用 プロキシ、あるいは侵害された CI ランナーから再生された漏洩キーは、モデルに触れる前に拒否 されます。 これは最小権限のソースバインディング側の半分です： model_limits はキーが到達してよいどのモデルかを 上限設定し、allow_ips はキーがどこから提示されてよいかを上限設定します。

​
1. allow_ips が行うこと

allow_ips はソースアドレスまたは CIDR レンジのリストを保持します。すべてのリクエストで、 OrcaRouter は呼び出し元のソース IP をそのリストと照合します：
  • マッチ → リクエストはモデル制限、クォータ、ポリシーのチェックへ進みます。
  • マッチなし → リクエストは、いかなるアップストリームのモデル呼び出しの前にも、 認証層で HTTP 403（access_denied）で拒否されます。
  • 空のリスト → 制限なし；キーは任意のアドレスから受け入れられます。
このチェックはキーが通過する最初のゲートであり、キーの有効性と並んで — ガードレールの前、 ファイアウォールの前、課金の前に実行されます。リストにないソースは、あなたのポリシーにも 残高にも決して到達しません。
空の allow_ips はすべての IP が許可を意味し、なしではありません。空白のままにする ことが無制限のデフォルトです — フィールドに何か働かせるにはキーを固定してください。

​
2. 受け付ける形式

各エントリは 1 つの IP または CIDR レンジです。両方を自由に混在；1 行につき 1 エントリ をリストします。

単一アドレス

203.0.113.7 — 正確に 1 ホスト。固定 IP のサーバーや、安定した egress アドレスを持つ NAT ゲートウェイに最適。

CIDR レンジ

203.0.113.0/24 — ブロック全体。クラウドサブネット、VPN プール、あるいは 1 つの egress CIDR の背後のオートスケーリンググループに最適。
裸の IP はその 1 アドレスにマッチします；CIDR はブロック内のすべてのアドレスにマッチします。 IPv4 と IPv6 のリテラルの両方がパースされます。
すべての正当な呼び出し元をなおカバーする最も狭いレンジに固定してください。1 ホスト （/32）は /24 より厳しい；/24 は「どこでも」より厳しい。落とすビットごとに、漏洩キーが 依然として機能する場所の集合が広がります。

​
3. コンソールで設定する

allow_ips を /console/token のキーエディタで設定します。キーの作成または編集には Developer ロール以上が必要です。
  1. Console → API Keys を開き、キーを作成または編集します。
  2. キーエディタで、信頼できるアドレスを IP allow-list フィールドに入力します — 1 行 につき 1 つの IP または CIDR。
  3. 保存。制限はそのキーが行う次のリクエストで適用されます — 再デプロイなし、 エージェントのコード変更なし。
キーをロックダウンする前に、ゲートウェイが見る実際のソースアドレスを検証してください。 エージェントが NAT、ロードバランサー、あるいは egress プロキシの背後にある場合、OrcaRouter が観測するアドレスはその egress ホップ — エージェントのプライベート IP ではありません。 egress アドレスを許可リスト化し、出荷前にデプロイ済み環境からテストしてください。

​
4. ひとつの具体例：スケジュールエージェント

チケットを要約するスケジュールジョブが、1 つのクラウドサブネットからのみ実行されます。 その資格情報が他のどこでも役に立たないよう、キーをそのサブネットに固定します。
フィールド値効果
allow_ips203.0.113.0/24スケジューラの egress ブロックだけがこのキーを提示できる
model_limits1 つの要約モデルフロンティアモデルにエスカレートできない
credit_limit_usd週次の上限暴走ループが残高を枯渇させられない
リレー呼び出し自体は変わりません — 依然として sk-orca-… キーをベアラートークンとして使います： 
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": "Summarize this ticket..."}]
  }'
203.0.113.0/24 の内側から提示されると、呼び出しは進みます。全く同じリクエストを他の任意の アドレスから再生すると、ゲートウェイは次を返します： 
{
  "error": {
    "message": "您的 IP 不在令牌允许访问的列表中 (request id: ...)",
    "type": "orcarouter_api_error",
    "code": "access_denied"
  }
}
モデルは決して呼ばれず、クォータは消費されず、拒否はログされます。
allow_ips は完全にコンソールのキーエディタを通じて設定されます — あなたのワークスペース セッション上の Developer 以上のアクションです。それに対するリレーキーのセルフサービスは ありません：キーは自身のソース許可リストを広げられません。

​
5. IP 許可リストが含むものと含まないもの

IP ホワイトリスト API キーは、キーがどこで機能するかを境界づけます — 被害範囲の 1 スライス です。それは他のスコープフィールドを置き換えるのではなく、それらと組み合わさります。
ログ、git コミット、あるいは侵害されたラップトップから流出した資格情報は、攻撃者が あなたの許可リスト化されたレンジからもトラフィックを発生させられない限り、無価値です。 これがこのフィールドの中核の仕事です — 完全なインシデント対応については 漏洩キーを参照。
侵害が許可リスト化されたホストそのもの — あなた自身のサーバー上で実行される汚染された 依存関係 — である場合、ソース IP チェックは通過します。allow_ips を model_limits、 支出上限、そして ファイアウォールポリシーとペアにして、信頼できるソースの侵害も なお境界づけられるようにしてください。
IP 固定はキーを短命にしません。それを絶対的な失効と ローテーションスケジュールと組み合わせて、キーが新しい場所 から機能を停止しかつ最終的に機能を停止するようにしてください。

​
6. 運用上の注意

呼び出し元が安定したソースアドレスを持たない場合（egress がローテーションする サーバーレス、モバイルクライアント、広いオフィスネットワーク）、IP 固定は誤った コントロールです — 実トラフィックを締め出すか、レンジが無意味になるまで広げるかの どちらかになります。代わりに model_limits、支出上限、 失効、ポリシーアタッチメントに頼ってください。
allow_ips の編集は次のリクエストで反映されます — 待つべき伝播遅延はありません。 リージョンを追加したりサブネットを移行したりするときは、まずキーを更新し、新しいレンジが 機能することを確認してから、古いものを落としてください。
allow_ips は個々のキー上に存在するため、各エージェントが独自のソースバインディングを 持てます。スケジューラキーはバッチサブネットに固定でき、インタラクティブキーはより広い オフィスレンジを許可できます — どちらも同じワークスペース内で。

​
7. 次のステップ

トークンオブジェクト

allow_ips を含む、キー上のすべてのフィールドを 1 つのリファレンスに。

モデル制限

キーが到達してよいモデルを上限設定 — ソース + スコープバインディングのもう半分。

漏洩キー

キーが露出した瞬間に何をすべきか。

最小権限チェックリスト

すべてのキーを同じ強化パスに通す。
IP 許可リストは、できる最も安価な被害範囲の削減です：1 つのフィールド、コード変更なし、 そして漏洩キーは、本来実行されるべきでなかったすべての場所から機能を停止します。詳細な 防御のために、それをスコープ付きキーモデルの 残りとペアにしてください。