员工同意Agent“帮我整理会议”，随后它读了旧邮件，又把发言人姓名发给外部转录工具。员工原本只是想整理今天的纪要。子Agent再接手排期时，谁来决定纪要能否继续转交？人往往在第一步点了允许，数据却在后来几步才真正离开原有边界。MLCommons AI Risk & Reliability项目发布的《Agent Privacy Risk Taxonomy v0.1》把这一类难题纳入25类隐私风险。这份分类列出了五个领域，并计划在2027年一季度前推进下一阶段工作。本文不替草案编写25条逐项条文，而是沿着五个领域讨论企业能落地的检查方法。
先弄明白风险是怎样长出来的
普通聊天场景常把输入和输出看作一次会话。Agent的操作边界不同：它可以长期观察工作环境、跨会话保留信息、用工具读取新资料，把任务委派给别的Agent，还可能生成代码去处理数据。即使每一个局部动作表面上有用途，一串动作接起来，也可能让原本只供内部排期使用的联系人信息跑进外部分析系统。
MLCommons将25类风险归入五个领域：数据摄取与处理，数据聚合、使用与共享，跨Agent隐私实践不一致，静态同意模型失效，以及责任与治理。这是一个风险分类框架，不等于“25个已被证明一定发生的漏洞”，也不是认证清单。企业读它，重点是找出自己系统里数据跨过的边界：来源、用途、接收者、时间和决策者。只有五个维度能在日志与策略中落地，风险字典才有用。
产品设计最容易漏掉用途悄悄改变：先为回答问题读一份文档，再为提高回答质量读更多历史，再为了让子Agent继续工作把整个上下文打包发送。很多数据没有在某个单独的步骤显得多余，但累计之后的画像已经超出用户最初理解的授权范围。不要只问“API有没有加密”，还要问“为什么需要这份数据、谁会在下一跳看到”。
数据摄取与处理：入口越宽，后续越难管
企业Agent接入知识库、IM、邮件、CRM和工单系统时，默认搜得到不等于本次任务需要。员工请求查询一项客户工单，检索器却把同一客户的全部历史往来、内部投诉与其他联系人的号码都塞进上下文，这就是应该被质疑的摄取边界。这里的情境是企业检查示例，不对应MLCommons草案里某条原文风险的逐字定义。
可执行的办法是让检索层先识别任务对象与允许字段，而不是把最宽的读取权限交给大模型自己节制。对文档要保留来源标识、访问控制标签和保留期限；对工具返回要做字段级过滤，必要时把原始个人信息替换为任务内临时标识。与其事后统计“模型看过什么”，不如在进入上下文之前就限制它能看到什么。
还要检查记忆。短期缓存、向量索引、轨迹日志与长期用户画像未必由同一个系统维护。用户以为删除了会话，调试日志里仍可能有原始联系人。上线前应列出每份拷贝的归属、过期机制和删除路径，并用实际删除演练验证，而不是仅在制度里写“支持删除”。对高敏数据，默认不进入长期记忆，比尝试以后从许多副本里逐一清除容易得多。
聚合、使用与共享：单项可见不代表组合可用
两个部门分别拥有的资料，可能都能被Agent合法读取；合并之后却产生一个新的敏感事实。典型例子是把请假时间与健康咨询记录关联到某位员工。即使结果没有发往外部，合并后的用途也可能与原始授权不一致。分类里的“聚合/使用/共享”提醒企业，不能只给每个数据库打一个可读或不可读的二值标签，还要管理派生数据的用途和下游传播。
设计检查时，可以让每一条数据随请求携带最少的元信息：来源、原始用途、敏感级别、主体、有效期与允许接收者。生成摘要、表格或向量表示时，派生物也继承限制；不能因为经过概括，便视为完全脱敏。真正能降低风险的脱敏要按重识别可能性和具体使用场景评估，删掉姓名不等于删掉所有识别线索。
对外部工具则应按接收方控制数据。调用日历接口只传排期需要的空闲时间与必要参会人，不必附上会议原始讨论全文；调用翻译工具若不得不带敏感段落，就需要单独确认服务方、保存策略和跨境边界是否被允许。这些是企业系统设计建议，不是MLCommons已经审定的合规结论。对所有高风险转交，留好“给了谁、给了哪些字段、基于哪项授权”的记录。
跨Agent协作：接手任务的人，未必接得住原来的限制
任务一旦委派给二级Agent，上游的限制常在自然语言转述中丢失。主Agent知道“只能为这场会议做摘要，不能把原文发给外部”；子Agent看到的却可能只是一句“请尽快处理这份材料”，加上一份完整附件。两个Agent各自的权限模型、日志粒度与记忆策略也可能不一致。危险不取决于它们是否自称同一个团队，而取决于数据跨过了一条新的处理边界。
企业可以规定委派必须通过结构化任务信封：任务目的、允许输入字段、禁止用途、授权主体、到期时间、下游接收者与回传格式。子Agent收到后先验证自身工具权限是否足以满足这些限制，无法满足就拒绝接单或退回要求人工处理。主Agent不能把“请注意隐私”写在提示词里，就认定下游实现了相同的控制。尤其是调用第三方托管Agent时，应审查传输与保留条件，并给数据流画出实际路径。
还有一个常见误区：把中间结果当作普通文本。一份由客户记录提取的行动清单，虽然不再含客户姓名，仍可能有项目代号、时间、地点和独特交易细节。策略应覆盖源数据与派生结果，跨Agent的每一跳都要核对接收范围。没有端到端保证时，缩短链条往往比增加更多“聪明助手”更安全。
一次同意无法覆盖后来的新情况
MLCommons把静态同意模型失效单列为风险领域。为什么？因为Agent执行任务时才会遇到新的文件、新联系人或新的外部服务。用户最初说“帮我安排出差”，并不一定预见到系统要读取旧病历以推荐座位，或把个人行程共享给不在原请求中的供应商。授权应跟着运行中的实际动作走，不应该把第一次点选的“允许”延长成无限期通行证。
一个实用的运行时决策至少问六个问题：是谁发起请求；此刻要读取或写入什么；处理目的是什么；工具与下游接收方是谁；授权还在不在有效期；动作能否撤回。如果目的、接收者或敏感级别发生变化，系统在动作发生前请求新的确认。低风险、同类且可逆的重复操作可以按范围授权；向陌生外部接收者发送原始资料、作出不可逆写入，宜采用逐次确认。弹窗数量不能替代决策质量，过度弹窗只会让人机械点击。
撤回更棘手。系统不能假设“取消同意”会自动抹去已经转交的文件。它至少应阻止后续调用，标记已经传播的副本，按合同和技术接口触发删除或限制使用，并向用户说明哪些处理已无法逆转。若下游没有可执行的删除机制，授权界面不能暗示随时可完全收回。制度里的“可撤销”，必须对应工程里的状态转换和回执。
责任与治理：出事时谁能把链路复原
隐私治理不该只留一份年度政策。企业需要知道哪位业务所有者批准Agent接入资料，哪个系统提供授权依据，哪个服务接收数据，谁负责处理撤回与事故。一个动作若经过检索、模型推理、插件调用、子Agent、第三方API五步，少记一环，事后就难以回答“信息到过哪里”。日志也有悖论：记录越完整，日志本身越可能成为敏感资料仓库。审计所需的标识、时间、目的和字段类别可留，原始内容则按最小必要原则限制读取和保存。
治理机制可以从一张数据流图开始，而不是先买一套“隐私AI平台”。选出高风险Agent，标记所有数据源和外发点；对每条边写明合法用途、批准角色、保留期限、撤回路径和事故联络人。接着拿几条真实但脱敏的场景演练：用户中途改变目标、第三方工具临时不可用、子Agent请求额外字段、用户撤回授权、审批人离职。检查系统是否停在正确的位置，而不是事后生成一段貌似有条理的解释。
还可以设置几条简单的运行指标：未获允许的敏感字段进入模型上下文的次数，向新接收方转交前的确认覆盖率，撤回到停止后续处理的耗时，审计链路可复原比例。指标设计必须与本地数据保护义务、业务风险和技术架构配套，不能声称这是MLCommons已经发布的统一Benchmark。分类提供问题目录，评分与监管适用性要由部署方进一步验证。
把授权做成状态机，而不是一排复选框
实施时可以给每项数据处理建立明确状态：未授权、限范围授权、待追加确认、已撤回、已过期。请求到达时策略服务读取数据标签和任务目的，决定放行、缩小字段、询问用户还是拒绝；Agent本身不应有权修改自己的授权状态。每次跨工具或跨Agent调用都重新带上授权标识与有效期，下游按最小权限校验，而不是相信上游的一句“已取得同意”。这是工程建议，不声称属于MLCommons发布的标准架构。
授权范围要能被人理解。让用户看到“允许读取今天这场会议的纪要并写入本人日历”，比一个含糊的“同意使用我的数据”更可判断。出现新接收方时，确认页说清接收机构、拟发字段、用途和保留期限；如果无法提供其中某项信息，就先暂停发送。用户若拒绝，Agent可回到原任务，询问是否使用本地处理或跳过该功能，而不是改走另一个不受控工具绕开决定。
撤回事件也要可测试。先在实验环境批准Agent读取一份模拟文档，让主Agent转交给允许的子Agent，然后在中途撤回。观察后续读取是否停止、缓存是否失效、任务队列中未执行的动作是否取消、下游是否收到删除请求以及审计日志是否保留处理证据。已经完成的外发不能用一个绿色“撤回成功”按钮抹掉，界面必须区分“停止未来处理”和“已传播数据的处置进度”。
让一次采购评审真的试出边界
供应商展示隐私能力时，别只让它播放正常流程。准备一份包含员工联系方式的脱敏测试纪要，先允许“生成内部摘要”，中途要求把摘要发给新出现的外部合作方，再让用户撤回同意。评审逐步查看系统是否暂停、展示拟转交的字段、保存确认依据，以及撤回后停止哪些动作。把相同脚本交给不同供应商，更容易分辨“有一个同意按钮”和“数据流真的受控”。
合同审查也应对应技术动作：第三方服务能否再委托处理，日志保留多久，怎样响应删除请求，发生误发时提供什么证据。测试时只用合成或脱敏数据，不要为了逼真把真实客户资料喂给未签约的演示环境。若供应商无法展示下游接收方和已转交副本的处置路径，先把外发功能关闭；本地摘要仍可在有限授权下运行。审慎上线不等于拒绝Agent，而是让产品能力服从可说明的数据边界。
v0.1意味着什么，采购又该怎么用
v0.1仍是草案，不是强制标准。根据MLCommons发布的资料，项目计划和大规模部署者一起确定优先风险，随后制定指标、试点Benchmark和缓解实践，目标在2027年一季度前推进下一阶段工作。今天采购产品，不宜要求供应商拿出并不存在的“MLCommons认证”；更合适的要求是让它画出数据流、展示运行时授权和撤回演练，说明子Agent或第三方工具如何继承限制，并提供一次事故追踪样例。
资源有限，就先管入口字段、外发授权、撤回执行与审计复原，之后再沿五个领域扩展测试用例。新接收方出现时，系统应检查原授权是否适用。若找不到授权依据，就先停下转交。
参考资料
- MLCommons，《What Could Go Wrong When Agents Handle Your Sensitive Data? A New Taxonomy Answers》，2026-10-01：五个风险领域、v0.1状态及2027年下一阶段工作安排。
- PPC Land，《MLCommons catalogues 25 privacy risks posed by AI agents》，2026-10-04：25类风险与事件链的交叉资料。