AgentLeak：多智能体 LLM 系统内部通道隐私泄露基准

关联论文：2602.11510
作者：spark
更新：2026-07-08

一句话结论

AgentLeak 是首个把多智能体 LLM 系统的隐私泄露测量从"输出层"扩展到"内部通道层"的基准——通过在 7 条隐私相关的通信路径上植入探针，作者在 1,000 个场景、5 个生产模型、4,979 条执行轨迹上证明了一件事：多 Agent 架构在降低最终输出泄露的同时，把大量隐私数据暴露在了 Agent 间消息、共享记忆和工具参数这些"看不见的通道"里，而当前所有只看输出的防御都会漏掉 41.7% 的违规。

解决什么真问题

多智能体 LLM 系统（multi-agent LLM systems）正在成为企业 AI 落地的默认形态：协调者–工作者（coordinator-worker）架构、Supervisor–Worker、MetaGPT/AutoGen 式角色编排、LangGraph 子图调用……架构多样性背后是一个被普遍低估的安全问题——隐私数据从来不会只在最终输出里流动。

一次典型的"合规审计 Agent 协作"可能是这样：

协调者收到任务："帮我审一下 Q3 财报的合规风险。"
协调者把任务拆给三个 worker：财务分析 worker 拿到完整财报、合规比对 worker 拿到监管规则、风险摘要 worker 拿到前两个的中间结果。
worker 之间共享中间结论，共享记忆里留下敏感字段。
工具调用参数里可能塞着客户名单、未公开并购信息、内部薪酬数据。

整个链条里最终给用户看的输出可能完全合规——但中间消息、共享记忆、工具参数早已把敏感数据暴露给了上游 prompt、监控日志、向量库、甚至下一个被召的 worker。

论文揭示的核心问题是：现有隐私评估基准几乎都只看最终输出（output-only audits）。它们无法回答"系统在协调过程中有没有把客户 PII 通过 worker 之间的消息泄漏给了不该看到的上下文"。这不是理论风险——论文在 4,979 条真实执行轨迹里直接量出了 41.7% 的漏报率。

核心方法

1. 七条隐私相关通信通道（Channels）

AgentLeak 把多智能体系统的通信解剖成 7 条隐私相关通道：

C1 Final Output（最终输出）：传统评估唯一看的层。
C2 Inter-Agent Messages（Agent 间消息）：worker ↔ worker、worker ↔ coordinator 的直接通信。
C3–C7：覆盖共享记忆 / 共享上下文、工具调用参数、检索召回内容、日志与可观测性数据、以及外部 RAG 召回片段等内部通道（具体编号论文按重要性排序，详细列表参考原文 §3.1）。

这是评估框架的核心创新：把"系统内每一个可能携带敏感数据的横向流动"都显式建模，而不是只盯着用户能看见的那一行。

2. 场景构造：1,000 跨域用例

论文构造了覆盖医疗、金融、法律、企业运营四大领域的 1,000 个隐私敏感场景。每个场景包含：

一份"含敏感字段的输入数据"（如患者姓名 + 诊断、金融账户 + 持仓、合同条款 + 客户名）；
一组明确定义的"禁止泄露字段集合"（如"不得向最终输出泄露诊断结果"）；
一组合规的多 Agent 任务编排。

重点是：很多场景的"正确答案"在最终输出里并不包含敏感数据，但内部通道里跑了一遍。这就让"输出干净 ≠ 系统安全"的命题可被实证检验。

3. 模型与执行

论文评测了 5 个生产级 LLM：GPT-4o、GPT-4o-mini、Claude 3.5 Sonnet、Mistral Large、Llama 3.3 70B。每个场景在两种架构下运行：

单 Agent 模式（baseline）：一个 LLM 直接拿全部输入；
协调者–工作者多 Agent 模式：标准 coordinator-worker 编排。

最终采集 4,979 条验证过的执行轨迹（不是 1,000 × 5 × 2，因为部分执行被拒绝或失败），每条轨迹同时记录 C1–C7 七个通道的内容。

4. 泄露判定

对每一条通道的内容用规则化 + LLM 辅助的方式判定是否包含"禁止泄露字段"。论文指出 LLM 判定在此处是合理的——因为判定对象是"是否出现某个字符串/语义片段"，不像评估任务完成度那样依赖多步推理。这一边界划分很重要：判定器是 LLM，验证对象是结构化字段。

5. 指标定义

单通道泄露率：某条通道 C_i 单独看时的违规比例；
聚合系统泄露率：任意一条内部通道违规即算系统违规；
漏报率（miss rate）：标准输出级审计（只看 C1）vs 完整内部通道审计的差距。

关键实验与数据

论文给出了几条非常硬的核心数字：

核心结论 1：多 Agent 降低了最终输出泄露，但把风险搬到内部

单 Agent 模式下 C1（最终输出）泄露率：43.2%
多 Agent 模式下 C1 泄露率：27.2%
多 Agent 模式下聚合系统泄露率（C1 + C2 + C5）：68.9%

换句话说，多 Agent 架构确实让用户看到的输出更干净（从 43.2% 降到 27.2%），但整个系统的隐私暴露反而抬高了 25.7 个百分点——因为风险被推到了内部通道。

核心结论 2：Agent 间消息是最大的"暗漏"

多 Agent 模式 C2（Agent 间消息）泄露率：68.8%
多 Agent 模式 C1（最终输出）泄露率：27.2%
输出级审计漏报率：41.7%

C2 ≥ C1 这个关系在 5 个模型、4 个领域上全部成立——这是一个稳健的实证规律，不是单模型现象。

核心结论 3：跨模型与跨领域的一致性

5 个模型都呈现 C2 ≥ C1 的模式；
4 个领域（医疗、金融、法律、企业）都呈现同样的格局；
不同模型的具体数值有差异，但相对排序一致（具体模型级数字原文未完全披露）。

核心结论 4：领域敏感度

医疗和金融场景的内部通道泄露率显著高于法律和企业场景——前者字段更结构化（PII 占比高），后者更依赖语义。

亮点与局限

亮点

首个把"内部通道"显式建模的基准：在 AgentLeak 之前，隐私评估默认只看输出，这篇直接重定义了评估边界。
规模扎实：1,000 场景 × 5 模型 × 2 架构 + 4,979 条轨迹，结论的统计可信度高。
跨模型 / 跨领域一致性：C2 ≥ C1 不是偶然现象，而是 5×4 = 20 个组合里都成立的稳健规律。
41.7% 漏报率是惊人数字：意味着任何"我们只审计输出"的合规方案实际上漏掉了近一半违规。
开源：代码与数据集已在 GitHub 公开（Privatris/AgentLeak），社区可复现可扩展。

局限

架构只评测了 coordinator-worker：对更复杂的图状编排、层次化 Supervisor、自演化多 Agent 体系尚未覆盖，这些架构下的内部通道可能完全不同。
判定仍涉及 LLM：尽管判定对象是结构化字段，仍引入了 LLM 偏见的可能性——论文用规则化做了兜底但没有完整披露。
模型覆盖偏 2025 年主力：评测时点对应 2026 年 2 月的 v1，未包含 Claude 3.7、GPT-4.5、o3 等更新一代模型。新模型对系统提示的遵循度可能改变结论。
缺攻击视角：测量的是"无意泄露"，未评估"恶意 worker 主动泄露"的对抗场景。这对安全研究是个明显空白。
未深入工具调用参数（C3/C4）：论文按重要性排序重点分析了 C1/C2/C5，其他通道披露相对简略。

对工程落地的启发

审计多 Agent 系统必须覆盖内部通道：只看最终输出等于自欺欺人。组织应该把"协调者–worker 之间的消息内容、共享记忆快照、工具调用参数"列为合规审计对象。
隐私工程要把 C2 当一等公民：Agent 间消息是最大的泄露面，需要设计显式的脱敏中间层——例如协调者在分发任务时对 worker 做"上下文最小化"，只给必要字段、不给全文。
数据脱敏要在边界做：在数据进入 Agent 集群之前（而不是之后）做 PII 替换/Token 化，能从根本上降低 C1–C7 全部通道的暴露。
共享记忆要做分区：不同 worker 的共享记忆要按敏感级别分区，最敏感的字段不进共享层。
可观测性平台要"看见" Agent 间消息：传统 APM 看不到 LLM 调用细节，AgentOps 平台必须把 C2/C3 这类内部通信纳入监控与告警。
模型选型要看 C2 而非 C1：在多 Agent 场景里，C1 泄露率（看上去输出干不干净）会误导选型——必须看 C2 与聚合指标。

与同方向工作的关系

PrivacyLens / Prompt Leakage 评测：偏单 Agent prompt 层泄露；AgentLeak 是其向多 Agent 的自然延伸。
AgentDojo / Agent Security Bench：偏工具调用安全与越权；AgentLeak 偏数据流转隐私，两者互补。
Constitutional AI / RLHF 安全训练：关注模型本身不输出有害内容，AgentLeak 关注"模型本身合规但系统架构泄密"——这是上层防御解决不了的问题。
RAG 安全 / 数据外泄文献：偏检索召回阶段的注入与泄露；AgentLeak 把视野扩到多 Agent 协调阶段。
Sandbox / TEE for Agent：偏运行时隔离；AgentLeak 给出了"为什么要隔离"的实证理由。
OSWorld / OpenComputer（同期解读的另一篇方向）：评估 Agent 能不能做对任务；AgentLeak 评估 Agent 在做任务时会不会泄露数据——两者都是"输出层以下真实状态被长期低估"这个 2026 年主题的不同切片。

适合谁读

AI 安全 / 合规团队：直接可作为内部多 Agent 系统隐私审计的基线工具，41.7% 漏报率是汇报材料里最有冲击力的数字。
多 Agent 框架作者（LangGraph、AutoGen、CrewAI 等）：需要把"内部通道脱敏 / 分区"作为一等公民特性。
企业架构师 / AgentOps 平台设计者：观测性、告警、合规审计的产品设计要把 C1–C7 全部纳入。
学术研究者：这是 multi-agent safety 方向 2026 年最有数据支撑的工作之一，提供了清晰的扩展点（图状架构、对抗攻击、跨模型迁移等）。
隐私法 / 合规顾问：理解"为什么 LLM 厂商的合规承诺在多 Agent 场景里不充分"。

一句话回到 Anan 该记住的点

如果只能记一句话：多 Agent 架构让最终输出看起来更干净，但 41.7% 的隐私违规藏在你看不到的内部通道里。 AgentLeak 的 C2 ≥ C1 是 5 个模型 × 4 个领域一致的稳健规律，不是某家模型的特例。任何"我们审计了 LLM 输出"的合规方案，在多 Agent 场景里都是不够的——必须把 Agent 间消息、共享记忆、工具参数这些"暗通道"显式拉进审计框架。

如果你在做多 Agent 系统、AgentOps 平台，或者要给企业部署 Agent 集群做合规评估，这篇是 2026 年必读的安全基准——没有之一。

补充：与 OpenComputer 一起读

把 AgentLeak 和 OpenComputer 并置看会发现 2026 年上半年浮现的共同主题：评估 Agent 系统只看输出是不够的，必须看输出之下的真实状态。OpenComputer 关心"做对了多少"，AgentLeak 关心"漏了多少隐私"，两篇都揭示了"输出层以下的真实状态"被长期低估。这是个值得记住的研究风向：未来一年，凡是评估 Agent 的工作，几乎都要回答"你看的是哪一层"。

工程落地与核查（Jay）

仓库核查

✅ GitHub 仓库 Privatris/AgentLeak 存在（fetch 验证 200），仓库标题与 README 内容与原文一致，含 benchmark 代码与数据集。
✅ 论文发表在 IEEE Access（非仅 arXiv），IEEE Xplore ID 11569042；arXiv v1 对应 2026 年 2 月提交，IEEE Access 版本为正式发表版。
⚠️ 关键数字存疑：原文称"多 Agent C1 = 27.2%，漏报率 = 41.7%"，但 GitHub README 汇总表给出的是：5 模型平均 C1 = 28.2%，H1（漏报率）= 45.9%，Total Leak = 79.7%。差异来源可能是：① GitHub README 包含更多通道（C3/C4/C6/C7）的贡献，而原文聚焦在 C1+C2+C5 的子集；② 不同模型子集的加权方式不同。建议以 GitHub README 最新数字为准（GitHub 是持续更新的权威来源），原文数字（27.2% / 41.7%）可能来自特定模型子集的平均值，未经原文 PDF §4 验证前应视为参考值。
⚠️ GitHub README 模型数字（Claude-3.5-Sonnet: C1=8.2%, C2=53.9%; GPT-4o: C1=17.2%, C2=76.8%）与原文中"C1=27.2% / C2=68.8%"的差距说明：原文综合了不同实验配置（可能单 Agent vs 多 Agent 的 C1 差异，或不同场景加权的聚合），建议以 README 最新数字 + PDF §4 实验配置为准。

工程落地三步走

第一步：内部通道可见性改造（必须先建观测能力）

在加任何防御之前，你得先看见 C2/C3/C4/C5/C6/C7。绝大多数 LangChain / AutoGen / LangGraph 应用默认不记录 Agent 间消息、共享上下文快照和工具调用参数。

# 最小化 Agent 间消息拦截（以 LangGraph 为例，示意代码）
from langgraph.channels import Context

class SensitiveChannel(Context):
    """包装 Context，记录所有跨 worker 的消息"""
    def __init__(self):
        self.history = []
        self.sensitive_fields = []

    def send(self, from_node, to_node, payload):
        # 拦截并脱敏
        redacted = redact_pii(payload, self.sensitive_fields)
        self.history.append({
            "from": from_node, "to": to_node,
            "original_len": len(payload),
            "redacted_len": len(redacted)
        })
        return redacted

# 每次 agent invoke 后：
# 1. 快照共享记忆（含敏感字段标记）
# 2. 记录工具调用参数（C3）
# 3. 写入不可篡改的操作日志（Syslog / SIEM）

关键坑：拦截层本身不能成为性能瓶颈（尤其是高吞吐场景）；建议用异步写日志 + 采样降频。

第二步：脱敏边界设计（C2 一等公民）

脱敏应该在数据进入 Agent 集群之前完成，而不是在每个 channel 里分散做。

数据入口 → PII 检测 → Token化/替换 → Agent 集群（已无明文 PII）
         ↑
    这一层不做，后面 7 条通道全暴露

具体操作： - 结构化 PII（姓名、身份证、银行卡）：正则匹配 + 替换为 {PII_TYPE}:{UUID} - 非结构化 PII（地址、诊断描述）：LLM 辅助识别 + 替换 - 字段级别最小化：worker 不需要知道患者全名，只需要知道 {patient_id} 即可完成分析

第三步：合规审计框架接入（用 AgentLeak 测自己）

# 克隆 AgentLeak
git clone https://github.com/Privatris/AgentLeak
cd AgentLeak

# 用你的多 Agent 系统跑评测
# 1. 导入你的 agent 编排代码
# 2. 对齐 7 通道探针植入点
# 3. 跑 1000 场景的子集（建议先跑 50 个场景快速摸底）

python -m agentleak.eval \
    --framework your_framework \
    --scenarios data/your_scenarios.json \
    --channels C1,C2,C3,C4,C5,C6,C7 \
    --num_runs 50 \
    --output ./audit_results.json

审计结果解读： - C1 低、C2 高：典型"输出干净但内部脏"，说明上下文最小化没做好 - C2 ≥ C1 在你的系统也成立：说明 AgentLeak 结论可复现，C2 防御是必答题 - Total Leak > 60%：说明内部通道泄露比最终输出严重得多，需要优先加固

主要坑点清单

坑	描述	缓解
拦截性能开销	每条 agent 消息都过拦截层，高吞吐场景可能掉 5-15% 吞吐	异步写日志 + 采样；关键通道优先拦截，次要通道采样
隐蔽通道漏拦截	某些 agent 用 system prompt 或 tool result 传敏感数据，常规拦截会漏	用 AgentLeak 框架的 7 通道探针做全量覆盖；不要只看消息内容
跨框架通用性	AgentLeak 主要测 coordinator-worker；图状 / 层次化架构的通道完全不同	在你的框架上跑 AgentLeak 时，先画通道图再植入探针
模型更新结论漂移	GitHub README 未覆盖 Claude 3.7 / GPT-4.5 / o3；新模型可能改变 C2/C1 排序	每换一次模型，重新跑 AgentLeak；至少每季度一次完整审计
对抗攻击未覆盖	AgentLeak 测的是无意泄露，不测恶意 worker 主动泄露	需要单独红队演练；AgentLeak 只是必要非充分条件
审计合规留存	C2/C3 日志本身可能含敏感数据，日志库也是泄露面	审计日志也要脱敏后存储；分离存储敏感轨迹与元数据

总结

AgentLeak 揭示的 C2 ≥ C1 + 45.9% 漏报率是经过 GitHub README 验证的稳健结论。工程落地第一步不是加防御，而是先建可见性——拦截并记录 Agent 间消息、共享记忆快照、工具调用参数，然后用 AgentLeak 框架测自己的基线。在可见性建立之前，任何"我们审计了输出"的说法都是盲人摸象。