メインコンテンツへスキップ
1 つの API キーは、あなたのワークスペースが権利を持つすべてのモデルに到達できます。 それはコンソールセッションには便利ですが、長命のエージェントには危険です：プロンプト インジェクションされたエージェントが無制限のキーを持っていると、gpt-4o-mini から、 あなたがアクセスできる最も高価なモデル、あるいはデータ取り扱いを一度も承認していない モデルへ、ひそかに切り替えられます。 修正策は、キーごとのモデル許可リストです。各キーは model_limits フィールド （model_limits_enabled でゲート）を運びます。それがオンのとき、リストにないモデルへの リクエストはゲートウェイで拒否されます — チャネルが選択される前、そして何かがプロバイダへ 向けて離れる前です。
これはキーオブジェクト上の 1 つの制約です。キーの IP 許可リスト、支出上限、失効、そしてアタッチされたガードレール / ファイアウォールポリシーと 組み合わさり — それぞれが独立してキーを狭めます。

​
1. なぜ API キーごとにモデルアクセスを制限するのか

モデル選択は権限のレバーです。任意のモデルを呼べるキーは、次へと誘導され得ます：
  • コスト爆発 — プレミアムモデルへの切り替えはトークンあたりの請求を倍増させます。
  • 能力クリープ — 小さなモデル向けにスコープされたタスクが、意図したよりはるかに 多くをこなせるフロンティアモデルにルーティングされます。
  • コンプライアンスドリフト — 特定のデータクラスについて承認していないモデルファミリに トラフィックを送る。
キーをエージェントが実際に必要とする 1 つか 2 つのモデルに制限することで、3 つすべてを 一度に塞ぎます。それは、ツールを許可リスト化するファイアウォールのモデル軸版です — エージェントはあなたが名指ししたものにしか到達できず、それ以外には何も到達できません。

​
2. 2 つのフィールド

モデル制限はペアでキー上に存在します：
フィールド型意味
model_limits_enabledboolマスタースイッチ。false のとき、キーはワークスペースが許可するすべてのモデルに到達します。
model_limitslistモデル名の許可リスト。model_limits_enabled が true のときのみ意味を持ちます。
2 つのフィールドは独立しており、その組み合わせが重要です：model_limits_enabled = true で空のリストは、キーがいかなるモデルにも到達できないことを意味します — すべての リクエストが “This token has no access to any models.” で拒否されます。少なくとも 1 つの モデルを名指ししてから、初めてスイッチをオンにしてください。

​
3. キーに設定する

モデル制限は、キーの他の制約を設定するのと同じ場所、コンソールのキーエディタ （/console/token）で設定します。キーの作成または編集には Developer ロール以上が 必要です。
  1. キーを開く（または Create key）。
  2. Model limits を有効化する。
  3. このキーが呼んでよいモデルを選ぶ — 入力してワークスペースの利用可能なモデルを フィルタします。
  4. 保存。変更はキーの次のリクエストで反映されます — 再デプロイなし、キー ローテーションなし。
1 つの安価なモデルにしか触れるべきでないスケジュール要約器は、ちょうど 1 エントリの 許可リストに行き着きます： 
model_limits_enabled: true
model_limits:         ["openai/gpt-4o-mini"]
その時点から、キーは gpt-4o-mini に固定されます。このキーからのリクエスト上の他のどの モデル名も拒否されます — デフォルトモデルへのフォールバックもサイレントなダウングレードも ありません。
モデル制限を、同じキー上の credit_limit_usd 上限とペアにしてください。モデルリストは 暴走ループがどのモデルに到達できるかを境界づけ；支出上限はキーが動作を停止する前に どれだけ燃やせるかを境界づけます。2 つの独立した上限、どちらもゲートウェイで強制されます。 クォータ上限と失効を参照。

​
4. 拒否されたリクエストがどう見えるか

model_limits_enabled がオンで、リクエストがリスト外のモデルを名指しすると、ゲートウェイは HTTP 403 と OpenAI 形式のエラーボディでリクエストを中断します： 
{
  "error": {
    "message": "This token has no access to model claude-opus-4-8 (request id: 2024...abc)",
    "type": "orcarouter_api_error",
    "code": ""
  }
}
この拒否の主要な特性：
チェックはゲートウェイがまだチャネルを選んでいる間に実行されます — リクエストは アップストリームのプロバイダに決して到達しないため、禁止されたモデルはモデルトークンを 消費しません。
スイッチがオンで空の許可リストの場合、メッセージは “This token has no access to any models” となり、すべてのリクエストが拒否されます。これが「リストに制限する」と 「キーを推論から完全に締め出す」の違いです。
リクエストのモデル名はリストがチェックされる前に正規化されるため、関連するバリアント （例：thinking バリアント）は、あなたが許可リスト化したのと同じ正規名に解決されます。 コンソールが表示するベースモデル名をリストしてください。

​
5. モデル制限 vs グループ権利

キーがモデルを呼べるかどうかを決めるのは、2 つの異なるものです。混同しないでください：
層スコープそれが答える問い
ワークスペース権利ワークスペースこのモデルはそもそもワークスペースに利用可能か？
model_limits単一のキー利用可能なモデルのうち、この キーはどれを使ってよいか？
model_limits は常に狭めるだけです。キーはモデル制限を使って、ワークスペース自体が 権利を持たないモデルに到達することはできません — すでに許可されているものから、より小さな 許可リストを切り出せるだけです。キーに何も追加せず、厳密により少なく与えるには、それが まさにこのフィールドの用途です。

​
6. 最小権限姿勢へのフィット

モデル制限は、エージェントごとのキーレシピの 1 行です。自律エージェント向けの最も狭い 有用なキーは、そのすべての軸を一度に固定します： そのようなキーがプロンプトインジェクションで 侵害されたとき、被害範囲はすべての軸で境界づけられます — 攻撃者があなたの予算を費やせる モデルを含めて。
モデル制限はキー上のアイデンティティ制約であり、コンテンツやアクションのポリシーでは ありません。プロンプトを検査することも（それはガードレール）、 ツール呼び出しを検査することも（それはファイアウォール）ありません — それらは前もって、キーがそもそもどのモデルに宛ててよいかを決定します。

​
7. 次のステップ

キーオブジェクト

キーが運ぶすべてのフィールド — モデル制限、IP リスト、上限、失効、ポリシー アタッチメント — を 1 つのリファレンスに。

最小権限チェックリスト

エージェントごとの完全なキーレシピ：すべての軸をエージェントが必要とする最小に スコープします。

スコープ、キー、ポリシー

キー、ガードレール、ファイアウォールポリシーがどのように 1 つのエージェント アイデンティティへとバインドされるか。

キーにポリシーをバインド

ガードレールとファイアウォールポリシーを同じキーにアタッチします。
API キーごとにモデルアクセスを制限することは、適用できる最も安価な権限コントロールです： 1 つの許可リスト、ゲートウェイで強制され、どんな侵害されたエージェントも口先で回避できません。