智能体处理个人信息的边界如何持续有效——从 Meta PrivacyLib 看个人信息保护的运行机制

编者按

假设用户让智能体“把上周出差的费用整理好，提交报销”。为了完成这项任务，智能体需要读取邮件、提取票据、核对行程，进而调用企业的报销系统。对用户而言，自己交代的只是一件事；但在系统内部，实际展开的却是一连串个人信息处理行为。至于哪些邮件可以读取、票据是否需要发送给外部模型处理、整理出的消费记录能否存入长期记忆，往往并非在任务启动前就全部锁定，而是在任务执行过程中才逐步确定。

这给个人信息保护提出了一个直接而具体的问题：当任务的执行路径尚未完全展开时，应当怎样划定个人信息处理的边界？而在执行路径动态变化的过程中，又怎样确保这些边界持续有效？

2026年10月27日，Meta公开介绍了其隐私保护基础设施中的PrivacyLib。这一机制将隐私规则的执行直接嵌入底层的数据访问环节，并通过AgentLib把内部智能体的工具调用与当前会话关联起来，使下游系统能够结合调用上下文和数据标注，实时决定是否放行相关操作。在已经接入并启用控制的链路上，即便智能体在运行中选择了开发者事先未曾预料的工具组合，只要触及数据访问，相关操作仍须接受合规检查。

在公号君看来，这项实践最值得关注的地方，在于它为一个经常停留在原则层面的难题提供了可落地的实现路径：智能体固然可以自主决定怎样规划步骤、完成任务，但个人信息的处理权限必须在每一次具体的数据操作中得到核验。换言之，智能体的自主性可以延伸到任务执行方式，却不能自行扩张个人信息的处理目的和使用范围。

一、任务授权需要落实到具体处理行为

回到开篇报销的例子。允许智能体读取本次出差的票据，并不意味着允许它顺便分析员工过去一年的消费习惯；允许它调用搜索工具，也不意味着可以把包含姓名、住宿地点和消费明细的内容直接写进搜索词对外发送。可以看到，即便两项工具本身都在可用之列，一旦组合使用，仍然可能形成超出原定任务范围的信息流向。

之所以会出现这种落差，是因为“工具权限”与“个人信息处理权限”所回答的本就不是同一个问题。前者解决的是系统在技术上“可以调用哪些能力”；后者则要进一步回答，这些能力可以用于哪些人的哪些信息、出于什么目的，以及产生的结果可以交给谁。也就是说，即便同一个人使用同一项工具，只要背后的处理目的或数据接收者发生变化，该项操作在法律和合规上能否成立的条件就会随之改变。

我国《个人信息保护法》第六条要求处理个人信息应当具有明确、合理的目的，并与处理目的直接相关，对收集范围亦提出最小必要要求；第十三条则要求处理活动必须具备相应的合法性基础。把这些要求放到智能体场景下审视，“用户发出了任务指令”、“当前账号在技术上能够访问数据”与“具体处理行为具有法律依据”其实是三个不同层面的问题，需要分别加以判断。例如，企业员工提出“帮我分析这些客户”，固然可以启动一项业务请求，但系统不能仅凭员工的这句话，就直接决定将客户资料交给新的外部服务商，或者转而用于另一项业务。在系统运行时，具体操作应当关联所适用的处理依据，并据此检查告知、同意等法定条件是否满足。

因此，在设计智能体时，关键一步是把用户交代的任务转化为系统可执行的处理边界。仍以报销任务为例，系统应当将其落实为特定人员、特定出差期间和报销所必需的字段范围，并限定仅允许向指定的报销系统提交材料；如确需调用外部模型辅助处理，还应事先确定该模型服务商被允许接收哪些内容。这些边界由可信的业务系统和权限机制先行确定，作为后续一切操作能否放行的判断依据。模型在运行中可以提出读取或发送数据的请求，但不能为了让请求通过，而在执行过程中自行修改任务的用途设定。

或许有人会问，这是否意味着每次工具调用都必须弹出窗口让用户逐一批准？当然没有这个必要。凡是落在已明确用途和既定范围之内的操作，完全可以由底层系统依据既有规则持续自动核验并执行；只有当任务推进过程中确实需要新增处理目的、接收者或者扩大信息范围时，才需要触发额外的实质审查。如此一来，既能让用户的真实决定贯穿任务全过程，也能避免把复杂的底层技术调用，重新变成一长串令用户疲于应付、实则难以判断的“同意”按钮。

图1：任务授权如何落到操作。业务系统将任务转化为具体处理边界，并在每次操作时核验。

二、把检查放在数据真正流动的地方

既然处理边界需要在运行过程中持续核验，检查机制究竟应当放在哪里？PrivacyLib的做法，是在后端服务所使用的数据访问客户端库中设置共同的检查机制。这里所说的“客户端”，并非面向终端用户的应用，而是后端服务用来访问数据库、日志系统等底层基础设施的软件库。这一位置恰好处于数据流动的关口：它既知道当前操作具体要触及哪个数据资产，又能够取得调用者、接口端点和处理目的等运行上下文，因而最适合对每一次具体的数据操作作出判断。

在具体运行流程上，智能体发起工具调用后，AgentLib首先把该次调用与对应的智能体会话关联起来，由下游服务沿着调用链继续传递有关上下文。当请求到达底层数据访问环节时，PrivacyLib便将本次操作、调用上下文和目标数据资产的标注一并交给相应模块处理：其中，策略分区（Policy Zones）负责执行用途和信息流向限制，智能体可观测性（Agent Observability）则负责记录会话标识、工具调用和访问目标等信息，以便事后调查数据实际经过了哪些系统。简言之，“决定是否放行”与“记录访问轨迹”在系统中各司其职。

图2：在数据访问处执行规则。PrivacyLib 结合操作、上下文和资产标注，分别执行策略控制与访问记录。

Meta的技术文章以“消息元数据写入”为例，直观说明了这种判断是如何发生的。当系统准备写入数据时，既要检查当前调用上下文是否属于允许使用消息元数据的情形，也要检查准备写入的目标数据表是否带有相应的合规标注。在启用强制执行模式后，上述两项条件只要有一项不满足，该条记录就会在发送到下游之前被直接阻断。不难看出，这种设计同时约束了数据的“当前用途”和“后续去向”：即便本次处理在当前环节获准，系统仍要保证接收数据的下游目标能够继续承接相应的保护限制。

数据标注（data annotation）在整个机制中的枢纽作用也由此清楚起来。它将数据资产与所适用的隐私规则连接起来，使不同业务服务能够按照一致的语义理解和执行限制。Meta此前在介绍Policy Zones时就已提出，下游数据所承受的保护限制原则上不得弱于其上游来源，并对标注的创建、关联和移除实施专门治理。换言之，保护条件可以随着信息流转一路向下延续，调用者不能通过简单地换一张表存储或者删掉一个标签，就把原有的用途限制消除。

把规则校验放在实际的数据访问环节，还从架构上回应了智能体执行路径难以事先预见的问题。在复杂任务中，智能体的工具组合方式可以不断变化，但无论路径如何调整，只要最终需要读取数据、写入存储或者向另一服务发送请求，总要经过具体的底层接口。PrivacyLib把异构系统的读写操作映射到共同的策略执行模型，使新的保护规则能够直接复用已经建立的检查位置；而对受支持的直接远程过程调用（RPC）路径，则再通过较低层边界的验证予以补充覆盖。

这一工程做法对智能体合规设计的启发十分明确，即让实际产生数据处理效果的必经路径接受统一检查，并严格以预先确定的处理目的、数据范围和接收条件作出决定。如此一来，即便外部不可信文本通过提示词注入等方式诱导模型提出新的越界操作，模型本身也不能因此取得修改底层校验条件的权限。模型负责选择下一步业务行动，执行层负责核验该行动是否越出法定的个人信息处理边界，两者权限分离，各自承担明确的职责。

三、信息经过加工，原有使用边界仍须延续

个人信息进入智能体工作流以后，往往会改变原有形态。几张原始票据可以变成一份报销摘要，多封往来邮件可以被归纳为一段人员介绍，日常聊天记录也可以转化为高维向量并存入长期记忆。问题随之而来：这些内容经过加工以后，原来的用途限制是否还在？

如果控制系统只懂得识别原始文件或原始表，就会留下一个很直接的规避缺口。举例来说，规则不允许将原始票据直接传给外部搜索服务，智能体在读取票据后，却完全可以把员工姓名、差旅行程和消费情况重新表述一遍，再作为搜索词发送出去。表面上看，文件名和文字表达都已经改变，但其中包含的个人信息以及对个人权益的影响依然存在。更关键的是，在智能体把摘要写进搜索参数并发出请求的那一瞬间，数据就已经传给了外部服务；倘若等到最终向用户生成答案时再做内容过滤，根本无法撤销此前已经发生的违规传输。

因此，沿着Policy Zones的思路设计智能体系统，应当让相关限制随着数据加工同步延续到派生内容之上。一个可行的起点，是让任务执行过程中的输出默认保留有关输入的来源标识和使用条件；如因业务需要提高后续使用的灵活性，再进一步细化追踪粒度，明确输出中的哪些字段或计算结果实际依赖哪些受限来源。相应地，负责处理文本摘要、向量数据库和长期记忆的系统，也必须能够读取这些附随条件，并在派生内容被再次调用、检索或对外交付时严格执行。

在这方面，安全界关于CaMeL架构的研究提供了颇具参考价值的实现方法。该方案通过模型本体之外的独立解释器，为运行时的数据变量维护来源和允许读取者等元数据，在运算过程中自动传播依赖关系，并在每次工具调用前执行安全策略。这一机制说明，“数据以何种形式被模型使用”与“数据随后可以被交给谁”，完全能够在系统中拆解开来、分别判断。

进一步来看，对于经过加工后的内容，在规范层面还应区分两种不同情况。第一种情况是原有个人信息仅仅换了表达方式或载体形态，此时需要维持既有的保护条件，确保限制得到完整继承；第二种情况则是若干原本分散的信息经过交叉组合与推理，形成了关于个人属性的新判断，此时还需要重新识别其性质。例如，对员工的消费记录作简单金额汇总，与根据这些记录进一步推断出特定人员的健康状况，所涉及的保护要求就截然不同——后者已经衍生出敏感个人信息的推断结果，不仅要求原有使用限制得到继承，还要求对新产生的信息补充分类并升级保护措施。

图3：加工之后，限制继续。来源和使用条件随派生内容延续；形成敏感推断时，补充分级保护。

当然，对派生内容调整或解除限制，同样需要明确的依据和独立的权限。只有当某项数据转换确实满足了预先确定的去标识化、匿名化或汇总脱敏条件时，系统才可以据此对其进行重新分类；而重新分类之后的数据能够用于什么目的、交给哪些接收者，仍须由相应规则确定。正因如此，Meta将“重新分类”纳入专门治理流程，使标签调整受到独立约束。放到智能体场景下，道理同样简单：智能体自己在上下文中生成一句“以上内容已经匿名化”，绝不能代替系统层面的合规判断。

四、跨智能体委托需要保留权限和来源

在更复杂的场景中，一个主控的报销智能体还可能把票据分类交给第二个智能体，把缺失材料核验交给第三个智能体。每次任务委托固然缩小了单个智能体处理任务的复杂程度，但同时也拉长了个人信息流转的链条。如果在转交任务时，下游智能体只收到一句自然语言指令“请处理这些材料”，那么原任务所确定的处理目的、对象范围和接收限制，就很容易在多次转交中悄然丢失。

因此，跨智能体的任务委托需要同时向下游传递两类关键信息：一类说明下游在本次子任务中“被允许做什么”，另一类说明所收到的材料“来自哪里、受到哪些既有限制”。具体而言，子智能体在单次任务中实际取得的处理范围，应当由“上游可委托的权限范围”、“子智能体自身的系统权限”以及“完成当前子任务的实际需要”三者共同限定。换言之，即便某个子智能体本身在系统配置上能够访问更广的数据库，也不意味着上游智能体可以借助任务委托，利用它的高权限来扩大当前任务的处理范围。

除了权限边界之外，数据来源信息的连续性同样重要。2026年10月发布的预印本论文《Can CaMeLs Talk?》展示了一种典型的跨智能体风险：在上游智能体中原本作为“外部不可信数据”处理的内容，一旦被写入发往下游智能体的自然语言任务描述后，下游往往会将其当作来自上游的“可信指令”执行，攻击由此得以跨智能体接力继续。该研究据此提出，应当通过分离控制指令与业务数据通道，并在智能体之间持续保留来源信息，来约束这种隐蔽的“信任升级”。

对个人信息保护而言，这一安全领域的发现具有直接启发。无论是发票、邮件还是网页中的文字，在系统中都应当始终保持其作为“任务材料”的身份；绝不能因为经过了一个智能体的总结或转述，就摇身一变取得“控制指令”的地位，进而获得改写任务范围、指定新收件人或者要求将数据另作他用的权限。只有确保每次转交都原原本本地保留原有的处理条件与来源属性，下游智能体才有依据判断自己能否接收这批材料、可以在什么范围内使用，以及后续还能继续传给谁。

图4：委托权限取三者交集。本次委托权限由三项范围共同限定，来源和限制随业务数据传递。

更进一步看，技术架构上的委托调用关系，还要与法律规范上的数据处理主体关系精准衔接。同样是一次跨智能体调用，究竟是同一企业内部两个智能体模块之间的分工协作，还是跨越组织边界、向另一家企业的模型服务提交材料，在法律上适用的是完全不同的规则。我国《个人信息保护法》第二十一条、第二十三条分别规定了“委托处理”和“向其他个人信息处理者提供个人信息”的法定要求。因此，智能体平台的工具目录除了记录技术接口参数和功能描述之外，还应当同步关联接口背后的组织主体、实际处理角色以及合同约定的处理范围。唯有如此，运行时的技术调用链，才能在法律上转化为清晰、可核验的责任关系链。

五、让规则在系统运行中持续兑现

行文至此可以看到，无论是数据标签还是调用上下文，其能否在运行中持续发挥作用，归根结底取决于背后的规则由谁制定、谁有权调整，以及规则的变更怎样准确到达各个执行位置。技术层面的自动执行，由此与组织层面的合规治理紧密联系起来。具体而言，要让规则在系统运行中持续兑现，需要重点落实好以下四个方面的工作：

首先，对处理目的和必要范围的界定必须有实质判断做支撑。技术上的标签核验机制本身并不自动产生合理性：假如报销系统虽然始终规范地携带“报销”标签，但后台对应规则所允许读取的范围却包括员工的全部邮箱、全部消费记录乃至家庭成员信息，那么底层机制执行得再准确，也不过是在精准执行一项过宽的规则。因此，智能体系统建设应当从具体业务任务与必要数据的实质关系出发，形成业务需求、法律评价和技术配置之间可核验的对应关系，而不能用一句笼统的“模型推理时可能用得上”来代替必要性说明。

其次，系统规则要随着任务进程和个人权利状态的变化及时调整。在工程实现上，PrivacyLib采用了缓存和分服务部署等方式来降低运行成本、控制规则变更的影响面。当把这套机制用于个人信息保护时，就需要同步管理好策略版本、部署范围和缓存失效机制，确保后续的每一次操作都能够依据当前有效的规则作出决定。举例来说，当本次数据读取或对外发送所依赖的任务授权已经终止，或者个人同意已经依法撤回时，系统就不能再继续援用基于既往授权或同意所形成的历史放行结果。

再次，智能体的长期记忆和数据删除机制需要单独落实。为完成一次报销任务所需的临时性处理，与把相关材料保留到长期记忆中供未来任务使用，具有截然不同的处理范围和保存期限要求。系统应当在底层记录长期记忆、文本摘要和向量索引与原始数据来源之间的映射关系：当适用的删除条件成立时，能够据此精准定位并清理有关内容；而在存在法律、行政法规规定应当保留的情形时，则按相应要求限制其继续使用，在运行时阻断后续检索与调用。简言之，“停止后续访问”和“处理已有副本”，各自有需要落地的技术动作。

最后，要使上述运行控制措施本身可核验。Meta为了降低海量遥测数据的成本采用了去重和采样策略，这种做法固然适合宏观分析运行模式和排查异常；但对于需要定责追溯的具体个人信息处理活动，系统则还应完整保存必要的授权来源、策略版本、访问对象、数据接收者及最终执行结果。当然，留存审计记录完全可以使用身份引用和资产标识符，大可不必为了证明“保护有效”，而在日志系统里再复制一份完整的个人信息。

图5：规则怎样持续生效。必要范围、规则更新、记忆清理与审计记录，共同支撑运行中的持续核验。

归根结底，上述要求最终需要由参与处理的各组织按照各自角色逐一落实。谁决定个人信息的处理目的和方式，谁提供受托处理服务，谁实际掌握工具、权限和数据流动的执行位置，都应当在系统设计与合同安排中明确界定。只有把相应的合规决定做成系统中可执行、可拦截、可追溯的规则，才能使各参与方所承担的个人信息保护义务，在智能体动态运行的过程中得到实际履行。

回到开篇的报销任务。用户真正需要的智能体自主性，是系统能够在合理范围内自主完成步骤选择和任务协调；而要让这种自主性与个人信息保护相容，个人信息的处理边界就应当始终与具体的处理目的、最小必要的数据范围和明确的接收条件相联系，并一路延续到数据加工、记忆保存和跨智能体委托之中。

Meta的PrivacyLib把面向运行时的持续核验推进到了底层数据访问基础设施。沿着这一思路，将规则检查进一步延伸到派生内容、长期记忆和跨智能体委托链条，智能体时代的个人信息保护便有了一条贯穿任务全过程的执行路径。任务可以动态展开，但处理权限不能在读取、生成、保存和转交的过程中自行扩大。唯有让每一次具体操作都依据当时有效的规则作出决定，让每一次信息流动都完整承接相应的保护限制，各参与组织才能在复杂多变的系统运行中切实履行其个人信息保护义务。

文章索引

数据保护官（DPO）社群主要成员是个人信息保护和数据安全一线工作者。他们主要来自于国内头部的互联网公司、安全公司、律所、会计师事务所、高校、研究机构等。在从事本职工作的同时，DPO社群成员还放眼全球思考数据安全和隐私保护的最新动态、进展、趋势。2018年5月，DPO社群举行了第一次线下沙龙。沙龙每月一期，集中讨论不同的议题。目前DPO社群已超过400人。关于DPO社群和沙龙更多的情况如下：