shell.exec に rm -rf / を、決済 API に過大な
送金額を、本番レプリカを標的にするデータベースツールを。これがエージェントツール乱用であり、
ツール呼び出しはしばしば不可逆な現実世界の副作用を持つため、エージェントシステムにおける
最も重大なリスクのひとつです。
エージェントファイアウォールには 3 つの重層的な防御があります。独立して、または
組み合わせてデプロイできます。
1. 許可リスト：明示的に許可しないものをすべて deny する
最強のコントロールは許可リストです。危険なツールをすべて列挙しようとするのではなく、 このエージェントが正当に必要とするツールを列挙します — そして他のすべてを deny します。 これがゼロトラストのベースラインです。default_verdict: deny と各承認ツールに明示的な allow ルールを持つポリシーがこれを
達成します。例：CRM からのみ読み取るべきエージェント：
shell.exec、db.delete、payment.transfer への呼び出しは — 意図的に発行されたか
インジェクションされた指示によってトリガーされたかに関わらず — * キャッチオールに
ヒットし、HTTP 400 firewall_blocked エラーを返します。エージェントは構造化された
ツールエラーを見て、リトライできません（ブロックは skip-retry とマークされます）、
したがって拒否を回避してループすることができません。
完全な許可リスト強制のためにポリシーの
default_verdict を deny に設定します。
デフォルトの audit 判定では、マッチしない呼び出しは許可されてログされますがブロック
されません — ロールアウト中には有用ですが、それ自体ではセキュリティコントロールでは
ありません。| パターン | カバーするもの |
|---|---|
crm.* | crm 名前空間のすべてのツール |
*.read | すべてのサーバーにわたる任意の read 動詞ツール |
db.query | ちょうどこのひとつのツール |
* | すべて（キャッチオール deny に使用） |
allow ルールを
低い優先度番号に、キャッチオール deny を高い番号に置きます。
2. 引数検証：ツールを許可し、危険な呼び出しをブロックする
ツール名の許可リストは粗いです —shell.exec を完全にブロックします。ツールを
許可しながらどのように呼び出せるかを制限したい場合があります。引数句により、
JSONPath とオペレーターのセットを使用してツール呼び出し引数内の特定のフィールドに
マッチできます。
例：shell.exec を許可するが rm -rf をブロックする
shell.exec が呼び出されかつ $.command 引数が破壊的コマンド
正規表現にマッチする場合にのみ発火します。安全なコマンドを持つ通常の shell.exec
呼び出しは次のルール（またはデフォルト判定）に落ちます。一般的な allow shell.exec
ルールよりも低い優先度番号にこのルールを置いて、最初に発火するようにします。
引数オペレーターの完全なセット：
| オペレーター | 使用タイミング |
|---|---|
eq | スカラー値（文字列または数値）の完全マッチ |
contains | 部分文字列マッチ — 例：$.query が DROP TABLE を contains |
regex | RE2 パターンマッチ — ホットパスで安全、バックトラッキングなし |
in | 値が指定された配列内にある必要 — 例：特定の環境のみを許可 |
cidr_match | IP アドレスが CIDR ブロック内 — egress 宛先チェックに有用 |
gt / lt | 数値比較 — 例：決済上限のために $.amount が gt 10000 |
args_match ブロック内のすべての句は AND で結合されます。パスが呼び出しの引数に
存在しない場合、句は false と評価されルールは発火しません — 呼び出しは次のルール
またはデフォルトに落ちます。
決済ガードの例 — しきい値を超える金額を持つ任意の決済ツール呼び出しを deny：
3. 人間による承認：高リスクの呼び出しを承認のために保留する
デプロイメントのトリガー、払い戻しの承認、バルクメールの送信など、本当に必要だが 高リスクのツールには、呼び出しが進む前に人間の承認を必要とするよう設定できます。pending_approval 判定が呼び出しを保留し、エージェントに firewall_approval_pending
レスポンスを返します：
pending_approval は引数句と互換性があります — しきい値にマッチする呼び出しのみを
保留し、ルーティンなものは通過させることができます：
4. ブロックされた呼び出しがどう見えるか
inbound サーフェスで拒否された呼び出し（リクエストでアドバタイズされたツール）は エラーコードfirewall_blocked とともに HTTP 400 を返します。レスポンスには
構造化された metadata が含まれます — マッチしたルールラベル、理由コード、リスク
要因 — そして同じ拒否された呼び出しをループでハンマーできないように skip-retry と
マークされます。
response サーフェスでブロックされた呼び出し（モデルがすでに tool_calls を
発行している）はツールエラーをモデルに見せ、モデルに反応するチャンスを与えます —
別のツールを選ぶ、ユーザーに尋ねる、または停止する — クラッシュする代わりに。
5. 最初マッチが勝つ順序
優先度の順序が重要です。エンジンは優先度の昇順でルールを歩き、最初のマッチで停止します。 一般的なパターン：| 優先度 | ルール | 判定 |
|---|---|---|
| 5 | shell.exec + 破壊的正規表現 | deny |
| 10 | shell.*（一般） | allow |
| 20 | crm.* | allow |
| 9999 | *（キャッチオール） | deny |
shell.exec は
shell.* の一般的な allow があるにもかかわらず deny されます。低優先度の deny がなければ、
allow shell.* ルールが最初に勝ちます。
6. Shadow mode で安全にロールアウトする
新しいポリシーを強制に切り替える前に shadow mode をオンにします。ポリシーは すべてのツール呼び出しを評価し、本番と全く同様に判定をログしますが、すべての強制 判定（deny、pending_approval、sanitize）は audit に格下げされます — 何も
ブロックされません。イベントログの理由には [shadow] would deny が前置されるため、
Events と Runs ビューで影響を測定できます。
ポリシーが期待するものに発火し、意図しないものには発火しないことを確認したら、
shadow mode をオフにします。次の呼び出しが強制されます。
tight 自律性レベルは block_destructive_shell プリセットを自動的に適用します。
ルールを書かずに素早い姿勢が必要な場合、コンソールから tight を適用すると
ひとつのステップで破壊的シェル呼び出しの deny ポリシーが提供されます。その後、
独自の許可リストルールを重ねることができます。
自律性レベル
を参照してください。7. 関連脅威
エージェントツール乱用は単独では到達しないことが多いです。未承認のツール呼び出しは しばしば別の攻撃ベクターの結果です：- プロンプトインジェクション — 攻撃者が 取得されたコンテンツに指示を埋め込み、エージェントを呼ぶべきでないツールに 誘導します。
- 過剰な権限 — エージェントがタスクに 必要以上のツールアクセスを与えられ、あらゆるインジェクションや設定ミスを 直ちに危険にします。
- 脅威モデル — ツール乱用がエージェント システムの完全な攻撃表面にどう収まるか。
ファイアウォールルールリファレンス
完全なマッチング言語 — ツールグロブ、引数句、すべてのオペレーター、
判定、API。
ファイアウォール概要
ポリシー、サーフェス、自律性レベル、HITL 承認、可観測性。