“但是数据保护呢？”——把 Agentic Work 看作 Information Flow 问题

只要话题一涉及 AI，迟早总会有人说：

“但是数据保护呢？”

这个质疑并没有错。任何把 AI 系统或 Coding Agent 与企业信息、个人数据或安全敏感系统连接起来的人，都应该非常认真地思考其中究竟会处理哪些信息。但仅仅说出这句话，还不能算作风险分析。

AI
↓
“数据保护！”

从技术角度看，它提供的信息量大致相当于：

Internet
↓
“Security！”

两者都指出了真实存在的问题领域，但都还没有回答任何一个具体问题。

只有当我们开始观察真实的 Information Flow 时，讨论才真正变得有意义：

信息
↓
来源
↓
授权
↓
Agent / Tool
↓
Context
↓
处理
↓
Output / Artefact / Memory

哪些信息流向哪里？为什么那里需要这些信息？谁有权看到？哪些系统会处理它？它跨越了哪一条 Trust Boundary？由此还会产生哪些新的 Artefact？如果这些信息出现在本不应该出现的位置，会发生什么？

正是在这里，讨论的性质发生了变化。Agentic Work 不只是数据保护问题，它还是 Information Flow 与 Trust Boundary 问题。 数据保护是其中非常重要的一维，但并不是唯一的一维。

这与本系列上一篇文章直接相连。上一篇讨论了“Architecture as Constraint”：架构限制 Agent 从结构上究竟允许产生哪些方案。信息保护进一步扩展了这一思想。架构回答“什么可以和什么连接”，信息保护则补充回答“谁可以看到什么”“什么可以流向哪里”“又可以由此产生什么”。

因此，架构限制的是结构上的解空间，而 Trust Boundary 限制的是被允许的 Context 与 Action Space。

敏感领域，并不自动等于敏感的开发 Context

我在技术负责人岗位上工作了大约 15 年，其中相当长一段时间都在医疗和 Public Sector 等领域。两个领域都存在必须受到高度保护的信息，这一点几乎没有争议。尽管如此，这些年来我自己从未需要使用真正的高敏感生产数据进行开发。

这明确只是我的个人经验，并不是对所有软件开发组织方式的普遍判断。确实存在一些系统、公司和岗位，开发人员会接触接近生产甚至真实生产的数据。但对我而言，这段经历仍然说明了一个很重要的问题：

一个系统中存在高度敏感的数据，并不自动意味着这些数据就是日常开发或 Agent Context 的一部分。

在很多 AI 讨论里，这个区别很容易被忽略。一个医疗系统会处理健康数据，但这并不意味着开发人员或 Coding Agent 必须看到真实的健康数据。开发环境和生产环境可以彼此隔离；开发流程可以使用合成测试数据、匿名化数据、假名化数据，或者专门构建的测试数据集。访问权限也可以这样设计：开发人员能够理解和修改系统的大部分功能，却从未真正看到生产数据本身。

德国数据保护会议在针对 AI 系统开发的指导中同样建议，首先检查相关目的是否可以通过合成数据或匿名化数据来实现。这里必须区分假名化数据与匿名数据：只要借助额外信息仍然可以重新关联到具体个人，假名化数据原则上仍属于个人数据；真正匿名化的信息则不再适用 GDPR。[DSK – AI 系统中的技术与组织措施]

因此，技术问题不应该是“整个系统是否包含敏感数据”，而应该是：

在这些数据中，这个具体的开发流程或 Agent 实际上需要哪些？

这听起来只是一个小小的视角变化，但实际上它改变了整个问题。我们不再抽象地讨论“这是一个敏感领域”，而是在讨论一条具体的数据流。

数据保护只是信息保护的一维

在技术讨论中，数据保护 这个词本身也经常被用得比实际需要更宽泛。

GDPR 保护的是个人数据，也就是与一个已经识别或可识别的自然人有关的信息。除了姓名、电子邮件地址这类显而易见的信息之外，根据具体 Context，也可能包括标识符、Online Identifier、客户编号、日志或 IP 地址。[GDPR，第 4 条 – EUR-Lex]

对于某些信息还存在更严格的要求。GDPR 第 9 条列举了包括健康数据、遗传数据、特定生物识别数据、政治观点、宗教或哲学信仰、工会成员身份，以及与性生活或性取向有关的信息。[GDPR，第 9 条 – EUR-Lex]

但同时，也有大量信息完全不涉及个人数据，却依然可能需要高度保护：Source Code、架构、尚未发布的产品、算法、研究成果、内部战略、合同、定价或专有流程。其中一部分在满足特定条件时，甚至可能依法构成商业秘密。德国《商业秘密保护法》关注的条件包括：该信息并非普遍已知或轻易可得、具有经济价值，并受到适当的保密措施保护。这并不意味着所有未公开的 Source Code 都自动属于商业秘密，但它非常清楚地说明：没有任何人员关联的信息，也可能因为经济价值而需要独立的保护。[§ 2 GeschGehG]

还有一类信息，其核心问题既不是数据保护，也不是经典意义上的商业秘密保护：API Key、Token、Private Key、Cloud 配置、内部网络结构、Security Architecture、漏洞信息以及其他 Credentials。对于这些信息来说，仅仅问“里面是否有个人数据”显然是不够的。

数据保护只是信息保护的一维。

这一点对于 Agentic Work 尤其重要，因为 Coding Agent 经常处理的数据在隐私法上完全不起眼，却可能对企业具有极高价值。Agent 即使看不到任何一个客户姓名，也完全可能接触到一家企业最核心的知识产权。

用两条轴，而不是一个标签

因此，在技术讨论里我会使用一个简单的模型。它并不是 GDPR 的官方分类，也不是法律分类体系，而是一种 Engineering 抽象，用来避免把两个不同的问题混在一起。

第一条轴大致描述个人数据属性以及由此带来的特殊法律保护：

无个人数据
↓
个人数据
↓
特殊类别的个人数据

第二条轴则关注信息泄露可能造成的损害：

公开
↓
内部
↓
机密
↓
业务关键
↓
威胁企业生存 / 危及个人

这两条轴并不必然相关。一封业务邮件地址可能属于个人数据，同时保护等级却相对较低；一个尚未发布的算法完全可以不包含任何个人数据，却在经济上极其关键。当然，一条信息也可能同时在两条轴上都处于很高位置。

用两个故意选择的极端例子，这种差异会更明显。

一边，我们可以想象一名受到政治迫害的人在庇护程序中的相关信息。仅仅是政治观点本身，就已经属于 GDPR 第 9 条所规定的特殊类别个人数据。根据案件内容，还可能包含其他高度敏感的信息。在这种情况下，未经授权的披露并不只是抽象的 Compliance 问题，而可能对真实的人造成现实后果。

另一边，一家公司正在开发一种新的技术方法。没有客户数据，没有姓名，没有电子邮件地址，没有用户标识符，完全没有个人数据。但这个方法可能是多年研究的结果，也可能是公司未来最重要的竞争优势。一旦泄露，经济后果可能是灾难性的。

没有个人数据，并不自动意味着不敏感。

因此，对于技术风险分析来说，单一的 个人数据：是 / 否 标签是不够的。我们还必须问：如果这条信息跨越了错误的 Trust Boundary，会发生什么？正是在这里，数据保护进入了更大的 Information Flow 问题。

数据流比 Marketing Label 更重要

这个区分也有助于理解一些在 AI 产品语境里很容易让人安心的说法。其中一个典型说法是：

我们的数据不会用于训练。

这可能是产品非常重要的一项属性，但它只回答了一个问题。它并不自动意味着没有处理、没有传输、没有存储、没有日志、没有 Retention、没有其他服务提供商、没有 Support Access，也不意味着不会在某个特定区域之外处理。

GDPR 对 处理 的定义要宽得多，其中包括收集、记录、存储、读取、查询、使用、传输、提供、组合以及删除个人数据。训练因此只是更大技术流程中的一种可能处理步骤或处理目的。[GDPR，第 4 条 – EUR-Lex]

德国数据保护会议同样会区分例如“把输入输出用于训练”和“保存输入历史记录”这两个问题。一个系统可以禁止训练，同时仍然保存数据。[DSK – 人工智能与数据保护]

所以：

No training is not the same as no processing.

这并不意味着商业 AI 服务或外部运行的 AI 系统就自动存在问题。它只意味着 No Training 并不能完整描述数据流。合同安排、AVV 或 DPA、Retention、Region、Subprocessor、技术配置以及真实的 Information Flow 必须一起考虑。

反过来的逻辑同样不成立。即便某项个人数据处理在数据保护法上是允许的，也不能自动推出“这些信息就可以放进 Prompt”。保密协议可能禁止进一步披露，内部 Security Policy 可能设置额外边界，信息可能属于商业秘密，也可能受到合同或监管规则限制。某个用户也许被授权在内部系统里读取某条信息，但这并不等于他同时被授权把它传给外部服务。甚至可能完全没有个人数据，但由于 IP 保护要求，这种传输仍然完全不可接受。

一项在数据保护法上允许的处理，并不自动意味着它在组织或安全层面也允许。

我是软件架构师，不是律师。一项具体的数据处理是否被允许，取决于真实的处理 Context，必要时需要数据保护或法律方面的专业评估。但架构工作要更早开始：在任何人判断某条数据流是否合法之前，技术上至少应该先明确，究竟存在什么数据流。

Agent 扩大了信息暴露面

在经典 Chat 场景里，可见的交互一开始相对有限：我写一个 Prompt，系统处理它，我得到一个回答。Coding Agent 的活动半径可能完全不同。

根据系统、配置和任务，它可能访问如下环境的一部分：

Repository
Documentation
Tickets
Shell
File System
Environment Variables
Database
Logs
CI/CD
Cloud APIs
Secrets
Browser
External Search

并不是每个 Agent 都拥有这些能力。恰恰因为如此，“Coding Agent 安全吗？”这种笼统问题太不精确。一个只能 Read-only 访问单个 Repository 的 Agent，与一个可以执行 Shell 命令、修改文件、调用外部服务、读取 Secrets 并触发 Deployment 的 Agent，在安全层面是完全不同的情况。

每增加一个 Tool，不只是 Agent 的 Action Space 在扩大，它的 Information Space 也在扩大。德国联邦信息安全局在讨论嵌入应用的语言模型时也指出，额外集成可以打开对文档、网站、编程环境或其他系统的访问，从而产生 Indirect Prompt Injection 等新的攻击路径。[BSI – Indirect Prompt Injections]

Agency 越强，信息面与攻击面也越大。

这使一个非常古老的安全原则重新成为 Agentic Work 的核心原则：Least Privilege。

问题不应该是“这个 Agent 将来可能会用到什么”，而应该是“它为了当前这个具体任务究竟需要什么”：

Task
↓
所需能力
↓
所需信息
↓
最小权限

一个只是在 Frontend 应用中修改文本的 Agent，通常不需要访问生产数据库，不需要 Cloud Admin 权限，不需要 Secrets，也不需要企业所有 Repository 的访问权。对复杂迁移进行分析时，可能确实需要更大的 Context。这并不矛盾。Least Privilege 并不是“权限越少越好”，而是需要多少就给多少，同时尽可能少给。

由此可以得到这个主题里对我而言最重要的原则之一：

Relevant 并不自动等于 permitted。

某条信息从技术上看可能对 Agent 有帮助，但这本身还不足以成为把它开放给 Agent 的理由。

Authorization 必须发生在 Retrieval 之前

在 RAG 系统中，这个区别尤其明显。一个非常简单的 RAG 心智模型可能是：

企业知识
↓
Retrieval
↓
LLM

由于知识不是直接训练进模型本身，这种方式一开始看起来更容易控制。它确实可以更容易控制，但权限问题并不会因此消失。

德国数据保护会议在 RAG 指导中明确指出，Reference Document 和 Vector Database 仍然需要 Rights & Roles Concept。它也指出，访问控制不能简单交给语言模型，而应该在真正执行查询之前就把相应角色纳入考虑。[DSK – 使用 RAG 的生成式 AI 系统的数据保护特殊问题]

从 Engineering 角度看，顺序应该非常清楚：

Identity
↓
Authorization
↓
Retrieval
↓
Context
↓
LLM

而不是先把所有东西都找出来、生成 Context，然后才去检查用户究竟有没有权看到这些信息。

RAG 不是 Privacy Shield。

Retrieval 改变的是信息进入 Context 的技术路径，但它不会取消原有的权限边界。一条信息不能仅仅因为技术上能被搜索到，就自动进入 Agent Context。

“Agent 本来不应该进入那里”

我在使用 Coding Agent 时最有意思的一次经历，正好与这种假设有关。

在一次针对一个多年演化而来的大型系统的早期 Audit 中，Source Code 中某些特别受保护的区域被明确排除在 Coding Agent 可访问范围之外。Agent 不应该直接分析这些区域。但后来，在 Agent 生成的 Audit 文档里，仍然出现了关于这些区域的信息。

这些信息究竟是通过间接 Dependency、Type、Alias、其他模块中的引用、之前生成的文档、Search，还是完全不同的分析路径暴露出来的，我事后已经无法确认。也正因为如此，我不想在后来人为构造一个看似确定的原因。

真正有意思的是另一点：

一个在技术上被排除的区域，显然仍然没有对 Agent 完全不可见。

这件事非常直观地提醒了我：“Agent 本来不应该进入那里”并不是一个可靠的安全描述。本来不应该 描述的是期望行为；Trust Boundary 描述的是技术上真正被强制执行的边界。

“Agent 本来不应该进入那里”并不是可靠的 Trust Boundary。

对于保护需求较低的信息，软限制可能完全足够。但保护需求越高，我越不愿意依赖这种限制。

File Boundary 不自动等于 Information Boundary

假设一个 Agent 无法读取某个文件：

protected-module.ts
✕ direct access

此时我们只能确认一件事：Agent 不能直接读取这个文件。我们还不能确认它无法通过其他方式获得任何关于受保护区域的信息。

软件系统中的信息很少会整齐地封闭在单个文件内。它会通过 Contract、Type、Dependency、Stacktrace、Log、Test Report、Coverage、Static Analysis Finding、Architecture Documentation、Ticket、PR Description、Agent Summary 以及其他生成的 Artefact 向外扩散。Interface 可以在完全不包含实现的情况下透露受保护区域的一部分信息；Stacktrace 可以暴露组件之间的关系；Test Report 描述行为；架构图记录 Dependency；Ticket 可能解释某个内部机制为什么存在；早期生成的 Summary 甚至可能继续携带来自后来已经不可访问的 Context 中的信息。

这明确不意味着 Agent 可以自动从这些信息中重建原始 Source Code。那将是另一种、更强得多的主张。真正相关的机制要简单得多：

受保护的信息可以跨越 Trust Boundary，而原始文件本身从未跨越这条边界。

因此，对 Source File 做 Access Control 还不等于完整的 Information-Flow-Control。这不是 GDPR 的特殊规则，而是一种 Engineering 推论。对 Agent 而言，这个推论尤其重要，因为它们可以组合来自很多来源的信息，并进一步生成新的 Artefact。

因此，我们不应该只问 Agent 可以读取哪些文件，还应该问：允许访问的来源本身可能暴露哪些信息？这些信息又会产生哪些新的 Artefact？Information Flow 并不会在 Input 结束。

这里甚至还会与我反复谈到的另一个架构主题产生联系。Big Ball of Mud 并不会自动造成数据保护违规，但高耦合会让清晰可理解的边界更难维持：

清晰的 Boundary
↓
更容易理解的信息路径

对比：

Big Ball of Mud
↓
隐式关系
↓
更难预测的信息路径

因此，Clean Architecture 本身还不能算作数据保护措施，但它会让 Ownership、Isolation、Dependency Control，以及由此产生的信息边界技术执行变得更容易。

高耦合会让 Trust Boundary 更难被技术执行和验证。

当保护需求很高时，“更少”往往更强

面对特别敏感的信息，一个自然的答案是把模型放到本地运行。这完全可能是一个合理的技术组件。如果某些信息不应该离开定义好的 Trust Boundary，那么 Local 或 On-Premise 模型确实可以产生很大差异。

但真正相关的架构并不只是 LLM local，而是整条链路：

LLM local
+
Retrieval local
+
Logs local
+
Tools local
+
Memory local
+
no cloud fallbacks
+
no unwanted telemetry

一个本地模型如果使用外部 Retrieval，就没有形成完全本地的 Trust Boundary。一个本地 Agent 如果通过 Tooling 又把信息发送到外部 API，同样如此。一个 On-Premise 模型如果存在未知的外部 Telemetry 路径，也不会因为 Inference 在本地执行就自动解决问题。

德国数据保护会议在 RAG 指导中也指出，On-Premise 架构可以避免把个人数据传给外部模型提供商，但仍然必须观察整体架构。[DSK – RAG 指导]

真正关键的仍然是完整的 Data-Flow Model。

当保护需求真的很高时，这个问题会更有意思。此时我们首先应该问的并不是“怎样把这条信息更安全地传给 LLM”，而是：

为什么这条信息一定要跨越这条 Trust Boundary？

Security Engineering 并不只意味着把风险数据流保护得越来越复杂。有些风险更优雅的解决方式，是让这条数据流根本不存在。也许合成数据已经足够，也许匿名化或缩减后的片段就能解决问题，也许一个 Contract 就足够。也许可以由一个本地 Service 封装敏感操作，只把敏感度更低的结果暴露给 Agent。也许人工边界更合适。甚至对于某个 Use Case，Agent 根本就不是正确的工具。

在极高保护需求下，正确的架构可能就是让某条数据流根本不要出现。

这与一个远早于 LLM 的基本思想完全一致：数据最小化和 Privacy by Design 并不要求先尽可能多地收集个人数据，然后再用尽可能复杂的方法去保护，而是在系统设计阶段就限制到实现目的真正需要的数据。[GDPR，第 5 条与第 25 条 – EUR-Lex]

对于 Agentic Work，这是一种很有价值的思考方式。核心问题不应该是“我们怎样才能把这些信息也给 Agent”，而应该是“为了这个任务，我们有哪些信息可以根本不让 Agent 看到”。

数据保护并不是因为 AI 才突然变得具体

这可能是当前 AI 讨论中最让我困惑的一部分。

企业和组织几十年来一直通过外部系统处理信息：Cloud、SaaS、API、Communication Platform、Support System、Analytics 以及外部服务提供商。这些系统从来都不是天然无风险的。对它们来说，Purpose、Permission、Recipient、Storage Location、Retention、Contract、Technical Measure 与 Protection Requirement 本来就需要被考虑，今天仍然如此。

AI 确实显著改变了一部分风险画像。生成式模型会以新的方式组合信息；RAG 让大型知识库变得可进行语义检索；Agent 获得 Tool，并可以自己执行 Action；Prompt Injection 带来新的攻击路径；Memory 和生成的 Artefact 可以把信息带出单次交互。

这些差异都是真实的。但最基础的问题——哪些信息流向哪里——并不是新的。GDPR 本身是技术中立的，它的原则并不取决于个人数据是由经典 SaaS、API 还是语言模型来处理。[GDPR – EUR-Lex]

因此，我认为两个极端都没有帮助。并不是只要出现 AI 就突然什么都不能做，也不是只要使用 Enterprise 产品就自动万事大吉。

数据保护不应该因为出现了 AI 这个词就突然绝对化。它应该在真实的数据流和真实的风险出现时变得具体。

这并不是主张减少数据保护。恰恰相反，它让讨论更精确。与其简单从 AI → 数据保护问题 得出结论，不如问一些真正能够被回答的问题：

Agent 需要这条信息吗？
↓
用户有权访问吗？
↓
Agent 可以为了这个任务处理它吗？
↓
它可以跨越这条 Trust Boundary 吗？
↓
访问是否被技术限制？
↓
它会产生哪些 Artefact？
↓
这些 Artefact 会不会继续携带信息？
↓
如何验证？

这些问题并不都只属于数据保护。有些属于 Security，有些属于架构、Governance、合同法或 Compliance。也正因为如此，“但是数据保护呢？”这种反射式反应帮助不大：它把太多不同的问题混在了同一个标签下面。

把数据保护看作 Constraint

至此，我们又回到了上一篇文章。

上一篇讨论的是如何缩小 Agent 的结构化解空间。并不是所有技术上可行的架构都应该被接受。即便 Agent 技术上可以让 Presentation Layer 直接访问数据库，也不意味着我们必须接受这种方案。

Architecture 会设置 Constraint。

Information Protection 也可以用类似方式理解。仅仅因为 Agent 技术上可以访问一条信息，并不意味着这条信息就应该成为它的 Context。

Architecture Constraints
↓
哪些结构化方案允许存在？

还需要补充：

Information Constraints
↓
哪些信息与能力允许存在？

对我来说，这是一种更有生产力的方式来理解 Agentic Work 中的数据保护。Agent 的确会产生真实的数据保护风险、真实的保密风险和真实的 Security 风险。Agency 越大，因为可访问的信息和可执行的 Action 越多，这些风险也可能越大。

但这些风险并不神秘。它们可以被分析、建模，并通过架构去影响；可以通过权限去限制、监控和验证；有些甚至可以通过直接禁止某条 Information Flow 而被完全避免。

数据保护不是 Agentic Work 的 KO 条件，而是系统的一项 Constraint。

这并不意味着数据保护已经被解决，而是意味着我们可以把它具体化。

其中仍然有一条规则尤其重要：

Relevant 并不自动等于 permitted。

真正关键的问题不是 Agent 理论上能不能处理某条信息，而是我们为了这个具体任务，到底愿意让它看到哪些信息。

如果我们能够清楚回答这个问题，那么“AI？但是数据保护呢？”就已经变成了一场更有意义的讨论：

究竟要处理哪些信息，谁有权看到，Agent 为什么需要它，它跨越哪一条 Trust Boundary，泄露会造成什么后果，以及我们怎样在技术上真正执行这条边界？

这并不是淡化问题，而是把问题具体化。Demystification 正发生在这里。

Requirements、架构与 Information Boundary 已经把允许的解空间显著缩小，但它依然不是 Deterministic 的。即便所有 Constraint 都定义得很好，Agent 仍然可以产生多个在业务和技术上都有效的方案。

所以下一篇文章会讨论另一个问题：我们怎样不只是忍受这种 Varianz，而是有意识地利用它？

Diverge · Decide · Converge.

来源与说明

GDPR – Regulation (EU) 2016/679，EUR-Lex
关于个人数据、特殊类别个人数据、数据处理、数据最小化、Privacy by Design、处理安全以及其他数据保护原则的主要法律来源。它既没有定义本文的两轴模型，也没有定义 Coding Agent 的特定 Trust Boundary 模型。
https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679

德国数据保护会议 – 人工智能与数据保护，2024
关于 AI 使用以及不同处理步骤区分的监管指导，其中包括训练和输入存储。它不是对特定 AI 产品的一般性批准或禁止。
https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf

德国数据保护会议 – AI 系统中的技术与组织措施，2025
关于 Data Protection by Design、数据最小化、风险分析，以及 AI 系统整个生命周期中可采取的技术和组织措施的监管指导。
https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf

德国数据保护会议 – 使用 RAG 的生成式 AI 系统的数据保护特殊问题，2025
与权限与角色模型、Retrieval、Reference Document、Vector Database 以及 On-Premise 场景相关。“RAG 不是 Privacy Shield”是本文的技术性概括，并不是 DSK 的逐字表述。
https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf

BfDI – 公共机构中的 AI：从一开始就考虑数据保护，2025
面向德国联邦行政机构、关于 LLM 使用与数据保护问题的指导。其目标群体是联邦行政机构，并不是适用于所有企业的一般法律规范。
https://www.bfdi.bund.de/SharedDocs/Downloads/DE/DokumenteBfDI/Dokumente-allg/2025/Handreichung-KI.pdf

德国《商业秘密保护法》– § 2 GeschGehG
定义商业秘密及其构成条件。个人数据与商业秘密是两种不同的保护类别，二者可能重叠。并不是所有未公开 Source Code 都自动满足商业秘密的法律条件。
https://www.gesetze-im-internet.de/geschgehg/__2.html

BSI – Indirect Prompt Injections
关于嵌入应用的语言模型，以及外部内容与 Tool Integration 可能带来的额外攻击路径的技术 Security Guidance。它不是关于数据处理合法性的法律判断。
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2023/2023-249034-1032.html

本文中的 Engineering 推论
把个人数据属性与潜在泄露损害结合起来的两轴模型并不是 GDPR 官方分类。同样，Identity → Authorization → Retrieval → Context → LLM、把 Least Privilege 应用于面向具体 Task 的 Agent 权限，以及 “File Boundary 不自动等于 Information Boundary” 这类表述也都是本文的 Engineering 模型。它们用于把抽象的保护要求转换为可以被技术讨论和验证的边界。