メインコンテンツへスキップ
アプリがモデルに送るどのプロンプトも、含めるべきでない個人データを運ぶ可能性が あります — サポートチケットに貼り付けられたメールアドレス、CRM メモ内の SSN、 ユーザーがチャットボックスに入力したカード番号。そのテキストが一度アップストリーム プロバイダに到達すると、もはやあなたの制御下にはありません：ログに残り、キャッシュ され、もしかすると学習に使われます。モデルのレスポンスも PII を漏らし返す ことがあり、詳細をエコーまたは推論して、それがあなたのアプリケーションログに 残ってしまいます。 このページは、PII ガードレール — モデルが見る前にリクエスト上の機微エンティティを マスクまたはブロックするワークスペーススコープのルール — を使って、ゲートウェイで LLM PII 漏洩を止める方法を示します。これはエージェントファイアウォールの コンテンツ層のカウンターパートであり、アプリケーションコードの変更を一切必要としません。
PII ガードレールはプロンプトとレスポンスのテキストをスクリーニングします。 エージェントがデータに対して取るアクション — fetch ツール、egress ホスト — を 統制するには、データ持ち出しを参照して ください。2 つのプレーンは組み合わせ可能です。ほとんどのチームは両方を運用します。

​
1. 漏洩はどのように起きるか

PII は、ごく普通の善意のトラフィックを通じてアップストリームプロバイダに到達します：
  • ユーザーが自分の連絡先詳細をチャットに貼り付け、アプリがメッセージ全体を そのまま転送します。
  • RAG パイプラインが顧客レコードを含むドキュメントを取得し、それをコンテキストと してプロンプトに詰め込みます。
  • エージェントがデータベース行を読み取り、生のフィールドをツール引数やフォローアップ プロンプトに含めます。
  • モデルのレスポンスが PII を言い直したり推論したりし、それをアプリが自身の ログに書き込みます。
これらのいずれも攻撃ではありません — LLM アプリの通常の姿です。修正は、コード内の すべての呼び出し箇所を監査する代わりに、ひとつのチョークポイントですべての リクエストとレスポンスをスクリーニングするポリシーです。

​
2. PII ガードレールで LLM PII 漏洩を防ぐ

ガードレールはワークスペーススコープの名前付き コンテンツポリシーです。その中の pii ルールは機微エンティティを検出し、各マッチに ひとつのアクションを適用します：
アクション効果
mask各マッチを型付きタグに置き換え — jane@acme.com → [EMAIL] — クリーニングされたテキストを転送します。モデルは元の値を決して見ません。
blockリクエスト全体を HTTP 400 guardrail_blocked で拒否します。PII が一切プロバイダに到達してはならない場合に使用します。
flagトラフィックは何も変えず、マッチを記録します。強制する前に露出を測定します。
検出器セットは組み込みで決定的です — 純粋なパターンマッチングで、ネットワーク 呼び出しはなく、ホットパス上で安全です。組み込みエンティティ： email、phone、credit_card、ssn、ip、iban、mac_address、jwt、 aws_access_key、api_key_openai、bitcoin_address、加えてチェックサムで ゲートされた地域識別子 jp_mynumber、kr_rrn、cn_resident_id。 mask アクションでは各マッチがその型付きタグ — [EMAIL]、[SSN]、 [CREDIT_CARD] など — としてレンダリングされるため、値は消えてもプロンプトの 構造は維持されます。
組み込みでない検出器（社内の従業員 ID、口座番号）が必要ですか？ カスタム エンティティ — オプションの Luhn チェックサム付きの正規表現、ルールごとに最大 25 個 — を組み込みのすぐ横に追加します。 ガードレールリファレンスを 参照してください。

​
3. 具体例 — リクエスト上で PII をマスクする

最速の出発点は PII Shield プリセットです：email、phone、ssn、 credit_card、ip をマスクする単一の pii ルール。コンソールで設定します — このステップではコード変更もキーも不要です。
1

ガードレールを作成

コンソールで Guardrails を開き、New guardrail をクリックします。 pii カテゴリから PII Shield プリセットを選ぶか、上記のエンティティに 対してアクション mask の pii ルールを 1 つ手で記述します。保存します。 （書き込みには Developer ロール以上が必要です。）
2

サンドボックスで証明

Test タブを開き、“reply to jane@acme.com” を貼り付け、input ステージを 選んで実行します。サンドボックスは reply to [EMAIL] を返します — ローカルで、 アップストリーム呼び出しなし、クォータ消費なし。
3

キーにアタッチ

API Keys でキーを編集し、Guardrail ドロップダウンからガードレールを 選択するか、ガードレールをワークスペースデフォルトに設定して、すべての 未アタッチキーがそれを継承するようにします。バインディングはゲートウェイの キー上にあります。
4

いつも通りゲートウェイを呼び出す

そのキーを使えば、リレー呼び出しは変わりません：
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Draft a reply to jane@acme.com"}
    ]
  }'
ゲートウェイは転送する前にメールアドレスを [EMAIL] に書き換えます。 アップストリームモデルはアドレスを決して受け取りません。
PII Shield は both ステージのルールですが、ライブのリクエストステージマスキングが 今日出荷されているものです — ゲートウェイは、モデルへ出発する前にプロンプトを マスクします。ライブリレー上の出力ステージ（レスポンス）マスキングはロードマップ上に あります。レスポンスステージのルールがどう振る舞うかを検証するには、Test タブで 評価してください。ストリーミングについては §5 を 参照してください。

​
4. ほとんどをマスク、最悪のものをブロック — エンティティごとの上書き

単一のルールが entity_actions 経由で異なるエンティティに異なるアクションを 適用できます。低リスクの識別子はマスクしつつ、決して転送したくないエンティティは ハードブロックします — 3 つの重複するルールの代わりにひとつのルールで： 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
ここでメール、電話、IP はマスクされて通過します；カード番号や SSN を運ぶプロンプトは 代わりに HTTP 400 guardrail_blocked で拒否されます。ブロックされたリクエストは クォータを消費しません — 入力ステージのブロックはメータリングの前に発火します — そして skip-retry とマークされます。各 entity_actions キーは、ルール上で宣言された エンティティ（組み込みまたはカスタム）でなければなりません；そのアクションはルールの アクションセットに対して検証されます。

​
5. ストリーミングで今日機能するもの

アクションとステージはストリーミングと異なる相互作用をします — それに依存する前に マトリクスを把握してください：
完全にライブ。プロンプトはアップストリーム呼び出しの前にスクリーニングされる ため、レスポンスがストリームするかどうかに関わらず、マスキングとブロックは 同一に機能します。これが PII Shield が今日強制するサーフェスです。
ストリーミングと非ストリーミングの両方のレスポンスで強制されます。ストリームでは、 スキャナがストリームを途中で切断し、ブロックされたコンテンツがクライアントに 到達する前に置換メッセージを発行します；出力ブロックは事前消費されたクォータを 返金します。
現在は非ストリーミングのみ。ストリームされたレスポンスでは、元のチャンクが マスクされずに通過します — インバンドのストリーム書き換えは計画中の拡張です。 今日レスポンスマスキングを行うには、非ストリーミングリクエストを使うか、入力 ステージのマスキングに頼ってください。あなたの正確なステージ/ストリームの 組み合わせを、まず Test タブで証明してください。

​
6. 何が捕捉されたかを確認する

発火したすべてのルールはマッチ — その型、アクション、ステージ、詳細文字列 — を 記録し、ワークスペースの Matches フィード（GET /api/guardrail/match、任意の メンバーに開放）で表示できます。そこからグループ化、フィルタ、CSV へのエクスポート、 誤検知のマークができます。
生の値はデフォルトではログされません。 ガードレールの Log raw content トグルはオフ — プライバシー保守的な姿勢 — なので、Matches フィードは PII ルールが 発火したこととどのエンティティかを記録しますが、マッチした部分文字列（メール アドレス自体）は記録しません。トリアージのために値が必要なときだけ、ガードレール ごとにオンにしてください；この設定は遡及しません。PII 漏洩をデバッグするために 自分の監査証跡に PII を捕捉するのは本末転倒です。

​
7. さらに進める

完全なレジデンシー、保持、消去権の制御 — GDPR、HIPAA、PCI DSS 向けにこれらの ガードレールを具現化するコンプライアンスパックのインストールを含む — については、 以下のリファレンスページから始めてください。

ガードレールリファレンス

すべてのルール型、ステージ、アクション、カスタムエンティティ、バージョニング、 そして eval ハーネス — このページの背後にある深いリファレンス。

シークレット漏洩

クレデンシャル形状の兄弟 — AWS、OpenAI、GitHub トークン — Secrets Blocker ガードレールが捕捉します。

安全でない出力

モデルが受け取るものだけでなく、送り返すものをスクリーニングします。

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

いつテキストをスクリーニングし、いつアクションを統制するか — そしてなぜ通常は 両方が必要なのか。