这篇论文研究的是数据空间（dataspace）与 LLM 智能体交汇处的一个治理盲区。作者指出，数据空间连接器（connector）的决策点只决定「是否允许一次传输发生」，而不管被传输的值里到底装了什么。对基于合同的传统应用来说这尚可接受，但对会自行组合工具调用、并派生（spawn）子智能体的 LLM 智能体而言就不够了。现有文献分成两拨：一拨研究「让智能体自动生成治理工件」并评估其输出质量；另一拨是治理文献，研究决策与授权机制。但「谁有权把一个治理工件授权为可用」这个问题恰好落在这两拨之间，两边都没有认领。作者提出，已发布的策略就是数据空间决策点实际执行的东西，因此「发布」本身就是一个治理事件；那么当一个智能体既是策略的约束对象（subject）、又是策略的作者（author）时，它实际上在书写约束自己的规范——作者把这一现象命名为「作者性风险」（authorship hazard），并给出唯一原则：智能体永远是治理平面的主体，而绝不是治理平面的作者。为此，智能体通往「发布」的授权通道在构造上被彻底关闭；它剩下的影响通道——起草供人类审批的文本——则被当作一个执行（enforcement）问题来处理，而不是当作创作自由。实验部分使用一份冻结的智能体草稿语料：如果允许未经批准的发布，会逆转 80 条授权决策，且其中大多数草稿只改动某个字段的敏感度分类、完全不改策略正文；一个只读「策略 diff」的分类器必然、无一例外地漏掉这类草稿（因为 diff 里根本没有策略文本变化）。作者主张把「分类」本身也视为一种作者性行为，这样全部此类草稿都会被路由到人工审查；为此所需的「由注册表持有分类」的机制在文中被设计和建模，但尚未在原型中实现。在执行边界上，作者给出两组对照数据：当受保护字段仅靠提示词声明的职责来保护时，105/105 的情况下受保护字段会到达模型；而把 ODRL duty 编译成调用时（invocation-time）的工具调用约束后，该数字降到 0/105。不过当敏感值并不局限于某个具名（named）字段时，编译出的条件仍在 7/7 的情况下把值暴露出来。最后作者指出，集中式审批池（centrally provisioned approval pool）无法扩展到触发该问题的那种参与者规模，暗示必须走分布式、注册表驱动的分类与授权路径。