メインコンテンツへスキップ
自律エージェントにとって最も安全な姿勢はデフォルト deny です：デフォルトで すべてのツールをブロックし、それからエージェントが使うことになっているひと握りだけを 明示的に許可します。エージェントが新たに拾うもの — コミュニティスキル、設定を誤った MCP サーバー、jailbreak がモデルに使わせたツール — は、ブロックを覚えていたからでは なく、決してオプトインしなかったから deny されます。 このページは api.orcarouter.ai 上でのエージェントのツール許可リストパターン です：deny デフォルト判定に加え、tool_name_glob をキーとする 1 つ以上の allow ルールです。それらのルールの背後にある完全な マッチング言語については、ファイアウォールルールを 参照してください。
許可リストはコンソールの Security → Firewall のもとで、または /api/workspace/firewall/* 管理ルート（セッション / アクセストークン — リレーの sk-orca-… キーではありません）経由で作成されます。エージェントの /v1/* 呼び出しのみがリレーキーを使います。ポリシーの作成または編集は Developer+ の アクションです。

​
1. なぜエージェントにデフォルト deny か

ブロックリスト（「shell.exec を deny、db.delete を deny、…」）は、あなたが思いついた 最後の脅威の分だけしか完全になりません。許可リストは立証責任を反転させます：ゲート ウェイはポリシーが明示的に許可しないものすべてを deny するため、未知のツールは構造的に 閉じられます。

デフォルト判定 = deny

ポリシーの床。どのルールもマッチしなければ、すべてのツール呼び出しがブロック されます。

allow ルールがツールをオプトインで戻す

各 allow ルールは、実際に使うツールを名指しします — 正確な名前またはグロブで。
エンジンはポリシーのルールを優先度順に辿り、最初にマッチしたものが勝ちます； 何もマッチしなければポリシーの default_verdict に落ちます。したがって許可リストは ただこうです：実際のツールに対する高優先度の allow ルールと、それ以外すべてを 捕捉する deny の床です。

​
2. 例 1 つ：リサーチエージェントのツールを許可リスト

エージェントが Web 検索とナレッジベースからの読み取りだけを必要とするとします — web.search と kb.read という名前のツールです。それ以外すべて（シェル、ファイル 書き込み、データベース変更、プロンプトインジェクションが呼び出すかもしれない任意の ツール）は deny されなければなりません。 ポリシーをデフォルト deny + 2 つの allow ルールとして構築します：
1

deny デフォルトでポリシーを作成する

Security → Firewall → Policies → New policy。名前を付け、Enabled を オンのままにし、デフォルト判定を deny に設定します。これが閉じた床です — ポリシーの作成を参照。
2

ツールファミリーごとに allow ルールを追加する

ルールエディタで 2 つのルールを追加します。両方 verdict = allow：
prioritytool_name_globverdict
10web.searchallow
20kb.*allow
web.search は正確なマッチです；kb.* は プレフィックスグロブで、ポリシーを 再編集せずに kb.read、kb.search、そして将来の任意の kb.* ツールを許可します。
3

エージェントのキーにアタッチする

キーの firewall_policy_id をこのポリシーに設定します（またはワークスペース デフォルトにします）。エージェントのリクエストボディは変わりません。
これで web.search と kb.read は通り；shell.exec への呼び出しはどの allow ルール にもマッチせず、deny の床に当たり、inbound サーフェスでコード firewall_blocked の HTTP 400 として返ってきます — ブロックがどう見えるかを参照。
allow ルールは正確な名前または狭いプレフィックス（kb.*）として作成し、広い サフィックスにはしません。緩い *.read は kb.read と secrets.read を許可します — 許可リストの目的の正反対です。ツール命名が許す限りグロブを締めてください。

​
3. グロブを 1 画面で

tool_name_glob は小さく、大文字小文字を区別する文法です — 正規表現なし、線形時間。 許可リストにとって重要な形：
パターン許可するもの
web.search正確にそのツール。
kb.*プレフィックス — kb.read、kb.search（裸の kb は不可）。
*.searchサフィックス — web.search、kb.search、そして裸の search。
*.tools.*インフィックス — byo.tools.fetch など。
完全な文法（インフィックスルール、エッジケース、スキル名グロブ）については、 グロブ構文と ファイアウォールルールリファレンスを 参照してください。
*.suffix グロブは裸の、名前空間化されていない動詞にもマッチします — *.search は web.search だけでなく、文字どおり search という名前のツールも許可します。プロバイダや 名前空間化しない MCP サーバーは裸の動詞でツールを公開するため、許可リストされた サフィックスは見た目より広いです。締まった許可リストが欲しいときは、正確な名前または プレフィックスを優先してください。

​
4. エージェントを壊さずにロールアウトする

デフォルト deny は、必要だと忘れていたツールをブロックする可能性が最も高い姿勢です。 段階的に進めます：
シャドウモードをオンにします。ポリシーは ライブと全く同様に評価しログを取りますが、すべての deny を audit に格下げし、理由に [shadow] would … を前置します。実トラフィックを流し、それから events フィードを 読みます。
Discovered tools はワークスペースが見た すべてのツールを、covered または gap とフラグしてリストします。シャドウ モードの「would-deny」イベントとギャップが、まだ必要な allow ルールが正確にどれかを 教えてくれます。
Test サンドボックスはサンプルのツール呼び出しに 対してポリシーをドライランし、判定、マッチしたルール、理由を返します — 何も ディスパッチも永続化もされません。web.search が許可され shell.exec が deny される ことを確認してから、シャドウをオフにします。
deny された inbound 呼び出しはモデルトークンを消費しません — アップストリームの モデルが実行される前にブロックされます — そして skip-retry とマークされるため、 ブロックされたツールが再ブロックで再試行予算を燃やすことはありません。 判定を参照。

​
5. 次に進む場所

特定のツールをブロック

逆 — デフォルト allow の床を保ち、名指しのツールを deny。

引数の検証

ツールを許可しつつ、安全な引数のときのみ（db.query だが DROP TABLE は不可）。

ルール優先度

最初にマッチしたものが勝つが、どう allow ルールを deny の床の上に並べるか。

判定

allow、audit、deny、sanitize、pending_approval、cap_cost。
このパターンが対処する脅威については、 過剰なエージェンシーと 危険なツール呼び出しを参照してください。 デフォルト deny がなぜエージェントのベースラインなのかについては、 ゼロトラストの理由を参照してください。