Apple 应对提示词注入的第一方答卷

Apple 如今会指名引用 Simon Willison。在 WWDC 2026 第 347 场分享中，一位 Apple 安全工程师对智能体风险的阐述，与本博客一年来的安全主线如出一辙：”我们可以借鉴 Simon Willison 提出的 lethal trifecta，它指出，每当一个智能体系统同时具备以下三项能力时，用户便面临最大的危险：访问私密数据、接触不可信内容，以及对外通信的能力。”¹ 这场分享、隐私与安全组的实验室专场，以及同一周 security.apple.com 上的一则公告，共同构成了迄今为止最完整的图景，揭示了这家拥有最庞大设备保有量的平台厂商如何思考智能体的安全防护：以确定性护栏为基线，以概率性护栏为加固，并以基础设施证明作为一切之下的底座。

lethal trifecta，在第 347 场分享的 5:55 处被引用。

摘要

• 第 347 场是 Apple 的第一方提示词注入方法论：先通过威胁建模识别不可信上下文，再”以确定性缓解措施作为基线，因为它们的安全保证更易于审计和推理”，并在其上叠加 spotlighting 等概率性缓解措施。¹
• 这些护栏是已发布的 API，而非泛泛建议。Foundation Models 的生命周期事件修饰符提供了确定性钩子：.onToolCall 在执行前拦截每一次工具调用，并可通过抛出错误将其阻断；.historyTransform 在每轮推理前重写会话记录，用于注入 spotlighting 分隔符和进行 PII 脱敏。¹
• App Intents 自动强制执行风险策略：意图会从其采用的 schema 继承风险元数据，风险评估系统会触发上下文相关的确认，而 authenticationPolicy 只能被覆盖为更严格的策略。¹
• 同一周，Apple 将 Private Cloud Compute 扩展到自有数据中心之外，部署到搭载 NVIDIA 硬件的 Google Cloud 上，同时保持原有的五项核心要求，并将软件证明”植根于来自独立厂商的至少两个相互独立的信任根”。²
• 隐私与安全组的实验室专场补全了细节纹理：Apple 表示，这套确定性加概率性的体系已贯穿应用于 Siri AI、Safari 和 Xcode，其中 Xcode 作为 MCP 服务器运行时，其智能体功能会使用工具白名单。³

方法论：确定性优先，概率性其次

第 347 场分享通过一个示例应用，走完了一套对任何在生产环境中运行智能体的人都不会陌生的威胁模型。间接提示词注入被定义为”嵌入在提供给模型的额外上下文中、意图改变控制流的指令”，并将其后果拆分为两种值得分别看待的效应：数据投毒，即”攻击者影响已执行操作的参数”；以及操作投毒，即”攻击者影响要执行的是哪个操作”。¹ 这场分享对技术现状的坦诚程度，是厂商材料中罕见的：”解决间接提示词注入是一个活跃的研究领域，这意味着我们目前最好的做法是理解你的应用面临多大风险，并力求缓解该风险。”¹

其中的排序原则，是值得在设计评审中逐字引用的部分。确定性缓解措施排在首位，”因为它们的安全保证更易于审计和推理”；概率性缓解措施也值得加入，因为”不同的模型可能更有效地强制执行这些限制”，但这场分享随即承认了它的局限：spotlighting”是一种概率性缓解措施，因为提示词注入可以被构造成抵消 spotlighting 的形式”。¹ 用户确认和设备解锁要求则归在账本的确定性一侧。脱敏让 PII 根本无法到达模型，”因此也无法被外泄”。¹ Apple 表示，它在设计 Siri AI 时已采用了这些缓解措施。¹

威胁模型中有一处微妙之处值得关注，因为它捕捉到了大多数白名单会漏掉的情形。一个创建定时器的操作看似无害，直到你注意到它那个可选的标签参数：一次提示词注入可以将标签设置为攻击者控制的文本，”随后一次列出定时器的查询，便能将这些攻击者控制的数据拉入该上下文，从而也把新的上下文一并投毒”。¹ 带有可写字符串字段、本身无副作用的工具，正是注入得以持久化的载体。

Foundation Models 的护栏 API

这场分享的实现部分，将方法论映射到了两个已发布的接口面上。在 Foundation Models 框架中，生命周期事件修饰符是”在会话执行的特定生命周期节点上确定性触发的回调”。¹

.onToolCall 是操作检查点。它”保证在 LLM 输出工具调用时、且在执行器运行该工具之前触发”，而其契约才是真正有用的部分：”如果该回调抛出错误，则该工具永远不会被执行。”¹ 分享中的示例在一处把一个涉及资金影响的工具置于用户确认之后，并由此覆盖了会话中的每一次工具调用。这与本博客在审批弹窗不等于授权中所主张的形态完全一致：检查应当存在于执行路径中，而不是模型的指令里。

.historyTransform 是输入检查点。它”在会话记录被渲染交给模型推理之前触发”，既在新的用户请求上触发，也在每轮循环迭代中触发，分享将其用于两项提示词缓解措施：把来自不可信来源的工具输出包裹进 spotlighting 分隔符中，以及用脱敏占位符替换敏感数据。¹ 有一处细节对实现者很重要：被转换的条目仅作用于当前这一轮推理，因此转换会在每轮迭代中重新应用，而 @SessionProperty 注解则是针对开销较大的有状态转换的逃生通道。¹

App Intents：你继承风险元数据，而非自己编写

面向 Siri 的一侧从 schema 系统获得其护栏。当一个意图采用某个意图 schema 时，风险元数据会基于该 schema 的副作用”被自动分配”：破坏性的、外泄性的，以及更新共享内容的操作风险更高，而”系统更有可能为高风险工具触发确认”。¹ 风险评估系统会将这些静态元数据与动态系统状态相结合，依据上下文判断是否在意图执行前插入一次确认；拒绝该确认将彻底阻断该意图。¹

锁屏暴露面也受到同样的处理。由于 Siri 在已锁定的设备上也能工作，物理持有设备的攻击者便可触及你的意图，因此自定义意图需设置一个 authenticationPolicy，schema 会带有基于敏感度的默认值，而那条约束恰到好处：”你可以覆盖 schema 的策略，但只能改得更严格”，如果你试图削弱它，会触发一个构建错误，并指明所允许的最低策略。¹ 编译器拒绝让你给某个操作设置不足的保护——这是最具 Apple 风格、最容易想见的提示词注入缓解措施。

基础设施层：PCC 走出 Apple 自有数据中心

在这场分享播出三天前，Apple 在其安全博客上发表了《扩展 Private Cloud Compute》：新的 Apple Intelligence 工作负载如今运行在搭载 NVIDIA GPU 的 Google Cloud 上，”首次将我们业界领先的 PCC 隐私承诺扩展到第三方数据中心”。² 五项核心要求原封不动地延续：”无状态计算、可强制执行的保证、无特权运行时访问、不可定向，以及可验证的透明度。”² 改变的是实现方式：NVIDIA Confidential Computing、搭载 TDX 的 Intel CPU，以及 Google 的 Titan 芯片。²

有两处设计抉择在机密计算的现状中尤为突出。对于一旦遭到入侵便可能外泄用户数据的组件，”软件证明植根于来自独立厂商的至少两个相互独立的信任根”，并且 Apple 维护着”一份对 PCC 集群中所有 Google Cloud 硬件的、可加密验证的仅追加账本”，以对抗供应链攻击。² PCC 在 Apple 芯片上的架构模式也一并延续：在专用命名空间进程中按请求解析网络数据、共享推理软件以较短的存活时间循环回收、把经过证明的密钥保存在一个与外部输入相隔离的独立机密 VM 中。² 控制权依然集中：”Apple 保留对 PCC 软件的完全控制；Apple 设备只会信任由 Apple 加密批准的 PCC 软件”，所有二进制文件都公开供公众检视，处于运行状态的研究模式节点可通过 Apple Security Bounty 计划访问。² 此次推出是分阶段进行的，”在夏季预览期内逐步推进至完整的防护集”。²

实验室补充了什么

隐私与安全组的实验室专场在同一周举行，而 Apple 不为实验室专场发布任何字幕，因此以下内容是基于本地转录的录音转述，而非直接引用。³ 这场座谈把分享的方法论与已发布的接口面联系了起来：那套确定性加概率性的体系贯穿运行于 Siri AI、Safari 以及 Xcode 的智能体功能之中，而当 Xcode 作为 MCP 服务器运行时，它会用一份获准工具的白名单来约束智能体。³ 在 Siri AI 架构方面，一位与会者描述了一个专用的、经过加固的沙盒守护进程，并以权限授予（entitlement）作为门控，它是用户数据在离开前往 Private Cloud Compute 之前进行收集与格式化的唯一路径；对于多轮请求，会在对话进行中针对新访问的数据重新请求授权。³

还有另外两条实验室线索值得标记以待跟进。座谈指出，Foundation Models 的隐私保证并不延伸到通过该框架的语言模型协议所接入的第三方模型；开发者需自行阅读这些提供方的条款并据此进行披露。³ 而在长期困扰 WebAuthn 采用的 passkey 生命周期问题上，一位与会者将 Signal API 指为已解决的答案：Web 标准如今定义了 signalUnknownCredential、signalAllAcceptedCredentials 和 signalCurrentUserDetails，用于在依赖方与认证器之间保持凭据同步，该 API 已真实存在并在 W3C WebAuthn Level 3 中发布。⁴

可以从中带走什么

真正有用的，并不是 Apple 解决了提示词注入；这场分享直言不讳地表示，没有人解决了它。真正有用的，是看到一家平台厂商笃定地确立了一种排序：执行路径中的确定性控制优先，模型层面的提示其次，基础设施证明垫底。对于在 Apple 平台之外构建智能体的人来说，每一块都有其等价物：.onToolCall 就是你的工具调用拦截器，.historyTransform 就是你的上下文清洗器，从 schema 继承的风险元数据就是你的工具分类表，而只能改严的 authenticationPolicy 覆盖就是你的策略下限。框架名称是 Apple 的；架构则是可移植的，它与本博客在一个拥有两个不可信输入的智能体和面向工具增强型智能体的运行时防御中所阐述的纵深防御不谋而合。

常见问题

Apple 推荐的提示词注入防御方法是什么？

先做威胁建模（识别不可信上下文来源和操作的副作用），再施加”作为基线的确定性缓解措施，因为它们的安全保证更易于审计和推理”，并在其上加入 spotlighting 等概率性缓解措施。¹ 具体而言：对有风险的操作要求用户确认和设备解锁，对不可信上下文施加 PII 脱敏和 spotlighting 分隔符。

哪些 API 实现了这些护栏？

在 Foundation Models 中，是生命周期事件修饰符：.onToolCall（在执行前确定性地拦截每一次工具调用；抛出错误即阻断该工具）和 .historyTransform（在每轮推理前重写会话记录的尾部），并辅以 @SessionProperty 用于持久化的转换。¹ 在 App Intents 中，从 schema 继承的风险元数据驱动上下文相关的确认，而 authenticationPolicy 以只能改严的覆盖来控制锁屏访问。¹

Apple 真的把 Private Cloud Compute 迁到了 Google 的云上吗？

是的，对于新的 Apple Intelligence 工作负载。PCC 如今扩展到了搭载 NVIDIA GPU、Intel TDX 和 Google Titan 芯片的 Google Cloud 上，保持原有的五项 PCC 要求、双厂商证明信任根、一份仅追加的硬件账本，以及仅由 Apple 批准软件的机制，并在夏季预览期内逐步推进。² PCC 的保证仍然不延伸到通过语言模型协议接入的 Gemini 或 Claude 等第三方模型。³

这些内容有任何能用在 Apple 平台之外的吗？

架构可以。执行路径拦截器、上下文清洗器、工具风险分类，以及策略下限，都是可移植的模式；Apple 的实现之所以值得注意，是因为它们以带有确定性契约的框架 API 形式发布，而非仅仅作为指南。

Apple 的缓解体系落在了本博客已绘制一年的版图上：trifecta 的框架见于一个拥有两个不可信输入的智能体，执行路径的论证见于审批弹窗不等于授权，而基础设施的故事见于Foundation Models 与 Private Cloud Compute。整个系列的入口是 Apple 生态系统系列。

参考资料