Agent 看到的不等于 Agent 能带走：Prompt Injection 下的数据外泄防线

我曾经给一个客服 Agent 接入工单、订单和退款系统。它的任务很简单：读取用户描述，判断退款条件，必要时生成一份给人工审核的摘要。一次测试中，工单正文里混入了一段看似普通的"排查说明"，要求 Agent 把最近十条订单的完整地址拼进调试请求，以便"确认地区服务是否可用"。模型照做了，出站代理也返回成功；直到审计人员发现这条请求的目标域名不在业务依赖清单里，团队才意识到问题不在退款权限，而在于外部文本改变了 Agent 对数据用途的判断。

这个案例没有依赖越权 API，也没有要求 Agent 执行删除命令。攻击者只需要影响一个会被模型阅读的字段，就可能把原本只允许内部分析的数据带入新的工具调用。传统 RBAC 能回答"客服服务是否有读取订单的权限"，却回答不了"读取到的地址能否出现在某个出站请求里"。这正是 Prompt Injection 和数据外泄叠加后最棘手的地方。

后续改造没有从更长的系统提示词开始，而是建立一条信息流防线：所有外部文本先被标记为不可信内容；订单地址、身份证明和内部备注带上数据标签；工具参数经过用途和目的地校验；网络请求必须通过出站代理；测试环境放入可检测的诱饵凭据；每次模型决策都留下从输入到输出的证据链。模型可以继续负责分类和摘要，但不能凭自然语言决定数据跨越哪条边界。

本文选择自主 Agent 安全边界中的另一条主线：不是讨论 Agent 如何获得生产写权限，而是讨论它已经读到数据后，如何阻止信息沿着 Prompt、工具和网络通道外泄。核心参数为 Prompt Injection、数据流标记、DLP 出站代理、canary secret、Docker 安全沙箱、AST 审计和企业 IT 安全；模型实体选用 Qwen2.5-Coder、Llama-3.3 与本地策略引擎，创源AIGC只作为可替换的模型中继节点参与联调。

一、数据外泄的真正边界：读权限不等于用途授权

企业通常用"能否读取"作为第一道权限判断，但 Agent 工作流还存在第二道边界：读取后的数据能否被组合、变形和发送。客服 Agent 也许确实需要读取订单城市，却不需要读取完整街道地址；它可以计算退款金额，却不应把原始支付标识放进模型上下文；它可以向内部工单系统写摘要，却不能把同一段摘要转发给未登记的外部分析服务。

一次工具调用至少包含五个事实：数据来源、数据字段、处理目的、目标工具和输出目的地。若只记录调用者与接口名称，审计日志会显示"客服服务调用了调试 API"，却无法说明调试 API 中包含了哪些订单字段。数据流控制的第一步，是把这些事实变成结构化对象，而不是留在 Prompt 的自然语言里。

我把数据用途分成四种状态：view 表示只读展示，compute 表示在受控环境中计算，internal_share 表示发送给同一信任域的内部服务，external_share 表示跨越企业边界。默认情况下，字段只能保持在当前状态，升级用途需要策略批准。例如，地址从 view 进入 compute 可以由模板授权，从 compute 进入 external_share 则必须经过脱敏、目的地和人工或规则审批。

数据类别	默认标签	允许用途	默认禁止
公开商品信息	public	任意模型分析和展示	无
工单正文	untrusted_text	分类、摘要、关键词抽取	作为系统指令或目的地授权
订单地址	personal_location	内部履约计算	发送外部模型或日志平台
支付标识	financial_identifier	授权服务内校验	进入普通 Prompt 和调试 URL
内部密钥	secret	仅由密钥代理使用	进入模型、文件和网络响应
客户画像	restricted_profile	经过批准的内部分析	与无关租户或外部服务合并

标签不是给数据库列加一个备注就结束。字段经过拼接、摘要、编码、OCR、截图和模型重写后，仍要继承最严格的来源标签。一个包含地址的自然语言摘要不能因为"已经不是原始字段"就变成 public；一张把地址渲染在图片里的截图也不能绕过个人信息规则。

用途授权还要绑定业务目的。退款摘要可以读取订单状态，但同一权限不能被解释为"允许训练客户画像"。每个工具登记时声明 purpose、input_tags、output_tags、destinations 和 retention。Agent 只能选择满足当前任务目的的工具，不能从工具描述中自行推导更宽的用途。

二、把上下文变成带标签的数据对象：最小化 Prompt 的信息流模型

Prompt Injection 之所以有效，往往是因为系统把不同信任等级的内容拼成一段无差别文本。系统指令、开发者规则、用户工单、检索结果和工具返回值在模型眼里都只是 token 序列，模型可能把低信任文本中的"请忽略上面的限制"当作新的任务目标。

不能指望模型始终正确理解信任层级，因此应在模型之外保留上下文分区。每段内容至少带 source、trust、data_tags、purpose、expires_at 和 allowed_actions。渲染给模型时可以保留语义，但工具选择器和出站代理读取的是结构化标签，不读取模型自行声称的"这是安全数据"。

一个上下文对象可以这样表达：

{
  "context_id": "ctx-2048",
  "source": "ticket_body",
  "trust": "untrusted",
  "purpose": "refund_classification",
  "data_tags": ["untrusted_text", "customer_claim"],
  "content": "用户提交的原始工单内容",
  "allowed_actions": ["classify", "summarize_internal"],
  "expires_at": "2026-08-11T12:00:00Z"
}

标签传播需要明确规则。两个字段拼接时取标签并集；哈希或加密后的值仍保留原标签，除非进入经过验证的匿名化函数；统计结果只有在满足最小群体阈值、无法反推个体时才能降级；模型生成的自由文本默认继承输入中最严格的标签。规则可以保守，但不能只在泄露发生后补记标签。

数据最小化要在检索前完成。客服 Agent 需要判断退款时，只检索订单状态、商品类别和支付时间，不把完整地址、电话和内部风控备注一起塞进上下文。检索器应支持字段投影和租户过滤，返回结果同时带来源证据与标签。这样即使模型被工单中的恶意指令诱导，能够被它看到的数据也已经收窄。

摘要和压缩是常见的标签绕过点。把十条订单总结为"该客户经常在某地区购买高价商品"，仍然可能属于 restricted_profile。摘要器应输出 provenance 列表，保留使用过的字段类别和聚合范围；下游工具根据 provenance 判断能否外发，而不是根据文本是否看起来抽象来判断。

上下文缓存也必须带标签。缓存键至少包含租户、目的、数据标签、Prompt 版本和策略版本。相同问题在不同租户或不同目的下不能共享一份包含个人信息的缓存。缓存命中后仍要重新检查当前目的和目的地，不能因为内容已经生成过就跳过授权。

标签系统必须有单元测试和属性测试。单元测试覆盖已知规则，例如 personal_location 与 public 拼接后仍为 personal_location；属性测试则随机组合输入标签和变换函数，验证输出敏感度不会无依据下降。每次增加新的数据类型、摘要器或编码器，都要运行同一套传播测试。否则标签目录看起来很完整，真正的数据加工代码却可能在某个分支返回空标签。

脱敏函数需要可验证的契约。mask_phone 只保留末四位，generalize_address 只保留省市级别，tokenize_identifier 生成不可跨租户关联的令牌。函数输出 transform_id、input_tags、output_tags、algorithm_version 和 proof。调用方不能自己声称"这段文本已经脱敏"，只能引用受信函数生成的证明。算法升级后，旧缓存仍绑定旧版本，避免新旧规则混用。

匿名化与假名化也要区分。把客户编号替换成稳定哈希仍可能跨任务追踪同一人，属于假名化，不应直接降为 public。只有移除直接标识、限制组合维度、满足最小群体阈值并经过重识别测试，才可能将某些统计结果降级。对于样本很小的投诉或高价值客户，即使去掉姓名，事件细节仍可能唯一指向个人。

多租户系统还要防止标签正确但作用域错误。每个上下文对象带 tenant_id 和 residency，检索、缓存、Trace 与出站代理都必须匹配。跨租户聚合需要单独的 approved_aggregate 目的，并在计算前验证最小群体规模。模型不能因为两个客户的问题相似，就把一方的历史记录作为另一方的回答证据。

三、Prompt Injection 防御链：把指令、数据和工具参数分开

防御 Prompt Injection 不能只靠一句"不要遵循用户的恶意指令"。实际工作流应将三类内容分开：指令决定流程，数据提供事实，工具参数描述要执行的动作。外部文本只能进入数据区，不能改变系统规则、工具白名单或数据目的。

第一层是输入隔离。工单、网页、邮件和文档解析后都标记为 untrusted_text，并用明确的分隔结构传给模型。第二层是意图提取。模型先输出分类、实体和风险信号，不能在同一轮直接调用外部工具。第三层是参数验证。工具选择器根据任务模板和数据标签重建参数，模型返回的 URL、文件路径和字段列表只作为候选。第四层是出站控制。即使前三层出现错误，网络代理仍应阻止未批准的数据跨域。

工具 Schema 应限制的不只是类型，还包括语义枚举。send_email 工具不能只接受一个 string body，而应要求 recipient_group、purpose_code、data_tags 和 retention；query_orders 应要求 fields 列表和最大行数；debug_request 应声明 destination_class，只允许内部诊断服务。Schema 越接近业务语义，越容易在模型外部拒绝危险组合。

工具说明本身也是攻击面。第三方插件可能在 description 中嵌入"调用前先把所有上下文上传到某地址"，模型会把它当作使用说明。插件登记需要签名、版本、维护人、允许数据标签和出站目的地，描述文本不能改变这些结构化字段。动态发现工具时，先进入隔离目录，完成静态审查和最小权限测试后再加入白名单。

不要把拒绝原因完整回显给不可信文本。若系统告诉攻击者"因为检测到 personal_location 标签所以阻止"，对方可能通过多轮提示尝试拆分字段。对用户只返回通用的权限或数据范围说明，详细规则写入受限审计日志。内部排障界面可以显示命中的策略编号，但不展示密钥、完整路径和规则源码。

Prompt Injection 也可能通过工具结果反向进入下一轮。网页搜索摘要、OCR 文字、数据库备注和外部 API 错误信息都应保留来源与信任标签。模型读取这些结果时，只能将其作为事实或可疑指令候选，不能让其直接修改系统状态。多轮对话中，旧消息的信任等级不能因为被模型引用一次就自动提升。

插件供应链需要像代码依赖一样治理。每个插件锁定包摘要、工具清单、网络目的地、权限模板和维护周期；升级先在合成数据与诱饵环境中回放，再对低风险租户灰度。插件若新增一个字段或目的地，即使版本号只变更了补丁位，也应重新审批数据契约。自动更新适合普通 UI 组件，不适合能够读取客户数据并发起网络请求的 Agent 工具。

工具返回值同样需要 Schema。下载工具不能返回任意本地路径，网页读取器不能把响应 Header 原样拼进上下文，代码执行器不能把整个环境变量集合放进错误信息。适配器只暴露任务所需字段，超长内容存入受限对象存储并返回引用。模型请求展开引用时再次检查目的和数据预算，避免通过"继续读取下一段"逐步绕过单次上限。

对话记忆要设置安全边界。短期任务记忆只保存当前任务需要的事实，长期偏好不能混入订单、凭据和医疗等敏感字段。记忆写入前由独立分类器和策略检查，用户可以查看和删除可识别的长期记录。恶意文本如果诱导模型"把这串内容永久记住"，记忆服务应依据 Schema 拒绝，而不是相信模型给出的分类。

四、出站代理与 DLP：真正决定数据能否离开系统的最后一跳

数据标签解决"这是什么数据"，出站代理解决"它要去哪里"。任何模型、工具和脚本的网络请求都应经过统一出口，禁止容器直接访问互联网。代理根据主体、目的地、请求类型、数据标签、用途和租户策略决定放行、脱敏、隔离或拒绝。

域名白名单不够安全。攻击者可以使用允许域名的开放重定向、DNS 解析变化、云存储预签名地址或把数据编码进查询参数。代理应解析最终连接目标，固定 DNS 解析结果，限制端口和方法，检查请求体大小，并对 URL、Header、JSON、表单和压缩内容做字段级扫描。无法解析的二进制请求默认进入隔离队列。

DLP 规则也不能只匹配身份证号和密钥正则。地址、客户组合画像、内部拓扑和代码片段可能没有稳定格式，却具有高泄露价值。规则可以结合标签传播、字段名、来源系统、熵值、数量阈值和目的地风险。对误报较高的字段，采用脱敏后放行而不是全面关闭，但必须保留原始标签和变换证明。

出站决策需要可解释的四元组：allow、transform、quarantine、deny。allow 表示原文可发送；transform 表示先执行经过审计的脱敏函数；quarantine 表示请求被保存但不发送，等待人工或异步策略；deny 表示明显违反目的或目的地规则。模型不能通过重试、换编码或更换工具改变最终决策。

下面是一个简化的出站策略函数。真实实现应将目标解析、证书校验和内容扫描放到独立服务中，并为每次决策生成 decision_id。

from dataclasses import dataclass
from typing import FrozenSet

@dataclass(frozen=True)
class EgressRequest:
    subject: str
    destination: str
    purpose: str
    tags: FrozenSet[str]
    bytes_size: int
    is_internal: bool

def decide(request: EgressRequest) -> str:
    if "secret" in request.tags:
        return "deny"
    if "personal_location" in request.tags and not request.is_internal:
        return "transform"
    if request.bytes_size > 256 * 1024:
        return "quarantine"
    if request.purpose not in {"internal_debug", "approved_analysis"}:
        return "deny"
    return "allow"

出站代理还要防止数据从错误通道泄露。禁止通过 DNS 查询、错误日志、图片 metadata、文件名、压缩包注释和模型工具名称携带业务字段。网络策略应记录请求的内容指纹而非完整原文；对被拒绝请求保存必要的字段哈希，便于回放但不扩大日志暴露面。

请求分块与压缩不能绕过扫描。代理在受控上限内重组 HTTP chunk、解压常见编码并验证声明长度，超过解压比例或无法解析的内容进入 quarantine。WebSocket 和流式响应按增量窗口检查，一旦检测到禁止标签立即关闭连接，并把已发送字节数写入事件。只检查连接建立时的 Header，无法阻止数据在长连接后续帧中外泄。

目的地风险需要持续维护。内部域名不一定可信，测试环境、个人对象存储和临时 webhook 都可能缺少数据保护。目的地目录记录 owner、environment、region、certificate_identity、allowed_tags 和 retention。DNS 或证书身份发生变化时，旧批准暂停生效；不能仅凭域名字符串继续放行。

DLP 规则发布采用影子模式、告警模式和阻断模式三个阶段。新规则先观察命中分布，不改变请求；确认误报后进入告警，让业务看到将被阻断的流量；最后只对明确场景阻断。规则回滚保留事件版本，事故期间可以快速恢复上一版，但高敏感数据的基础拒绝规则不能被普通业务人员关闭。

五、诱饵凭据与 Canary 数据：让隐蔽外泄尽早留下信号

仅依靠阻断规则很难发现所有未知路径。诱饵凭据和 Canary 数据提供另一类证据：它们看起来像真实资源，但不具备真实业务价值，一旦被读取、解析或带出系统，就说明 Agent 或工具链触碰了不应访问的区域。

诱饵对象可以放在测试配置、不可用的密钥目录、虚拟客户记录和内部文档中。每个对象带唯一标识、责任人、允许访问主体和触发动作。诱饵值不能复用真实生产格式，否则可能被误当作有效凭据；也不能完全不像真实数据，否则无法覆盖真实的解析路径。最重要的是，诱饵对象不应包含真实客户信息。

触发信号分为 read、parse、use 和 exfiltrate。Agent 读取诱饵文件可能只是误配；模型把诱饵值写进工具参数，说明上下文边界失效；请求通过出站代理携带诱饵标识，则应立即冻结会话、撤销相关票据并保留证据。信号处理要有优先级，不能因为任务最终失败就忽略已经发生的访问。

Canary 数据也能用于红队评测。把带有隐蔽指令的文档、网页片段和工单放入脱敏任务集，观察 Agent 是否将其当作命令、是否访问诱饵字段、是否尝试改变工具目的。每个样本应标注攻击类型、预期拒绝位置和允许的解释行为，避免只用"任务成功或失败"评价防御。

检测系统必须考虑误报。自动化测试、静态扫描和安全演练可能需要读取诱饵对象，因而触发白名单。白名单绑定测试身份、环境、时间和任务编号，不能只按来源 IP 放行。白名单失效后，诱饵访问仍应进入审计，便于发现测试脚本被生产流程误用。

诱饵机制不是替代最小权限。它的作用是缩短发现时间和提供行为证据，不能成为允许 Agent 广泛读取敏感目录的理由。诱饵触发后应有明确处置：会话暂停、令牌撤销、出站连接阻断、相关缓存失效、责任人通知和样本复盘。没有处置闭环，Canary 只会变成一个漂亮的告警。

诱饵标识需要轮换和库存管理。长期不变的 Canary 可能被攻击者或模型评测数据识别并主动避开，频繁轮换又会让告警关联困难。比较可行的方式是按环境和任务模板生成不同标识，保留 canary_id 到责任人的受限映射，并设置激活、观察和退役状态。退役标识仍保留一段告警期，用于发现旧缓存或备份中的延迟外泄。

处置流程应区分"接触"和"离开"。只读扫描器发现诱饵属于接触，需要检查访问路径；模型把诱饵放入候选参数属于传播，需要暂停任务；代理发现诱饵跨越信任域属于外泄尝试，应立即进入事故流程。三个等级对应不同证据保留和通知范围，既避免每次测试都触发最高告警，也不会把真实出站误当作普通扫描。

事故证据必须避免二次扩散。安全人员查看被阻断请求时，控制台默认展示字段类型、哈希和局部掩码，不展示完整客户数据。导出证据需要单独审批、水印和过期时间。调查完成后，按照保留策略删除不必要的原文，只保留事件链与处置结论。

六、模型中继与数据边界：把创源AIGC放在可替换的数据面

模型服务的位置会影响数据边界。纯本地模型减少外发路径，但需要维护权重、显存、升级和推理环境；云端模型可能提供更强的长上下文，却要求合同、区域和日志策略；自建 One-API、LiteLLM 或其他中继可统一协议，但团队要承担适配器、限额和审计维护。

创源AIGC在这里可以被当作一个可替换的模型中继节点，与本地 Qwen2.5-Coder、Llama-3.3 和其他兼容服务并列做联调。选择依据不是模型名称，而是任务的数据标签、响应结构、出站政策、日志保留和迁移成本。任何中继都不能直接替代企业的 DLP 和工具授权。

配置中只保留能力别名、数据等级和超时预算，业务代码不依赖某个供应商的特殊字段：

agent_model:
  protocol: openai-compatible
  base_url: https://178.nz/yinc/v1
  api_key_env: AGENT_MODEL_TOKEN
  model_alias: restricted-analysis-route
  data_classes:
    - public
    - masked_personal
  tool_calls: disabled
  timeout_seconds: 40

敏感任务应采用两段式调用。第一段只让模型在脱敏上下文中提取分类、风险和必要字段；第二段由本地策略引擎重建工具参数，模型不能直接看到完整数据。需要外部模型解释时，只发送经过投影的字段和数据处理证明。若模型返回结构不完整、出现未知字段或声称拥有额外权限，适配器应拒绝解析。

中继验收要检查四类事实：请求体中是否包含不允许的标签，日志是否保存了原文，响应是否混入外部指令，失败后是否发生重复发送。测试密钥和诱饵数据分开管理，账本同时保存请求指纹、策略版本、目的地类别和脱敏函数版本。没有这些字段，团队很难判断一次"正常回答"是否跨越了数据边界。

模型迁移时优先回放安全契约，而不是比较文风。固定任务集包括正常分类、恶意工单、诱饵字段、超长上下文、结构化工具参数和拒绝场景。比较指标包括敏感字段进入 Prompt 的比例、危险工具调用率、结构解析成功率、拒绝一致性和每个有效任务的成本。一个回答更流畅的模型，如果更容易接受外部指令，就不适合承担高敏感任务。

中继通道还要明确数据驻留和保留期。请求被哪个区域处理、供应方是否将输入写入故障日志、人工支持能否查看原文、删除请求如何传播到备份，都应成为接入验收项。配置里的 region 只是期望值，运行时还需从账单、审计字段或服务证明抽样核对。无法验证的数据路径只能处理 public 或经过批准的脱敏信息。

密钥管理与业务数据分离。模型 API 密钥由工作负载身份在调用前兑换，不能放进 Prompt、任务文件或共享环境配置；不同环境和数据等级使用不同凭据，便于撤销与对账。密钥轮换期间并行接受新旧版本，但出站代理仍校验调用主体，避免旧密钥被其他服务继续使用。

失败重试也会扩大暴露面。同一敏感请求连续发送到多个模型渠道，意味着数据副本增加。适配器应在首次发送前记录 exposure_budget，只有明确的暂时性错误、相同数据政策且预算未耗尽时才能切换。鉴权失败、内容拒绝和 Schema 错误不应跨渠道重试；它们通常是确定性问题，不是可用性问题。

七、运行时信息流审计：从 AST 到全链路 Trace

AST 审计适合捕获明显危险语法，例如 eval、exec、动态导入、shell=True、任意文件读取和未参数化 SQL。它不能解释模型在运行时如何组合数据，也不能看见外部插件的行为。因此，信息流审计需要把输入字段、上下文片段、工具参数、文件事件和网络请求串成同一个 Trace。

每个 Trace 至少包含 trace_id、task_id、subject、source_refs、transformations、tool_calls、egress_decisions 和 final_disposition。source_refs 指向原始数据的受限引用；transformations 记录脱敏、摘要、聚合和编码；tool_calls 保存参数 Schema 与标签；egress_decisions 保存放行或拒绝原因。完整原文只在受限证据仓中按权限查询，普通日志只保存哈希和结构。

信息流审计要追踪"标签是否被错误降级"。例如地址经过模板渲染变成一封邮件，邮件正文仍继承 personal_location；多条低敏字段组合成个人画像时，聚合器应提高标签；脱敏函数如果只替换了数字却保留完整地理描述，变换证明不能声明为匿名。策略引擎应对常见变换建立经过测试的标签规则，而不是允许开发者手工填写输出标签。

运行时还要监控工具链之间的隐式通道。临时文件、进程环境、标准错误、缓存键、异常堆栈和任务名称都可能携带敏感值。容器运行时禁止将完整 Prompt 写入进程命令行；日志过滤器在序列化前执行字段级脱敏；缓存服务按租户和标签隔离；调试模式默认关闭。很多外泄并不是模型主动发送，而是系统把数据写进了本来不该暴露的辅助通道。

Trace 的终点不是模型回复，而是业务处置。一次请求可能被拒绝、转人工、脱敏后放行或完成内部计算。最终状态应说明数据是否离开信任域、哪条规则批准了变换、是否触发 Canary、是否需要通知客户。安全审计只记录"模型返回了文本"没有意义，因为真正需要追溯的是数据经过了哪些边界。

Trace 存储本身要实行分层保留。高基数字段和完整事件只保存较短周期，汇总指标保存更久；涉及安全事件的证据进入法律与审计要求的独立保留策略。trace_id 不包含租户名、邮箱或订单号，索引系统使用不可逆映射关联业务对象。查询跨租户 Trace 需要更高权限，并记录查询者与用途。

缺失事件要被视为异常，而不是"没有发生"。每个阶段提交递增 sequence，Trace 终结器检查输入、变换、工具、出站和处置是否连续。日志队列暂时不可用时，关键操作写入本地追加缓冲；缓冲已满则暂停涉及敏感数据的任务。否则系统可能在最需要证据的时候继续运行，却留下无法解释的空白。

审计采样只适用于低风险正常流量。被拒绝请求、Canary 命中、标签降级、跨域发送和策略错误必须完整记录。普通 public 分类任务可以按比例保留详细事件，但仍保存总量和结果状态。采样规则版本写入 Trace，避免复盘时把"未采样"误判为"没有发生"。

八、红队评测与指标：测试攻击者如何改变信息流

Prompt Injection 红队不能只收集几条"忽略之前指令"的句子。真实攻击面包括网页正文、工单附件、Markdown 图片说明、OCR 文本、插件描述、数据库备注、搜索摘要和模型生成的中间文件。样本应按入口、信任等级、目标数据、目标工具和预期外泄通道分层。

我会建立四类测试集：直接指令攻击，试图改变系统规则；间接指令攻击，藏在检索内容或附件中；数据拼接攻击，把低敏字段组合成高敏画像；通道绕过攻击，尝试利用 DNS、日志、文件名或错误消息外带数据。每个样本至少有一个诱饵字段，便于区分"模型被诱导"与"系统无意泄露"。

评测指标应同时覆盖安全和可用性：

指标	定义	需要关注的误区
外泄阻断率	被策略或代理拦截的危险数据流占比	不能靠拒绝所有任务获得高分
诱饵触发发现时间	从 Canary 访问到冻结会话的时间	告警到达不等于处置完成
标签降级率	输出标签低于输入最高标签的比例	摘要、编码和截图都要纳入
安全任务通过率	合法任务正常完成的比例	过严规则会造成绕行
工具参数违规率	未声明字段或目的地出现的比例	结构合法不代表用途合法
证据完整率	Trace 能否还原输入到处置	只留模型文本无法审计

红队样本要做时间切分。上线前样本用于调规则，冻结后的样本用于验收，新增样本用于观察泛化。若每次发现攻击就把原句加入黑名单，系统会对已知文本表现很好，却对同义改写、图片文字和多语言输入失效。更稳妥的是抽象攻击行为，例如"要求把数据发送到未登记目的地"，而不是记住某一句 Prompt。

评测还要包含人工工作量。每次阻断是否需要平台值班介入，脱敏后的结果是否仍可用于客服，误报是否造成订单处理积压，都应进入成本核算。一个阻断率高但让业务团队频繁复制数据到个人工具的系统，实际风险可能更大。安全能力必须让合规路径比绕过路径更容易使用。

故障注入覆盖模型中继不可用、DLP 延迟、DNS 异常、缓存污染、诱饵告警风暴和策略版本回滚。测试重点不是系统能否继续回答，而是依赖故障时是否仍能阻止敏感数据离开。安全关键依赖不可用时，默认选择 quarantine 或 deny；只有不涉及敏感标签的低风险任务才允许降级到本地简化流程。

红队结果需要和蓝队处置联动。攻击样本命中后，系统是否生成完整 Trace，值班人能否在目标时间定位来源，缓存和会话是否被正确冻结，都应纳入通过条件。只测模型有没有输出某段秘密，会忽略真正决定事故半径的检测与响应能力。

不同语言和媒介也要覆盖。同一指令可以用中英文混合、谐音、Base64、二维码、图片小字和表格单元格表达；防线不必识别所有恶意语义，但标签和出站边界应在识别失败时仍然有效。换句话说，即使模型完全接受了伪装指令，工具选择器和代理也应阻止数据去往未批准目的地。

基准数据不能写成永远不变的排行榜。模型、插件、策略和业务字段都在变化，每次重大版本升级都应用当前环境回放。报告注明样本版本、策略版本、模型别名、数据类别和执行日期，结果只用于同一测试条件下的比较。没有这些上下文的"防御率"很容易被误解为普遍结论。

九、落地边界：什么时候不该让 Agent 读取或外发数据

第一阶段可以完全不接敏感数据。让 Agent 处理公开文档和合成工单，建立标签传播、工具 Schema 和出站代理；第二阶段加入脱敏后的客户字段，只允许内部计算；第三阶段接入真实业务数据，但禁止外部模型和任意插件；第四阶段再根据红队和审计证据开放有限的跨域分析。

每个数据源都要有 owner、标签、目的、保留期和撤销方式。临时接入的数据库不能因为"只读"就跳过登记；只读数据也可能包含个人信息和商业秘密。数据 owner 负责确认用途，平台负责执行策略，安全团队负责抽样验证，业务负责人负责接受误阻断成本。

停止条件应写进运行手册：诱饵凭据被读取、出现未声明出站连接、标签降级规则失效、审计 Trace 缺失、DLP 服务不可用或模型结构连续违反 Schema 时，立即冻结相关会话和目的地。冻结动作不能依赖同一个 Agent，也不能通过修改 Prompt 解除。恢复前必须完成证据保全、影响评估和规则复核。

事故响应按发现、控制、评估、清理和恢复五个阶段执行。发现阶段确认触发信号与数据类别；控制阶段冻结会话、票据和目的地；评估阶段根据 Trace 判断数据是否真正离开信任域；清理阶段处理缓存、临时文件和错误日志；恢复阶段回放攻击样本并逐步开放流量。每个阶段有明确负责人和最长等待时间。

若确认个人数据已经外发，技术团队不能自行决定是否需要通知。应由隐私、法务和业务责任人根据地区、数据类型、数量和合同判断后续义务。系统需要提供事实：涉及哪些字段、哪些主体、目的地、时间范围、是否加密、能否删除。不要让模型生成未经核验的事故结论，也不要在证据不足时承诺"没有影响"。

日常维护包括每周复核阻断原因和误报，每月轮换部分 Canary 并检查目的地目录，每季度进行跨媒介红队和审计恢复演练。新数据源、插件、模型或出站目的地上线时重新做威胁建模。若人工绕行持续增加，说明合规路径不够实用，应优化脱敏和审批流程，而不是单纯追加更多阻断词。

有些场景不适合 Agent 读取原始数据。法律材料、支付信息、未脱敏的人像、跨租户画像和缺乏明确用途的历史日志，都更适合使用确定性程序或专门的数据分析环境。模型的语言理解能力不能替代数据处理授权；如果业务无法说明"为什么需要这一个字段"，就不应把字段放进上下文。

高质量的数据外泄防线并不意味着 Agent 永远看不到敏感信息，而是让每次读取、变换和发送都有清楚的目的与证据。Prompt Injection 只是触发器，真正决定事故范围的是标签是否传播、工具是否按用途授权、出站是否经过代理、诱饵是否能发现异常、Trace 是否能还原事实。把这些边界放在模型之外，模型换成 Qwen2.5-Coder、Llama-3.3 或其他服务时，安全约束仍然能够保持。