メインコンテンツへスキップ
エージェントが乗っ取られたとき — プロンプトインジェクション、汚染されたツール結果、暴走ループ — それが実際にできることは、ただひとつのことによって境界づけられます：その API キーが何を することを許されていたか。制限もポリシーもないキーは、ひとつの侵害されたエージェントを ワークスペース全体のインシデントに変えてしまいます。 このページは、すべてのキーを出荷前に、そしてその後も定期的に実行する強化パスです。意図的に 短くなっています：1 つのチェックリスト、1 つの実践例、それから各フィールドの詳細へのリンク。 その背後のメンタルモデルについては、 スコープとキーから始めてください； フィールドごとのリファレンスについては、キー概要を参照してください。

​
1. 最小権限チェックリスト

すべてのキー — 新規または既存 — を、キーエディタ（/console/token）でこれら 6 つのゲートに 通します。それらのいずれかを設定するには Developer ロール以上が必要です；2 つのポリシー プレーン（§5–6）は別途作成され、ここでバインドされます。
model_limits をこのエージェントが必要とする正確なリストに設定します（そして model_limits_enabled を有効化します）。リスト外の任意のモデルへの呼び出しは、ゲートウェイを 離れる前に拒否されるため、乗っ取られたエージェントはより高価あるいはより高性能なモデルに エスカレートできません。 チェック： リストは仕事が許す限り短いか — 理想的には 1 つのモデルか？ 詳細：モデル制限。
allow_ips を、エージェントが実際に呼び出すソースアドレスまたは CIDR に設定します。それ以外の どこからか提示された漏洩キーは認証層で拒否されます。空はすべてのIP が許可を意味します。 チェック： 固定ホストまたはスケジュールエージェントについて、リストは空でなく、その egress にスコープされているか？ 詳細：IP 許可リスト。
credit_limit_usd を、エージェントが生涯で決して超えるべきでない上限に設定します。 ゲートウェイはそれをキーの支出に対して強制します。0 は無制限を意味します — 暴走ループが あなたの残高全体を枯渇させ得ます。 チェック： 上限は 0 ではなく、実際の予算か？ 詳細： クォータ、上限、失効。
expired_time を絶対的な失効 — スプリント、デプロイ、あるいは CI 実行の終了 — に設定します。 -1 は決して失効しないを意味します。短命キーは忘れられた攻撃面として居座れません。 チェック： 一時的または委託先のキーは、-1 ではなく実際の失効を持つか？ 詳細： 失効するキー。
ガードレールを guardrail_id 経由でアタッチして、リクエスト （そして、サポートされる場合はレスポンス）テキストが、モデルに到達する前に PII、シークレット、 インジェクション意図についてスクリーニングされるようにします。 チェック： 機密プロンプトを扱うキーは、ガードレールがバインドされているか、あるいは ワークスペースデフォルトを継承するか？ §5 を参照。
ファイアウォールポリシーを firewall_policy_id 経由でアタッチして、 このキーが発行するすべてのツール呼び出し、MCP ディスパッチ、egress が、エージェントが正当に 必要とするものの許可リストに対して評価されるようにします。 チェック： ツールを呼ぶエージェントは、ファイアウォールポリシーがバインドされているか、 あるいはワークスペースデフォルトを継承するか？ §6 を参照。
上のフィールドは、キー上の唯一の顧客が設定可能なレバーです — それらをすべてコンソールで 設定してください；ここに何もエージェントのコード変更を必要とするものはありません。キーを読み 戻すとマスクされて表示されます；平文は作成時に一度表示されます。 キーマスキングを参照。

​
2. 何を / どのくらいの頻度で / どこで

3 つの問いが、チェックリストを一度きりの雑用から姿勢へと変えます。

何を

上の 6 つのゲート、順番に：model_limits → allow_ips → credit_limit_usd → expired_time → guardrail_id → firewall_policy_id。

どのくらいの頻度で

作成時のすべてのキーで、そして定期的なレビューで — エージェントのスコープが変わる とき、キーをローテーションするとき、そして長命キーについては 固定のペースで。

どこで

コンソールのキーエディタ（/console/token）で、Developer+ として。2 つのポリシーは それぞれ独自のコンソールで作成され、それからキー上でバインドされます。

​
3. ひとつの具体的な最小権限キー

1 つの安価なモデルで、1 つのホストからサポートチケットを要約するスケジュールエージェントは、 ほとんど権限を必要としません。完全に強化されたキー：
フィールド値理由
model_limits1 つの要約モデルフロンティアモデルにエスカレートできない
allow_ipsスケジューラの egress CIDR漏洩キーは他の場所では役に立たない
credit_limit_usd週次の上限暴走ループが残高を枯渇させられない
expired_timeデプロイの終了自動失効、居座れない
guardrail_idPII マスキングガードレールリクエストテキストがスクリーニングされる
firewall_policy_idそのツールのみ許可リスト化想定外のツール呼び出しがない
このエージェントが乗っ取られても、依然として 1 つのモデルしか呼べず、1 つの IP レンジからしか 呼べず、上限までしか呼べず、ファイアウォールポリシーが許可するツールしか呼べません。 ワークスペースの残りは無傷で — ファイアウォール監査証跡が、それが何をすることを認可されて いたかを正確に示します。
model_limits も allow_ips もなく、credit_limit_usd: 0、expired_time: -1、そして ポリシーアタッチメントもないキーは、最大の権限を持ちます。それが漏洩すれば、保持者は あなたのワークスペース全体を手に入れます。その組み合わせをデフォルトではなく発見として扱って ください — 無制限 vs 境界づけを参照。

​
4. /v1 リレー呼び出し vs コンソール

チェックリストは、あなたのセッション（Developer+ ユーザー）でコンソール内で設定されます。 あなたのエージェントはそれらの設定ルートに決して触れません — /v1/* 推論呼び出しでその スコープ付きリレーキー（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..."}]
  }'
キーの model_limits に openai/gpt-4o-mini が含まれない場合、この呼び出しはゲートウェイを 離れる前に拒否されます。呼び出し元の IP が allow_ips にない場合、認証層で拒否されます。 エージェントコードは同じまま；キーが被害範囲を決定します。

​
5. ゲート 5 — バインドされたガードレール

guardrail_id は、ワークスペーススコープの順序付きコンテンツポリシーをキーにバインドします。 解決は、キーの明示的なガードレール（存在し有効な場合）、それ以外はワークスペースデフォルト、 それ以外はなし、です。
ガードレールは、無効化されたときの厳格なオフスイッチです：無効化または削除された guardrail_id は、キーがいかなるガードレールも得ないことを意味します — ワークスペース デフォルトにフォールバックしません。これはファイアウォールプレーン（§6）の正反対なので、 バインドされたガードレールが単にアタッチされているだけでなく、有効であることを検証してください。
ガードレールのルールは、モデルの前（入力ステージ）に、そして、サポートされる場合はレスポンスに （出力ステージ）、アクション block、mask、flag で実行されます。例えば PII Shield プリセットは、リクエストがモデルに到達する前に PII をマスクします。ガードレールを Developer+ として作成しアタッチしてください — ガードレールと ポリシーをバインドを参照。

​
6. ゲート 6 — バインドされたファイアウォールポリシー + ゲートウェイスコープ

firewall_policy_id は、ワークスペーススコープのツール呼び出しポリシーをバインドします。 それはエージェントが取るアクション — アドバタイズされるツール、モデルが発行する tool_calls、 MCP ディスパッチ、そしてアウトバウンド egress — を、判定が allow、audit、deny、 sanitize、pending_approval、cap_cost である順序付きルールリストに対して統制します。
ファイアウォールプレーンはガードレールと異なる解決をします：無効化されたアタッチ済み ファイアウォールポリシーはワークスペースデフォルトにフォールバックし、強制をオフにはしません。 なのでポリシーをバインドして無効化すると、キーはワークスペースデフォルトに戻ります — 決して サイレントに無防備にはなりません。
両方のプレーンを一度に設定する最速の方法は自律性レベルです — ワークスペースのファイアウォール およびガードレールの姿勢（tight / balanced / permissive）をアトミックに設定する単一の スイッチで、ワンクリックの取り消しを伴います。 ファイアウォール §8を 参照。
is_firewall_gateway は別種のキーです — ファイアウォール MCP と evaluate フックのルート （/api/v1/firewall/*）のためにのみ発行され、推論のためには決して発行されません。通常のキーは それらのルートで 403 を受け取り、推論パス上のゲートウェイキーは過剰スコープです。フラグを 有効化すること、そしてゲートウェイキーの平文を読むことには Admin+ が必要です。1 つのキー、 1 つの目的。

​
7. チェックリストの後

セキュアエージェント ベースライン

推奨される開始姿勢 — 1 つの自律性スイッチ、それから実トラフィックからチューニング。

ポリシーをバインド

guardrail_id と firewall_policy_id がどうアタッチされ解決するか。

過剰な権限

このチェックリストが封じ込めるために作られた脅威。

漏洩キー

スコープ付きキーが露出した瞬間に何をすべきか。
各キーが狭いほど、どれかひとつのエージェントが侵害されたときの被害範囲は小さくなり — そして 各エージェントが何を認可されていたかの記録は明確になります。すべてのキーで最小権限 チェックリストを実行し、実行し続けてください。