跳轉到主要內容
一個能觸及網路的代理可以被變成一根資料管道。 注入的指令告訴它用它已經持有的工具蒐集密鑰、列，或 PII， 並把它們 POST 到一個攻擊者主機——或探查 內部服務（SSRF）。代理從不「決定」要外洩；它 執行對它而言看似一條合法指令的東西。 本配方串接起三個端對端封閉迴圈的控制—— 一份鎖定外送呼叫能去何處的 egress 允許清單、 在憑證觸及一個模型之前就攔下它們的 Secrets Blocker 防護欄， 以及把密鑰從一個模型確實發出的工具呼叫中剝除的引數淨化器。 其中一切都存在於閘道中，所以你在主控台中設定它一次， 且對你的代理程式碼零更動。關於完整的攻擊解剖，閱讀 網路上的資料外洩； 本頁是構建步驟。
這裡的一切都綁定到你的工作區，並從 主控台設定。你的代理持續以相同的 sk-orca-... 金鑰呼叫 https://api.orcarouter.ai/v1/...——只有閘道中的政策改變。 設定動作需要每個步驟標明的角色；中繼呼叫使用 那把範圍限定金鑰。防火牆只看見透過閘道路由的目的地的 egress（MCP 派發路徑或 evaluate hook）——把 你的網路綁定工具呼叫路由通過它，它們就會受治理。

​
1. 防止 AI 資料外洩的三個層次

每個層次在請求生命週期的不同點捕捉攻擊。 把三個都疊起來——它們是獨立且互補的。

提示中的憑證

一個被貼進（或被拉進）請求的密鑰，會在輸入階段被 Secrets Blocker 防護欄捕捉——在任何模型 看見它之前。

工具引數中的密鑰

一個發出攜帶憑證的工具呼叫的模型，會被一條 sanitize 防火牆規則清理，它會遮蔽匹配到的引數。

外送目的地

真正的網路步驟受一份 egress 允許清單所限——只有 列舉的主機通過；其餘一切被拒絕。
本配方使用兩個平面：防護欄用於請求中的 文字，防火牆用於動作 與網路。關於界線落在何處，參見 防護欄與防火牆。

​
2. 在提示處攔下憑證——Secrets Blocker 防護欄

第一個要鎖定的是憑證本身。Secrets & API-Key Blocker 防護欄在輸入階段運行，並掃描 請求中的憑證模式——AWS 風格的存取金鑰、OpenAI 金鑰、 JWT 與類似權杖——在請求離開閘道之前。一旦 匹配，請求就被封鎖：憑證從不抵達一個模型，也 從不落入一個工具呼叫。 在主控台中，開啟 Guardrails → New guardrail（Developer 角色；讀取與 Test 沙盒對任何成員開放），把它命名為 exfil-shield，並從範本庫套用 Secrets & API-Key Blocker 預設集（類別 secrets）。該預設集會播下三條 input 階段的 regex block 規則，每種憑證形狀一條——AWS 存取 金鑰、OpenAI 風格的金鑰，以及 GitHub 權杖： 
[
  { "type": "regex", "stage": "input", "action": "block", "pattern": "AKIA[0-9A-Z]{16}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "sk-[A-Za-z0-9]{20,}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "ghp_[A-Za-z0-9]{36}" }
]
要擴展涵蓋，在內建實體上加一條 pii 規則——偵測器 集涵蓋 email、phone、credit_card、ssn、ip、 iban、mac_address、api_key_openai、aws_access_key、jwt 與 bitcoin_address。透過 entity_actions 逐實體選擇 mask（遮蔽到一個帶型別的標籤如 [EMAIL]） 或 block。輸入階段遮罩已上線； 它會在模型看見請求之前重寫它。
一個被封鎖的請求回傳 HTTP 400 guardrail_blocked，消耗零 配額（一個輸入階段封鎖在計量之前觸發），並被標記為 skip-retry。在 Test 分頁中證明它——貼上一個樣本 AWS 金鑰、挑選 input 階段，並確認裁決——再附加一把金鑰。

​
3. 把密鑰從工具呼叫引數中淨化掉

一條防護欄篩查提示；它看不見一個模型發出的 工具呼叫。當模型產生一個其引數攜帶 憑證的 tool_call 時，一條防火牆 sanitize 規則會捕捉它。Sanitize 會從工具呼叫引數中遮蔽 匹配到的子字串，並轉送清理後的呼叫——工具運行，但 密鑰已被剝除。 在 Firewall → Policies → New policy（Developer 角色）中，把它命名為 exfil-firewall，並在 response 介面上加一條 sanitize 規則—— 模型在其回覆中發出的 tool_calls： 
{
  "priority": 10,
  "label": "Redact secrets from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize": {
    "presets": ["aws_access_key", "openai_key"],
    "custom": ["sk-[A-Za-z0-9]{20,}"]
  }
}
Sanitize 只遮蔽工具呼叫的引數——絕不遮蔽一個工具 回傳的內容。它是對外送呼叫形狀的防禦，而非對 inbound 工具結果。在 inbound 介面上（那裡尚無呼叫時引數） 一個 sanitize 裁決會升級為一個 deny。關於完整的匹配 語言，參見 防火牆規則。

​
4. 鎖定外送目的地——egress 允許清單

最持久的防禦是網路邊界本身：列舉 你的代理被合法允許觸及的主機，並拒絕其餘 一切。一條 egress 規則使用 stage: egress 與 egress 欄位； 裁決設定極性——allow 放行列出的目的地，而一個 較低優先順序的 deny 捕捉全部則封鎖其餘。 把這些規則加入同一個 exfil-firewall 政策： 
[
  {
    "priority": 10,
    "label": "Allow known API endpoints",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "allow",
    "egress": {
      "allow": ["api.openai.com", "api.anthropic.com", "api.orcarouter.ai"]
    }
  },
  {
    "priority": 20,
    "label": "Deny all other outbound destinations",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
條目以一個 CIDR、一個 IP 字面值，或一個不分大小寫的主機名匹配。 要在沒有明確允許清單的情況下阻止朝向內部服務的 SSRF， 自己撰寫一條 egress deny 規則，列出雲端中繼資料端點 （169.254.169.254）與 RFC-1918 私有範圍（10.0.0.0/8、 172.16.0.0/12、192.168.0.0/16）。一個被拒絕的呼叫回傳 HTTP 400 firewall_blocked。
沒有預設集出貨 CIDR egress 規則——你自己撰寫 host/CIDR allow 與 deny 條目。tight 自主等級 是相鄰的快速路徑：它直接拒絕擷取形狀的工具名稱 （http_fetch、web_search、fetch_url、request），在一個目的地 被評估之前就移除網路能力。當你的代理根本不需要那些工具時使用它。

​
5. 附加一把範圍限定金鑰

一個政策只會在解析到它的金鑰上強制執行。給代理它自己的 金鑰，範圍限定到它所需的最低限度——絕不用你帳號層級的金鑰。在 API Keys → New key（Developer 角色）中：
從 Guardrail 下拉選單挑選 exfil-shield（設定 guardrail_id），並從 Firewall policy 下拉選單挑選 exfil-firewall（設定 firewall_policy_id）。兩個綁定都存在於閘道中的金鑰上。一個明確的防護欄附加絕不靜默 回退——停用它就是關閉開關。相對地，一個被停用的防火牆政策 則回退到工作區預設政策。
把 credit_limit_usd 設為一個合理的上限（0 = 無限制），這樣一把 被入侵的金鑰就無法耗盡配額，並把 allow_ips 設為你後端的 外送 IP，如果代理從一個固定伺服器呼叫。為臨時金鑰設一個 expired_time（-1 = 永不過期）。
金鑰在建立後顯示時會被遮罩——只複製一次。你的代理 現在會讓每個請求穿過 exfil-shield，並讓每個工具呼叫穿過 exfil-firewall，且沒有任何程式碼知道強制執行正在發生。

​
6. 用影子模式上線，然後觀察

如果你還不知道你的代理合法觸及的每個主機，別 盲目強制執行——先觀察。關於完整的 observe → shadow → enforce 路徑，參見強制執行模式。
1

影子化 egress 規則

在 exfil-firewall 上設定 shadow_mode: true。每個強制執行的裁決 都會被降級為 audit，並帶著目的地記錄為 [shadow] would deny。 影子模式開啟時沒有流量被封鎖。
2

觀察動態

Firewall → Events / Runs（Developer+）顯示你的代理命中的每個工具呼叫與 egress 目的地，以及會被拒絕的東西。 Guardrails → Matches（任何 Member）顯示輸入防護欄捕捉的 每個密鑰。調校 egress allow 清單，直到只有 攻擊者可觸及的主機會被拒絕。
3

強制執行

關閉 shadow_mode。緊接的下一個請求就受治理—— 憑證在提示處被封鎖、密鑰從工具引數中被剝除、 外送呼叫被限制在你的允許清單內。無需應用程式變更。
Matches 動態只在防護欄的 Log raw content 開啟時才記錄匹配到的子字串（預設關閉—— 隱私保守的姿態）。標記一個誤判（Admin）以調校 政策。每次防護欄變更都會寫入一筆你可以 diff 與還原的版本歷史列； 防火牆政策變更記錄在稽核軌跡中。

​
7. 一覽涵蓋範圍

外洩步驟阻止它的層次
憑證進入請求Secrets Blocker 防護欄（input）
模型發出一個攜帶密鑰的工具呼叫sanitize 防火牆規則（response 介面）
工具撥向一個攻擊者主機Egress allow / deny 規則
代理觸及雲端中繼資料或 RFC-1918列出那些 CIDR 的 Egress deny 規則
擷取形狀的工具被提供給模型tight 自主等級（工具名稱 deny）

​
8. 下一步去哪裡

防火牆規則參考

完整的匹配語言——egress 清單、CIDR、淨化器，以及所有裁決。

資料外洩威脅

本配方端對端防禦的攻擊解剖。

加固一個 MCP 代理

治理一個代理透過 MCP 伺服器派發的每個 tools/call。

PII 安全的日誌

讓敏感資料遠離你的 request log 與 Matches 動態。