S58：Artifact Provenance 与 Egress / Purpose Policy
Provenance 解释 artifact 从哪里来、怎样构建和由谁批准，egress/purpose policy 则约束运行时哪些数据为了什么原因可以流向哪个外部目的地。
内容类型：预习教材（不代表已完成）
日期：2027-01-19
阶段：P2 · AI Systems Engineering 90
总路线：Day 148 / 360
周次：W9 · Security、Privacy、AI Supply Chain
节奏：周二最小实现
状态：教材已备；学习未完成
标签：provenance、hash、egress-policy、purpose-policy、supply-chain
一句话定义
Provenance 解释 artifact 从哪里来、怎样构建和由谁批准，egress/purpose policy 则约束运行时哪些数据为了什么原因可以流向哪个外部目的地。
学习目标
- 能区分 hash 完整性、签名身份、provenance 过程证据和“内容安全”。
- 为一个小 artifact 设计来源、依赖、构建和审批记录。
- 写一个最小 egress/purpose policy，并解释默认拒绝与升级路径。
- 理解供应链控制与运行时数据流控制互补而不能互相替代。
核心知识
- Hash 证明字节在比较时是否一致，不证明来源可信、内容无漏洞或训练数据合规。
- Signature 将摘要绑定到某身份/密钥，但还需验证密钥信任、时间、撤销和签名对象。
- Provenance 可记录 source URI/revision、builder identity、build recipe、dependencies、timestamp、artifact digest 与 approval evidence。AI bundle 还可关联 model、prompt、index、tool 与 policy 版本。
- AI BOM 是组件清单与依赖关系，不自动保证组件安全；它帮助发现影响范围、许可证和版本风险。
- Egress policy 控制目的地、数据类别、字段、操作、主体和时间；purpose policy 控制使用目的。仅有域名 allowlist 仍可能向允许域发送不该发送的数据。
- Policy decision 应输出 allow/deny/escalate、reason code 和匹配规则版本。高风险需求可进入人工路径，不能由模型改写目的绕过。
机制与推导
最小 provenance record：
artifactRef, digest, sourceRevision, builder,
recipeVersion, dependencyDigests[], builtAt,
reviewer/approvalRef, intendedUse
验证链是 resolve expected digest→recompute/download digest→verify signature/provenance→check policy→admit。Digest mismatch 只说明字节不同；即使 match，也仍需漏洞、许可证与用途判断。
最小 egress 决策：
[ allow = destinationAllowed \land dataClassAllowed \land fieldsMinimized \land purposeAllowed \land actorDelegated ]
例如 restricted 案件数据发往外部模型默认 deny；脱敏摘要用于 case-summary 且供应商合同/区域符合时可能 allow；未知目的返回 escalate。决策必须发生在真正出站边界，而不只在 UI。
最小练习或观察步骤
- 创建一个合成 prompt/tool manifest 的文本示例，手工或用已有工具计算其 hash；未实际计算则写预期步骤。
- 写 provenance record，明确 hash 能证明和不能证明什么。
- 定义三类数据
public/internal/restricted、两个目的地和两个 purpose。 - 写四条 egress/purpose 规则，并为 allow、deny、escalate 各做一个合成请求。
- 记录 policy version、reason 和最小化后的字段，不保存真实敏感正文。
- 不要求建立签名基础设施或供应链 gate；重点是证据语义。
常见误区与边界
- hash 一致就宣称 artifact 安全可信。
- provenance 只记录最后上传者，不记录 source、builder 与 recipe。
- AI BOM 生成后从不随 bundle 更新。
- allowlist 域名可以接收任何字段和任何目的。
- 客户端先脱敏再完全信任，出站 gateway 不复核策略。
- 本地示例不代表实现企业密钥管理、签名验证或数据防泄漏系统。
系统 / 金融 / Web3 场景连接
金融 Agent 的模型与 prompt bundle 应能追到审批版本；restricted 字段不能因模型调用方便就发送到任意 provider。Web3 工具包也需记录来源 commit、构建 digest 与依赖，防止被篡改的交易编码器改变目标地址；但 hash 无法证明合约本身安全。
自检问题
- hash、signature、provenance 与 BOM 各提供什么证据？
- 为什么目的地 allowlist 仍不足以控制数据外流？
- Policy 应在哪个边界执行并记录什么？
- Artifact digest 匹配后仍有哪些风险？
专业课程对齐
- 阅读 Kubernetes 官方文档 中 image、Secrets、admission control 与 security 相关导航，观察 artifact identity、运行准入和运行时权限是不同控制层。
- 阅读 Full Stack Deep Learning 2022 的 data management、infrastructure 与 deployment 讲次，映射数据、代码、模型和服务 artifact 的生命周期证据。
- 阅读 Model Context Protocol 官方文档 的 security、authorization 与 server/tool 边界，思考工具调用出站时怎样同时检查能力和数据用途。
深入学习提示
对每种证据都补一句“不能证明什么”，可防止安全剧场。深入时沿一个 bundle 从 source→build→registry→runtime→egress 画链，标明 digest、identity、policy version 和数据类别在哪一步产生或验证；不必引入真实签名服务。
学后填写区
- Artifact 与 provenance 字段：
- Hash 能 / 不能证明：
- Egress / purpose 规则：
- 三种决策示例：
- 未实现的生产能力：