可信数据空间 × Agent：从用途合约到域内 enforcement 的工程落地

Deep Research 报告 | 2026 年 7 月 | 面向数据要素、可信数据空间、隐私计算与平台工程从业者，关注跨组织数据流通与 Agent 落地的团队

---

摘要

这是"Agent 时代数据治理"系列的第三篇。前两篇——《Agent 打破了 20 年数据治理》讲清了架构分水岭（enforcement 要下沉到绕不过去的那一层），《Agent 直连数据库的三道关》把它拆成了认证、身份传播、SQL 闸三道可施工的关卡。但这两篇有一个共同的边界：它们都发生在单个组织内部。 数据是你自己的，库是你自己的，IdP 是你自己的。

真正难的场景，是跨组织：数据在别人手里，你想用；对方想让数据"用起来"变现，又绝不能让数据"流出去"失控。这正是可信数据空间（Trusted Data Space）要解决的问题。它的核心机制，用官方文件的话说，就是数字合约 + 数据使用控制：让数据使用方"在合同约定下，按约访问、使用和二次传输"数据，同时"数据不出域、可用不可见"。

过去这套东西很容易停在"合规话术"层面——签个数据共享协议，附一份用途说明，然后……就没有然后了，约束靠信任和事后审计。但 Agent 把这层窗户纸捅破了。 当数据使用方派来的不是人、而是一个以机器速度、探索式访问、概率式生成查询的 Agent 时，"按合约使用"这几个字必须从合同文本，变成在数据方的域内、被强制到 Agent 绕不过去的可执行策略。

这篇就讲清楚这条落地路径的三段：

1. 用途合约怎么从"合同文本"变成"可执行策略"——ODRL 的权限/禁止/义务、IDS 的 21 类策略，以及"只落地 8-9 类"的残酷现实 gap。
2. 连接器怎么当"域内 enforcement"的守门人——数据不出域，策略在数据方的域里执行。
3. Agent 概率式访问下，域内 enforcement 的三种硬手段——连接器 Usage Control、TEE 机密计算、确定性信息流控制/粘性策略，再叠加区块链存证。

一、可信数据空间到底要解决什么

先把概念落地，不然容易被"数据要素""数据流通"这些大词绕晕。

"数据要素×"回答"为什么要用"，可信数据空间回答"凭什么敢用"。 政策要数据流通起来、释放要素价值，这是动机；但企业心里真正的坎是"我把核心数据给你，你会不会拿去干别的、会不会转手卖了、会不会训了模型我却什么都拿不回来"。可信数据空间就是为了消除这个坎而设计的一套技术—制度基础设施：让数据"可用不可见、不出域、按合约使用"，从而让企业敢把数据拿出来共享。

国家数据局 2024 年 11 月印发《可信数据空间发展行动计划（2024—2028 年）》（国数资源〔2024〕119 号），提出分类推进企业、行业、城市、个人、跨境五类可信数据空间，到 2028 年建成 100 个以上。2025 年 4 月，全国数据标准化技术委员会发布《可信数据空间 技术架构》技术文件，给出了工程骨架：由"服务平台"和"接入连接器"两部分组成，具备身份管理、目录管理、数字合约管理、数据使用控制等核心功能。

其中和本文最相关的是行动计划里点名的"可信管控能力"，它几乎就是前两篇那套逻辑的跨组织版：

• 接入核验：谁能进这个空间——对应"认证"。
• 履约机制 + 数据管控策略：确保使用方"在合同约定下，按约访问、使用和二次传输"——对应"身份传播 + 用途 enforcement"。
• 日志存证与溯源：追踪数据来源、流动路径——对应"审计"。

底层技术，官方定调是区块链 + 隐私计算双底座：区块链管存证溯源与利益分配，隐私计算管"可用不可见"。

那么 Agent 让这件事发生了什么变化？在"人对人"的数据合作里，用途合约哪怕只是一纸协议，配上事后审计，大体也还能约束——因为人的行为是有限的、可解释的。但当数据使用方接入空间的是一个 Agent，它会以机器速度发起海量、探索式、概率式生成的访问，一纸静态合同根本追不上它的行为。"按合约使用"必须从"事后能不能查出来违约"，变成"事前和事中，违约的动作根本执行不了"。这就是 Agent 把可信数据空间从合规话术逼成工程题的地方。

二、用途合约：从"合同文本"到"可执行策略"

可信数据空间的心脏是"数字合约"。但"数字合约"这四个字有一个致命的歧义——它到底是一份存在链上的电子合同（文本），还是一段能在运行时被机器强制执行的策略（代码）? 这两者天差地别，也是国内很多试点最容易滑过去的地方。

国际上 IDS（International Data Spaces）体系把这件事想得比较透，值得直接借鉴。在 IDS 里，一份 IDS Contract（合约） 被明确拆成两部分：合约元数据（签发日期、参与方等，对 enforcement 无影响）和 Usage Control Policy（使用控制策略）——后者才是"组织与技术层面强制执行的核心动机"。而这个策略用 ODRL（开放数字权利语言） 表达，由一组称为 IDS Rules 的语句构成，只有三种原子：

• 权限（permission）：可以做什么（比如"允许查询用于风控建模"）。
• 禁止（prohibition）：不可以做什么（比如"禁止导出原始明细""禁止二次转售"）。
• 义务（obligation）：做了之后必须履行什么（比如"使用后 30 天内删除""每次使用留痕上链"）。

这套抽象的关键在于，它把"用途合约"从人读的自然语言，翻译成了机器可判定的规则。IDSA 定义了 21 类策略，其中第 10 类正是 "用途受限使用（Purpose-restricted Data Usage）"——这就是"用途合约"最精确的技术对应物；还有第 12 类"限制使用次数"、第 14 类"使用后在指定时间删除"等，都是可以被运行时强制的。

但这里有一个必须讲清楚的现实 gap，否则会对落地过度乐观：标准定义了 21 类，主流开源连接器实现（Dataspace Connector）当前只落地了其中 8-9 类。 换句话说，标准里写得很美的很多策略，工程上还没有可用的强制实现。更进一步，Eclipse Dataspace Components（EDC，实现了 Dataspace Protocol）虽然提供了策略引擎框架，但它只给框架、不给全部策略逻辑——具体的评估函数要开发者自己用代码实现、绑定到运行时上下文、注册到策略引擎。

所以第一段落地路径的结论很硬：用途合约要真正管用，必须走完"自然语言 → ODRL 规则 → 可执行的评估函数"这条链，并且承认目前只有一部分策略类型有成熟的强制实现。 停在"链上存了一份电子合同"就以为万事大吉，是最常见的自欺——那顶多是"可举证"，离"可强制"还差着整个执行层。

三、连接器：域内 enforcement 的守门人

用途合约变成了可执行策略，下一个问题是：在哪儿执行？ 答案是可信数据空间的第二个核心部件——接入连接器（Connector）。它就是"数据不出域"这个承诺的物理载体。

连接器承担两个职责：一是互操作 API，让空间里各参与方能互相发现、协商、传输；二——也是本文的重点——是可信的策略执行组件。它是数据进出数据方的唯一闸口，是名副其实的 gatekeeper（守门人）。数据消费方不能直连数据源，只能通过数据方一侧的连接器发起请求；连接器的策略引擎在运行时根据已协商的合约来放行或拒绝每一次数据传输与使用。

这就是"域内 enforcement"的确切含义：策略不是在消费方那侧、也不是在中立第三方那侧执行的，而是在数据方自己的域里执行。 数据方保留对自己数据的最终控制权——这正是"数据主权（data sovereignty）"的技术实现。EDC 里策略执行的三步（把规则绑定到运行时 scope、实现评估函数、注册到 PolicyEngine），做的就是把用途合约"焊死"在数据方域内的这个闸口上。

把它和前两篇对照，你会发现是同一套世界观在放大：库内 enforcement 是"把策略下沉进数据库引擎"，域内 enforcement 是"把策略下沉进数据方的连接器"。共同点是——把强制点放到消费方（以及消费方派来的 Agent）绕不过去的那一层。 区别只在于，可信数据空间面对的是跨组织，所以这个"绕不过去的层"不在你自己家，而在数据提供方家里。

四、Agent 把域内 enforcement 的难度又抬高了一档

如果数据消费方是一个规规矩矩、走预定义流程的应用，连接器 + Usage Control 这套基本够用了。但换成 Agent，前两篇讲过的每一个难题都会在跨组织场景里重现，并且放大：

• 谁在用（身份跨空间互认）：Agent 得先证明自己代表哪个合法参与方。国家发改委的专家观点里把数字身份称为可信数据空间的"通关密钥"——跨空间身份互认是互联互通的前提。这比单组织内的认证更难，因为要跨信任域。
• 替谁用（OBO 链跨组织延伸）：一个 Agent 可能替某个真人、经过若干中间 Agent，最终来敲数据方的门。前一篇讲的 OBO / RFC 8693 委托链，在这里要跨组织地保持 sub（真人）和 act（每一跳）不丢——数据方才能按"到底是谁、替谁"来施加用途策略。
• 能用到什么程度（用途 enforcement）：Agent 概率式生成的访问，可能有意无意地触碰用途边界（比如合约只允许"聚合分析"，Agent 却想拉明细）。静态合同管不住动态行为，必须靠连接器在每次调用时实时判定。
• 用完了呢（二次传输与输出侧）：这是最容易被忽略、却最致命的一环。数据方最怕的不是"这次查询",而是"结果被 Agent 拿走后，转头喂给了模型、写进了另一个系统、或流到了第三方"。用途约束必须能跟着数据/结果走，而不是在数据离开连接器的那一刻就失效。

这四条里，前三条前两篇已经给了框架，真正的新难点是第四条——输出侧的持续管控。因为 Agent 的本质就是"把数据搬来搬去、加工、再分发"，一旦结果脱离了数据方的域，传统访问控制就彻底失效了。这就逼出了下一节要讲的、比"入口把关"更强的几种硬手段。

五、域内 enforcement 的三种硬手段

面对 Agent，"域内 enforcement"不能只有连接器这一道入口闸，需要分层叠加。按强度和成本从低到高，有三种手段，外加一个贯穿始终的存证层。

手段一：连接器 + Usage Control——入口处的策略闸。 这是基础，上一节已经讲透：把用途合约编译成 ODRL 规则，在数据方连接器的策略引擎里，对每一次访问做权限/禁止/义务判定。它解决"这次访问允不允许、能取多少"。局限是——它管得住"数据出不出门",管不住"出门之后的数据被怎么用"。

手段二：TEE / 机密计算——让数据"可用不可见"，且计算过程可验证。 这是"数据不出域"的更强形态：不是不让数据动，而是让计算在可信执行环境（TEE）的加密飞地里进行，数据在使用中（in-use）始终加密，连数据方管理员都看不到中间态，消费方只能拿到约定的结果。2026 年 6 月发布的 Anjuna Overwatch 是个有代表性的思路——它把治理 Agent 行为的"控制平面"本身放进 TEE，经远程证明（attestation）后运行，实时强制"上下文感知的策略"来管控 Agent 的工具使用和数据访问，确保 Agent"只在授权边界内行动"。TEE 的意义在于：它把"信任"从"信任对方管理员"变成了"信任一段经过密码学证明的代码"。 当然，TEE 也不是银弹——它仍面临侧信道等高级攻击，实践上要配合远程证明、恒定时间密码学、持续审计一起用。

手段三：确定性信息流控制 / 粘性策略——让约束跟着数据/结果走。 这一层专治第四条难点：输出侧。学术界已有几个很清晰的思路——**粘性策略（sticky policy）**让策略"粘"在数据上，输入侧和输出侧都带策略，数据流到哪、约束跟到哪（如 Styx 用 TEE 强制的 sticky policy，连输出模型的管控权都由多方联合持有）；确定性信息流控制（IFC）则更进一步，像 GAAP 那样让 Agent 先产出一个代码工件、再对它做信息流分析，从而确定性地保证私有数据的披露符合用户许可——关键是"确定性",不依赖 Agent 或提示词本身是否可信、是否被攻击。对可信数据空间而言，这类技术是回答"结果被 Agent 拿走之后还受不受控"的唯一硬答案。

贯穿层：区块链存证与溯源——履约与审计。 这正好接上国内技术架构"区块链 + 隐私计算"的定位：每一次访问、每一次用途判定、每一次结果交付都留痕上链，形成不可篡改的履约证据链，既支撑事后追责，也支撑数据贡献方的利益分配。它不直接"拦",但它让"拦"和"分"有据可依。

这四层的关系，可以用一句话概括：连接器管入口、TEE 管过程、信息流控制管出口、区块链管留痕。 越往后，管的东西离"数据本身被怎么用"越近，成本也越高。落地时按数据敏感度分层选用，而不是一刀切上最重的方案。

六、一张落地参考架构与自查清单

把上面的东西拼起来，一个面向 Agent 的可信数据空间"域内 enforcement"参考架构大致是这样：数据消费方的 Agent 带着跨空间身份与 OBO 委托链，向数据方连接器发起请求；连接器先做接入核验，再用编译自用途合约的 ODRL 策略做权限/禁止/义务判定；放行的计算在 TEE 内进行、数据可用不可见；结果出域时受粘性策略/信息流控制约束；全过程上链存证。

用一张清单把每一环要做的事和它对应的"用途合约条款"对上，方便直接拿去评估自家方案：

环节	工程手段	对应用途合约条款	强制在哪一侧
谁能进	跨空间身份互认 + 接入核验	参与方资质、准入范围	空间服务平台
替谁用	OBO / RFC 8693 跨组织委托链	授权主体、代理边界	IdP + 连接器
能否访问 / 取多少	连接器 Usage Control（ODRL 权限/禁止/义务）	用途受限、次数限制、字段范围	数据方连接器
过程可用不可见	TEE / 机密计算 + 远程证明	禁止查看原始数据、计算范围	数据方域内 TEE
结果出域后受控	粘性策略 / 确定性信息流控制	禁止二次传输、使用后删除	随数据/结果流动
全程留痕	区块链存证与溯源	履约证据、利益分配	空间 + 各方

这张表最该盯住的是"强制在哪一侧"这一列——加粗的三行，是真正决定"敢不敢用"的地方，也恰恰是最容易被"签了合同就算数"糊弄过去的地方。一个务实的自查问题是：把每一条用途合约条款拿出来，问一句"如果 Agent 就是要违反它，是什么在物理上阻止它？" 如果答案是"审计能查出来"，那只是可举证；只有答案是"连接器/TEE/信息流控制在执行时就拒绝了它"，才叫可强制。

七、ICE 观察

技术视角："执行下沉"从单组织扩展到跨组织

这三篇其实是同一个判断在三个尺度上的展开：库内 enforcement 是"把策略下沉进数据库引擎"（单库），MCP 三道关是"把策略下沉到 Agent 直连的入口"（单组织），而域内 enforcement 是"把策略下沉进数据提供方的连接器与 TEE"（跨组织）。尺度在变，内核不变：把强制点放到消费方及其 Agent 绕不过去的那一层，并让'定义'（用途合约/策略）与'执行'（连接器/TEE/信息流控制）分离。 对架构师最实际的判断标准是：拿到任何一套可信数据空间方案，逐条问用途合约的每个条款"在运行时由什么强制、Agent 能不能绕过"。停在"链上存了合同"的方案，本质上还没有执行层。

落地视角：别停在"合同文本"，也别一步到位上最重的方案

给正在建或接入可信数据空间的团队两条务实建议。其一，用途合约必须走到"可执行"这一步，但要清醒承认现实 gap——IDS 21 类策略主流连接器只实现了 8-9 类，EDC 只给框架不给全部逻辑。所以选型时别看 PPT 上列了多少策略类型，要看你真正需要的那几条（尤其"用途受限""禁止二次传输""使用后删除"）到底有没有可用的强制实现。其二，按数据敏感度分层上手段：一般数据，连接器 Usage Control + 存证就够；核心敏感数据，才上 TEE；涉及"结果不能外流"的，再上粘性策略/信息流控制。一上来就要求"全都 TEE + IFC",大概率把项目拖死在成本和性能上。记住系列第一篇那个数字——48% 的生产 Agent 还在无监控裸奔，对多数团队，先把连接器闸口和存证打上，就已经甩开大部分人了。

本土视角：政策窗口、国产底座与"可重放审计"的机会

放到国内，这是一个罕见地"政策、技术、市场"三股力量对齐的窗口：政策上有行动计划的 100 个空间目标和创新试点，技术上有"区块链 + 隐私计算"的明确底座定调，市场上有强监管行业"敢用 AI 却不敢交数据"的真实痛点。对国产厂商，机会点很具体：连接器（把 ODRL/用途受限等策略类做出成熟的国产强制实现，补上那 8-9 类之外的缺口）、国产 TEE / 机密计算（让"可用不可见"跑在信创栈上）、数字身份（跨空间身份互认与 OBO 委托链的国产 STS）。而把这三篇串起来看，还浮现出一个更完整的产品主线——用途合约（定义）→ 跨组织 OBO 身份链（谁在用、替谁用）→ 连接器/TEE 域内 enforcement（能用到什么程度、可用不可见）→ 确定性可重放审计（事后能不能精确复现每一次访问）。 最后这个"可重放审计"尤其值得国产团队重点投入：它不只是留痕上链，而是能把某一次 Agent 访问的语义、策略版本、数据快照绑定起来、点对点重放——这既是强监管的刚需，也是可信数据空间从"可举证"迈向"可自证清白"的关键一跳。

结论

把这篇收束成几句话：

1. 可信数据空间是"执行下沉"的跨组织版。 数据要素×给动机，可信数据空间给"敢用"的机制，而 Agent 把它从合规话术逼成了工程题。
2. 用途合约必须从"合同文本"走到"可执行策略"。 ODRL 的权限/禁止/义务、IDS 的用途受限策略是路径；但要认清"21 类只落地 8-9 类"的现实 gap，别停在"链上存了份合同"。
3. 连接器是域内 enforcement 的守门人。 数据不出域、策略在数据方域里执行，这是数据主权的技术实现。
4. Agent 逼出了输出侧管控这个新难点。 域内 enforcement 要分层：连接器管入口、TEE 管过程、信息流控制/粘性策略管出口、区块链管留痕。
5. 判断一套方案是否可信，就问每条用途条款"Agent 要违反它，什么在物理上拦住它"。 答"审计能查"只是可举证，答"执行时就拒绝"才是可强制。

最后留个问题给正在推数据要素、建可信数据空间的你：当数据消费方派来的是一个 Agent 而不是人时，你那份"用途合约"里的每一条，是真的有一段代码在数据出域的闸口上强制执行，还是只是一份签了字、存了证、却拦不住任何实际动作的电子合同？ 这个问题的答案，决定了你的可信数据空间是"真可信"，还是"名义可信"。

---

参考资料

1. 国家数据局.《可信数据空间发展行动计划（2024—2028 年）》（国数资源〔2024〕119 号）. 2024-11-21. https://www.nda.gov.cn/sjj/xxgk/gknr/ghjh/1125/20241125103832267789867_pc.html
2. 全国数据标准化技术委员会.《可信数据空间 技术架构》技术文件发布通知（服务平台 + 接入连接器；身份/目录/数字合约/使用控制）. 2025-04-30. https://www.nda.gov.cn/sjj/ywpd/szkjyjcss/0430/20250430181352183912672_pc.html
3. 国家发展和改革委员会.《数字身份驱动可信数据空间发展》（数字身份为"通关密钥"；区块链 + 隐私计算底座；1+5+N+1 架构）. 2025-10-09. https://www.ndrc.gov.cn/wsdwhfz/202510/t20251009_1400856.html
4. International Data Spaces Association. Data Space Connector Report（连接器双职责：互操作 API + 可信策略执行；数据主权与 usage control）. 2025-10. https://internationaldataspaces.org/idsa-data-space-connector-report/
5. Eclipse Foundation. Eclipse Dataspace Protocol（DCAT 目录 + ODRL 策略 + 合约协商 + 数据传输；DSP 2025-1）. https://projects.eclipse.org/proposals/eclipse-dataspace-protocol
6. IDSA / Dataspace Connector. Usage Control（IDS Contract = 元数据 + Usage Control Policy；ODRL 权限/禁止/义务；21 类策略，含"用途受限使用"，连接器实现 8-9 类）. https://international-data-spaces-association.github.io/DataspaceConnector/Documentation/v5/UsageControl
7. A Survey of Dataspace Connector Implementations（连接器架构、数据模型与使用控制语言对比）. arXiv:2309.11282. https://arxiv.org/html/2309.11282v2
8. Anjuna Security. Overwatch: A Confidential-Computing-Protected Control Plane for Autonomous AI（TEE 内运行、远程证明、上下文感知策略治理 Agent 行为）. 2026-06-22. https://www.prnewswire.com/news-releases/anjuna-security-launches-industrys-first-trusted-control-plane-built-upon-confidential-computing-to-secure-the-age-of-autonomous-ai-302805725.html
9. Styx: Collaborative and Private Data Processing With TEE-Enforced Sticky Policy（TEE 强制的粘性策略，输入/输出双侧生命周期保护）. arXiv:2604.04082. https://arxiv.org/pdf/2604.04082
10. GAAP: An AI Agent Execution Environment to Safeguard User Data（确定性信息流控制，不信任 Agent/提示词，保证数据披露合规）. arXiv:2604.19657. https://arxiv.org/abs/2604.19657