跳转到主要内容
一个能访问网络的智能体可以被变成一根数据管道。被注入的指令告诉它用它 已经持有的工具去收集密钥、行数据或 PII，并把它们 POST 到一个攻击者 主机——或探测内部服务（SSRF）。智能体从不”决定”去外泄；它执行在它看来 像是一条合法指令的东西。 本配方接好三项控制，端到端地闭合这个循环——一个egress 允许列表锁定 出站调用能去哪里、Secrets Blocker 防护栏在凭据到达模型之前就拦下 它们，以及一个**参数脱敏器（sanitizer）**把密钥从模型确实发出的工具调用 中剥离。这一切都存在于网关，因此你在控制台中配置一次，无需修改你的 智能体代码。关于完整的攻击解剖，阅读 网络上的数据外泄；本页是构建步骤。
这里的一切都绑定到你的工作区并从控制台配置。你的智能体继续用同一个 sk-orca-... 密钥调用 https://api.orcarouter.ai/v1/...——只有网关中的 策略发生变化。配置动作需要每个步骤点明的角色；中继调用使用那个限定 范围的密钥。防火墙只对路由经过网关（MCP 派发路径或 evaluate hook）的 目的地看到 egress——把你那些访问网络的工具调用路由经过它，它们就受到 治理。

​
1. 预防 AI 数据外泄的三层

每一层在请求生命周期的不同点捕捉攻击。把三层叠起来——它们独立且互补。

提示中的凭据

一个被粘贴进（或被拉进）请求的密钥会在输入阶段被 Secrets Blocker 防护栏捕捉——在任何模型看到它之前。

工具参数中的密钥

一个发出携带凭据的工具调用的模型会被一条 sanitize 防火墙规则 清理，它脱敏匹配的参数。

出站目的地

实际的网络步骤由一个 egress 允许列表限定——只有列举出的主机 通过；其余一切被拒绝。
本配方使用两个平面：用 防护栏 处理请求中的 文本，用 防火墙 处理动作和网络。关于界线落在 哪里，参见 防护栏 vs 防火墙。

​
2. 在提示处拦下凭据——Secrets Blocker 防护栏

第一件要锁定的是凭据本身。Secrets & API-Key Blocker 防护栏在 输入阶段运行，并在请求离开网关之前扫描请求中的凭据模式——AWS 风格 的访问密钥、OpenAI 密钥、JWT 和类似令牌。命中时请求被拦截：凭据永远 不会到达模型，也永远不会落入一次工具调用。 在控制台中，打开 Guardrails → New guardrail（需 Developer 角色； 读取和 Test 沙箱对任何成员开放），命名为 exfil-shield，并从模板库 （类别 secrets）应用 Secrets & API-Key Blocker 预设。该预设播种 三条 input 阶段的正则拦截规则，每种凭据形态一条——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 执行面——模型在其回复中发出的 tool_calls——上加一条 sanitize 规则： 
{
  "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 执行面 上（那里还没有调用时参数）一个 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 拒绝规则，列出云元数据端点（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 允许和拒绝条目。 tight 自治级别 是相邻的 快速路径：它直接拒绝 fetch 形态的工具名（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. 用 shadow mode 上线，然后观察

如果你还不知道你的智能体合法访问的每一个主机，不要盲目执行——先观察。 关于完整的 observe → shadow → enforce 路径，参见 执行模式。
1

对 egress 规则做 shadow

在 exfil-firewall 上设置 shadow_mode: true。每个执行性判定都被 降级为 audit，并连同目的地记录为 [shadow] would deny。在 shadow mode 开启时没有流量被拦截。
2

观察信息流

Firewall → Events / Runs（Developer+）显示你的智能体命中的每一次 工具调用和 egress 目的地，以及会被拒绝的内容。 Guardrails → Matches（任何 Member）显示输入防护栏捕捉到的每一个 密钥。调优 egress allow 列表，直到只有攻击者可达的主机才会被拒绝。
3

执行

关闭 shadow_mode。紧接着的下一个请求就受到治理——凭据在提示处被 拦截、密钥从工具参数中被剥离、出站调用被限制在你的允许列表内。 无需任何应用变更。
Matches 信息流仅当该防护栏的 Log raw content 开启时才记录匹配的 子串（默认关闭——隐私保守姿态）。标记一个误报（Admin）以调优策略。 每次防护栏变更写入一条你可以 diff 和 revert 的版本历史行；防火墙策略 变更被记录在审计追踪中。

​
7. 覆盖一览

外泄步骤阻止它的层
凭据进入请求Secrets Blocker 防护栏（input）
模型发出携带密钥的工具调用sanitize 防火墙规则（response 执行面）
工具拨向一个攻击者主机Egress allow / deny 规则
智能体访问云元数据或 RFC-1918列出那些 CIDR 的 Egress deny 规则
向模型提供 fetch 形态的工具tight 自治级别（工具名拒绝）

​
8. 接下来去哪里

防火墙规则参考

完整的匹配语言——egress 列表、CIDR、脱敏器，以及所有判定。

数据外泄威胁

本配方端到端防御的攻击解剖。

加固一个 MCP 智能体

治理一个智能体经由 MCP 服务器派发的每一次 tools/call。

PII 安全日志

让敏感数据远离你的请求日志和 Matches 信息流。