メインコンテンツへスキップ
ファイアウォールイベントやガードレールマッチを読むとき、行はゲートウェイが何を 決定したか — deny、sanitize、[EMAIL] — を教えてくれます。このページは、それらの 言葉のためのルックアップテーブルです：それぞれが何を意味するか、呼び出しに何をするか、 そして完全なメカニズムについてどこへ行くか。ルールをオーサリングしたり、イベント フィードをトリアージしたりする間、開いておいてください。 2 つのコントロールプレーンが 2 つの語彙を生み出します。ファイアウォールは ツールのアクションを統制し、判定を発します。ガードレールは プロンプトとレスポンスのテキストをスクリーニングし、アクションを発し、加えて マスク時には型付きマスキングタグを発します。これらは決して言葉を共有しません — ガードレールは決して deny と言わず、ファイアウォールは決して mask と言いません。
これはリファレンスインデックスであり、ハウツーではありません。各コントロールの背後に あるユースケースについては ガードレール vs ファイアウォールを； HTTP ボディについては セキュリティエラーコードを参照してください。

​
1. ファイアウォール判定用語集

ファイアウォールルール（またはポリシーの default_verdict）は、すべてのツール呼び出しを これら 6 つの判定のちょうどひとつに解決します。エンジンは優先度順にルールを辿り、 最初にマッチしたものが勝ち、何もマッチしなければデフォルトにフォールバックします。
呼び出しはツールへ進みます。それでもファイアウォールイベントとしてログされるため、 Runs とイベントフィードに表示されます。これは、エージェントが使うことを明示的に 信頼されているツールに対して欲しいものです。
allow と同一のトラフィックですが、観察したいものとしてフラグされます。これは 推奨される default_verdict です：ルールがチューニングされるまで、すべてを観察し、 何もブロックしません。balanced 自律性レベルは PII Shield ガードレールを flag のみ （audit）として出荷するため、PII は呼び出しを保留せずに記録されます。
呼び出しはツールに決して到達しません。inbound サーフェスでは HTTP 400 firewall_blocked を返します；MCP ゲートウェイ経由ではツールエラー （firewall deny: <reason>）として返るため、モデルはクラッシュする代わりに反応 できます。skip-retry とマークされます。モデルトークンを消費しません。
ツール呼び出しの引数内のマッチした部分文字列（シークレット、PII）を [redacted:<preset>] トークンで置き換え、それからクリーニングされた引数で呼び出しを 転送します。引数のみをリダクトします — ツールが返すコンテンツは決して触りません。 inbound サーフェスでは、まだ呼び出し時の引数がないため、sanitize は deny に エスカレートします。
呼び出しはレビューのためにエンキューされ、エージェントは承認 id を運ぶ保留レスポンスを 受け取ります（HTTP 400 firewall_approval_pending）。レビュアーがコンソールで、 または HMAC webhook コールバック経由でそれを解決します；エージェントは id を ポーリングし、単回使用の承認ヘッダーとともに一度だけ再送信します。 人間による承認を参照してください。
ルールごとのセント上限を持つルールとしてオーサリングされます。エージェント実行が 予算内である間は allow に解決し、累積支出が上限を超えると deny に解決します — そのためイベントには、リテラルな単語 cap_cost ではなく、allow または deny が 表示されます。暴走ループのためのサーキットブレーカーです。
シャドウモードでは、deny / sanitize / pending_approval はすべて audit に 格下げされ、理由には [shadow] would … が前置されます。イベントは発火したであろう 判定を記録しますが、トラフィックは変わりません — それが安全なロールアウトの要点です。

​
デフォルト判定

default_verdict は、3 つの非インタラクティブな判定のみを受け付けます：
値ルールがマッチしないときの意味
allowカバーされていないツール呼び出しをサイレントに許可。
audit許可するが記録する — デフォルト。
denyどのルールも明示的に許可しないものをブロック（デフォルト deny 姿勢）。
tight 自律性レベルは default_verdict: deny を設定します；balanced と出荷時の デフォルトは audit を使用します。

​
2. ガードレールアクション

ガードレールルールは、5 つのアクションのひとつを発火します。これらは判定のテキスト プレーンの等価物です — そしてガードレールルールは決してファイアウォール判定を生み出し ません。
アクション何をするかクォータ
blockリクエスト全体を HTTP 400 guardrail_blocked で拒否。なし — 入力ブロックはメータリングの前に発火し；出力ブロックは返金。
mask各マッチを型付きタグ（§3を参照）にリダクトし、クリーニングされたテキストを転送。通常 — 呼び出しは進む。
flagログのみ。マッチを記録し、トラフィックについて何も変えない。通常。
annotate非ブロッキング。テキストをマスクもブロックもせずに、人間可読なノートをリクエストにアタッチ（セキュリティ通知としてアップストリームに注入）。通常。
spotlight非ブロッキング。マッチした（信頼されていない）テキストをデリミタで包み、デリミタで囲まれた領域を指示ではなくデータとして扱うようモデルに伝える — プロンプトインジェクションの「スポットライティング」防御。通常。
ブロックされたガードレールリクエストは skip-retry とマークされます — 別のチャネルに 対して同じプロンプトを再実行しても再びブロックされるだけです。
新しいルールを block または mask に切り替える前に、実トラフィックに対して測定する には flag を使ってください。Matches フィードは トラフィックへの影響ゼロで何が捕捉されたであろうかを表示します — ファイアウォールの シャドウモードのガードレール版です。
単一の pii ルールは、entity_actions を使って異なるエンティティに異なるアクションを 適用できます — メールと電話はマスクするが、credit_card と ssn はブロックする、を ひとつのルールから。キーはそのルールで有効化されたエンティティでなければならず；値は block / mask / flag / annotate でなければなりません。

​
3. マスキングタグ用語集

mask アクションでは、すべてのマッチしたエンティティが型付きタグ — [<UPPERCASE_ENTITY_NAME>] — でインラインに置き換えられるため、モデル（入力ステージ） または呼び出し元（出力ステージ）は、値なしでデータの形状を見ます。マスキングは両方の ステージで走り、ストリーミングされたレスポンスを含みます：トークン対応のストリーム スキャナが、チャンク境界をまたぐマッチを、クライアントに到達する前にマスクします。
エンティティタグ
email[EMAIL]
phone[PHONE]
credit_card[CREDIT_CARD]
ssn[SSN]
ip[IP]
iban[IBAN]
mac_address[MAC_ADDRESS]
jwt[JWT]
aws_access_key[AWS_ACCESS_KEY]
api_key_openai[API_KEY_OPENAI]
bitcoin_address[BITCOIN_ADDRESS]
3 つの地域識別子が、ベースセットの上に出荷されます：
エンティティタグリージョン
jp_mynumber[JP_MYNUMBER]日本
kr_rrn[KR_RRN]韓国
cn_resident_id[CN_RESIDENT_ID]中国
カスタムエンティティは同じ規約に従います。employee_id という名前のカスタム エンティティは、明示的な mask_with 置換を設定しない限り [EMPLOYEE_ID] にマスク されます。ルールごとに最大 25 個のカスタムエンティティ、それぞれオプションの luhn チェックサムを持つ RE2 正規表現です。 PII 検出を参照してください。

​
4. ひとつの実例

単一の db.query ツール呼び出しを、上から下へ読むと、両方の語彙に触れます： 
firewall verdict : sanitize        # SQL 引数からシークレットを除去
guardrail action : mask            # プロンプト内のメールをリダクト
masking tag      : [EMAIL]         # モデルが実際に受け取るもの
ファイアウォール sanitize はツールの引数をクリーニングし；ガードレール mask は プロンプトテキストをクリーニングし；[EMAIL] タグは、アドレスの代わりにモデルが 見るものです。同じリクエスト、3 つの異なるレイヤー、この用語集からの 3 つの言葉です。

​
5. 判定と並んで目にする姿勢の言葉

これらは判定でもアクションでもありませんが、判定がそもそも強制されるかどうかを決定 します — そのため、同じイベントと設定ビューに表示されます。
言葉プレーン意味
シャドウモードファイアウォールポリシーごとのフラグ。すべての強制判定を audit に格下げし、理由に [shadow] would … を前置。
観察モードファイアウォールワークスペース設定。どのポリシーも解決しないとき、呼び出しを許可するがカバレッジギャップとしてログ（Discovered tools）。
強制ファイアウォールシャドウオフ + ポリシーがアタッチ済み：判定が効力を持つ。
フェイルオープンガードレール高度なルール（llm_judge、grounding、external）のデフォルト — タイムアウトは観察され、リクエストは続行。ルールごとにフェイルクローズに切り替え可能。
Log raw contentガードレールデフォルトはオフ。オフのとき、マッチはルールが発火したことを記録するが、マッチした部分文字列は記録しない。
deny vs audit vs shadow の区別の詳細については、 強制モードを参照してください。

​
6. 各言葉がどこで定義されているか

サーフェス語彙ホームページ
ファイアウォールポリシーallow audit deny sanitize pending_approval cap_costファイアウォール
ファイアウォールルールマッチングtool_name_glob、args_match、egress、sequenceファイアウォールルール
ガードレールルールblock mask flag annotate spotlightガードレール
ガードレール PIIエンティティ名 + マスキングタグガードレール
MCP とスキルスキルリスクバンド、quarantine / block モードファイアウォール MCP、ファイアウォールスキル
HTTP エラーボディguardrail_blocked、firewall_blocked、firewall_approval_pendingエラーコード
ここのすべての用語は、アイデンティティ、スコープ、脅威の用語を追加する、より広い コンセプト用語集にも登場します。このページは狭く、 決定にフォーカスしたスライス — 判定、アクション、マスキングタグのみ — です。

​
7. 関連する読み物

なぜブロックされたのか？

1 つの拒否された呼び出しを、それを停止した正確なルールと判定までトレースします。

強制モード

audit、shadow、observe、enforce がどう関係するか — そして安全にロールアウトする方法。

ガードレール vs ファイアウォール

どのプレーンがどの決定を所有するか、そしてなぜリクエストが両方を通過しうるか。

危険なツール呼び出し

deny と sanitize 判定が止めるために存在する脅威。