メインコンテンツへスキップ
エージェントが危険なことをするのを止める最速の方法は、ツールを名指しして deny する ことです。ツール名グロブ上の deny 判定はエージェント ファイアウォールの deny リストのプリミティブです： 1 つのルール、1 つのグロブ、判定 deny、キーにアタッチ — それ以降ゲートウェイは すべての呼び出しでそのツールを拒否します。エージェントコードの変更はありません。 このページは deny リストのユースケースと、それが強いる 1 つの決定をカバーします： どのサーフェスでブロックするか — アドバタイズするツール（inbound）か、モデルが 発行するツール呼び出し（response）か。完全なマッチング語彙と判定セマンティクスに ついては、ルールスキーマと 判定を参照してください。

​
1. AI エージェントが行うツール呼び出しをブロックする

deny リストルールは、ファイアウォールポリシーが表現できる最もシンプルなものです： ツールを名前でマッチし、deny を返します。あるキーに対してツールが決して発火しては ならないとき — shell.exec、*.delete、信頼しないコミュニティプラグイン — 引数に 関わらず使います。 ワークスペースコンソールでポリシーを開き（または作成し）、 ルールを追加します： 
{
  "label": "block destructive shell",
  "tool_name_glob": "*.exec",
  "verdict": "deny"
}
tool_name_glob は小さく、大文字小文字を区別するグロブです — shell.* は ファミリー全体を捕捉し、*.delete はサーバーをまたいで動詞を捕捉し、* はすべてを 捕捉します。引数句は不要です：裸のグロブ + deny はツールを無条件にブロックします。 ツールを一般的に許可しつつ 1 つの形の呼び出しを deny したいときのみ、 引数句を追加します。
エンジンはポリシーのルールを優先度順に辿り、最初にマッチしたものが勝ちます。 狭い allow 例外を低い priority 番号に置き（それらが先に実行されます）、広い deny を その下に置きます — 例：信頼された builtin.* スキルからの shell.exec を許可し、 それ以外すべてで deny します。ルール優先度を参照。

​
2. inbound vs response：サーフェスを選ぶ

deny はリクエストライフサイクルの 2 つの異なるポイントで着地でき、その違いは重要です。 stage フィールドでルールを固定するか、空にして両方をカバーします。

inbound

エージェントがリクエストでモデルにアドバタイズするツール（ツール定義）。 ここでの deny は、モデルがそれを選択できる前にツールを剥がします — モデルは オプションとしてそれを決して見ません。

response

モデルがその返信で発行する tool_calls。ここでの deny は、モデルがすでに 行うことを決めた呼び出しを、ツールに到達する前に捕捉します。
ツールを不可視にしたいときは inbound を優先します — モデルは提供されなかった ものを呼び出せないため、ツールを選んだだけで拒否されるという無駄なターンを回避します。 ツールが一部のリクエストに正当に現れ、実際に発行された呼び出しを捕捉したいとき、または エージェントループのみを制御しアドバタイズされるツールセットを制御しないときは、 response を使います（または stage を空のままにします）。
stage のないルールはすべてのサーフェスに適用されます — 同じ deny が、ツールが アドバタイズされようと、発行されようと、MCP 経由でディスパッチ されようとカバーします。それがベルト＆サスペンダーのデフォルトです；deny を 1 つに スコープすべきときのみサーフェスを固定します。ステージを参照。

​
3. ポリシーをアタッチして発火を見る

ポリシーはキーがそれに解決するまで何もしません。コンソールで キーに firewall_policy_id を設定して アタッチするか、ポリシーをワークスペースデフォルトにします。解決は：キーのアタッチ済み ポリシー（存在し有効である場合）、そうでなければワークスペースデフォルト。（無効化 されたアタッチ済みポリシーはデフォルトにフォールバックします — ポリシーの管理を参照。） アタッチされると、inbound サーフェス上の deny された呼び出しはエラーコード firewall_blocked とツールを名指しする理由とともに HTTP 400 を返します — 例：tool "shell.exec" blocked by firewall。エラーは skip-retry とマークされ （同一の呼び出しを再実行してもまたブロックされるだけ）、inbound ブロックはアップストリーム 呼び出しの前に発火するためモデルトークンを消費しません。 MCP ゲートウェイ経由でディスパッチされた deny は代わりに ツールエラーとして表面化するため、モデルは拒否を見て反応できます。
inbound サーフェス上の deny は、モデルに提供されるものからツールを取り除きます。 エージェントフレームワークがアドバタイズしたツールを呼び出し可能であることを要求する 場合、それを inbound でブロックするとループを混乱させる可能性があります — その場合は 代わりに response でブロックし、ツールはアドバタイズされ続けるが実際の呼び出しが 拒否されるようにします。ロールアウト前に違いをテストしてください（§5 を参照）。

​
4. deny はいくつかの判定のひとつ

deny は deny リスト上で最も鈍いツールです。ハードなブロックが過剰なとき、同じグロブが より柔らかい判定を運べます：
判定deny の代わりにいつ手を伸ばすか
auditツールの発火を見たいが、まだブロックしたくない。
sanitizeツールは問題ないがその引数がシークレット/PII を運ぶ可能性がある — 引数をリダクト、ツール結果は決して触らない。
pending_approval人間が各呼び出しを帯域外で承認すべき。
cap_costエージェント実行の支出がセント上限を超えるまで許可。
これらすべては判定で文書化されています。deny リストは ただ判定が deny であるサブセットです。許可リストの姿勢（すべてを deny し、名指しの セットを許可）にするには、ポリシーの default_verdict を deny に切り替え、狭い allow ルールを追加します — ツール許可リストを 参照。

​
5. 安全にロールアウトする

コンソールの Test タブはサンプルのツール呼び出しに対してポリシーをドライランし、 判定、マッチしたルール、理由を返します — 何もディスパッチも永続化もされません。 キーをアタッチする前に、グロブが意図したツール（そしてそのツールのみ）にマッチ することを確認します。ルールのテストを参照。
ポリシーでシャドウモードをオンにすると、 すべての強制判定 — あなたの deny を含む — が audit に格下げされ、理由に [shadow] would … が前置されます。deny が実トラフィックに対して何をブロック するであろうかを正確に測定し、それから強制するためにシャドウをオフにします。
グロブする正確なツール名が分からない？Discovered Tools ビューはワークスペースが 見たすべてのツールを covered または gap とフラグしてリストします。実際に現れた名前 から直接 deny を作成します。分析を参照。
すべての評価は判定、サーフェス、ツール、マッチしたルールを持つファイアウォール イベントを書き込みます。強制した後、events ログを 判定 deny でフィルタし、期待した呼び出しでルールが発火するのを見ます。

​
6. 誰が何をできるか

すべての deny リスト設定はセッション下のコンソールで実行されます （/api/workspace/firewall/*）：
アクションロール
ポリシー、プリセット、discovered tools、Simulate の読み取りMember
ポリシーのドライラン（Test）Developer+
ルールとポリシーの作成 / 編集 / 削除Developer+
events ログと実行集計の読み取りDeveloper+
deny ルールの作成または変更は Developer+ の書き込みであり、コンソールの Test ドライランも同様です。ポリシーの読み取りと読み取り専用の Simulate（「what-if」） ビューはすべてのメンバーに開放されています。

​
関連

グロブ構文

shell.*、*.exec、*.shell.* が正確にどうマッチするか。

ツール許可リスト

逆の姿勢：デフォルト deny、名指しのセットを許可。

引数の検証

ツール全体ではなく、呼び出しの 1 つの形のみを deny。

危険なツール呼び出し

deny リストが対処する脅威。

判定

deny とその柔らかい兄弟がワイヤー上で何をするか。

ファイアウォールリファレンス

完全なルール + マッチングリファレンス。