Apple 對 prompt injection 的第一方解答

Q: 哪些 API 實現了這些護欄？

在 Foundation Models 中，是生命週期事件修飾器：.onToolCall（在執行前確定性攔截每一次工具呼叫；拋出錯誤即封鎖該工具）與 .historyTransform（在每一輪推理前改寫對話記錄的尾端），並以 @SessionProperty 處理持久化的轉換。1在 App Intents 中，schema 繼承的風險中繼資料驅動情境式確認，而 authenticationPolicy 以只准更嚴格的覆寫控管鎖定畫面的存取。1

3分鐘閱讀

Apple 如今直接點名 Simon Willison。在 WWDC 2026 的第 347 場議程中，一位 Apple 安全工程師對代理風險的描述方式，正是本部落格安全系列一年來所採用的視角：「我們可以參考 Simon Willison 的 Lethal Trifecta，它指出當一個代理系統同時具備以下三項條件時，使用者面臨的風險最高：存取私密資料、暴露於不可信內容，以及對外通訊的能力。」¹這場議程、Privacy and Security 小組的實驗室，加上同週一篇 security.apple.com 的公告，共同拼出了迄今最完整的一幅圖景——擁有最大裝置規模的平台供應商，是如何思考代理安全的：以確定性護欄為基準，以機率性護欄為強化，並在底層以基礎設施證明（attestation）作為支撐。

Watch on Apple Developer ↗

lethal trifecta，引用於第 347 場議程的 5:55 處。

重點摘要

第 347 場議程是 Apple 的第一方 prompt injection 準則：先透過威脅建模辨識不可信的脈絡，接著「以確定性緩解措施作為基準，因為其安全保證更易於稽核與推理」，再於其上疊加 spotlighting 等機率性緩解措施。¹
這些護欄是實際出貨的 API，而非建議。Foundation Models 的生命週期事件修飾器提供確定性掛鉤：.onToolCall 會在每次工具呼叫執行前攔截，並可透過拋出錯誤加以封鎖；.historyTransform 則在每一輪推理前改寫對話記錄，用於加上 spotlighting 分隔符與 PII 遮蔽。¹
App Intents 會自動執行風險控管：intent 從其採用的 schema 繼承風險中繼資料，一套風險評估系統會觸發情境式確認，而 authenticationPolicy 只能朝更嚴格的方向覆寫。¹
同一週，Apple 將 Private Cloud Compute 擴展到自家資料中心之外，運行於 NVIDIA 硬體上的 Google Cloud，維持相同的五項核心要求，並讓軟體證明「植根於至少兩個來自獨立廠商的分離信任根」。²
Privacy and Security 小組的實驗室補上了更多細節：Apple 描述自己在 Siri AI、Safari 與 Xcode 之間運用這套「確定性加機率性」的堆疊，而當 Xcode 作為 MCP 伺服器運作時，其代理功能會採用工具允許清單。³

準則：確定性優先，機率性其次

第 347 場議程以一個範例 App 走過一遍威脅模型，任何在正式環境中運行代理的人都會覺得熟悉。間接 prompt injection 被定義為「嵌入在提供給模型的額外脈絡中、意圖重導控制流程的指令」，議程並將其後果拆成兩種值得分開看待的效應：資料中毒（data poisoning），即「攻擊者影響某個已執行動作的參數」，以及動作中毒（action poisoning），即「攻擊者影響要執行的是哪個動作」。¹這場議程對技術現狀的坦白，是供應商材料中罕見的：「解決間接 prompt injection 是一個活躍的研究領域，意味著我們目前最好的做法，是了解你的 App 風險有多大，並設法緩解該風險。」¹

排序原則才是值得在設計審查中引用的部分。確定性緩解措施居先，「因為其安全保證更易於稽核與推理」；機率性緩解措施值得加上，是因為「不同的模型可能更有效地執行這些限制」，但議程隨即坦承其侷限：spotlighting「是一種機率性緩解措施，因為 prompt injection 可能被建構成抵銷 spotlighting 的形式」。¹使用者確認與裝置解鎖要求落在帳本中確定性的那一側。遮蔽可讓 PII 根本不會抵達模型，「因此也就無法被外洩」。¹Apple 表示自己在設計 Siri AI 時即運用了這些緩解措施。¹

威脅模型中有一個細節值得留意，因為它捕捉到大多數允許清單會漏掉的情況。一個建立計時器的動作看似無害，直到你注意到它那個可選的標籤參數：prompt injection 可以把標籤設成攻擊者控制的文字，而「隨後一個列出計時器的查詢，便能把這份攻擊者控制的資料拉進該脈絡，從而也污染了新的脈絡」。¹帶有可寫字串欄位的無副作用工具，正是注入攻擊的持久化機制。

Foundation Models 護欄 API

議程的實作部分把準則對應到兩個出貨的介面。在 Foundation Models 框架中，生命週期事件修飾器是「在 session 執行過程中的特定生命週期節點上確定性觸發的回呼」。¹

.onToolCall 是動作檢查點。它「保證在 LLM 輸出工具呼叫時、且在執行器運行該工具之前觸發」，而其契約正是有用之處：「若此回呼拋出錯誤，則該工具永遠不會被執行。」¹議程的範例在某處將一個具財務影響的工具設於使用者確認之後，並為 session 中的每一次工具呼叫取得了覆蓋。這個形態正是本部落格在核准提示不等於授權中所主張的：檢查存在於執行路徑中，而非模型的指令裡。

.historyTransform 是輸入檢查點。它「在對話記錄被渲染給模型進行推理之前觸發」，無論是新的使用者請求或每一次迴圈迭代皆然，議程將其用於兩項提示緩解：把來自不可信來源的工具輸出包進 spotlighting 分隔符，以及用遮蔽佔位符取代敏感資料。¹對實作者而言有個重要細節：經轉換的項目僅限於當前這次推理流程，因此轉換會在每次迭代時重新套用，而 @SessionProperty 標註則是處理昂貴的有狀態轉換時的逃生口。¹

App Intents：你繼承而非編寫的風險中繼資料

面向 Siri 的這一側，其護欄來自 schema 系統。當一個 intent 採用某個 intent schema 時，風險中繼資料會根據該 schema 的副作用「自動被指派」：具破壞性、外洩性，以及更新共享內容的動作風險較高，而「系統較可能為高風險工具觸發確認」。¹一套風險評估系統會把那份靜態中繼資料與動態的系統狀態結合起來，依情境決定是否在 intent 執行前插入一道確認；若使用者拒絕，便完全封鎖該 intent。¹

鎖定畫面的暴露也受到相同對待。由於 Siri 在已鎖定的裝置上仍可運作，實際持有裝置的攻擊者便能觸及你的 intent，因此自訂 intent 會設定 authenticationPolicy、schema 帶有基於敏感度的預設值，而其限制設計得恰到好處：「你可以覆寫 schema 政策，但只能讓它更嚴格」，若你試圖削弱它，編譯錯誤會指出所允許的最低政策。¹編譯器拒絕讓你對某個動作保護不足，正是最具 Apple 風格、所能想像得到的 prompt injection 緩解措施。

基礎設施層：PCC 離開 Apple 的資料中心

在議程播出三天前，Apple 在其安全部落格發表了〈Expanding Private Cloud Compute〉：新的 Apple Intelligence 工作負載如今運行於配備 NVIDIA GPU 的 Google Cloud 上，「首次將我們業界領先的 PCC 隱私承諾延伸到第三方資料中心」。²五項核心要求原封不動沿用：「無狀態運算、可強制執行的保證、無特權執行階段存取、不可鎖定性，以及可驗證的透明度」。²改變的是實作：NVIDIA Confidential Computing、搭載 TDX 的 Intel CPU，以及 Google 的 Titan 晶片。²

有兩項設計選擇在機密運算的現況中格外突出。對於一旦遭入侵便可能外洩使用者資料的元件，「軟體證明植根於至少兩個來自獨立廠商的分離信任根」，而 Apple 為防範供應鏈攻擊，維護「一份對所有屬於 PCC 機群的 Google Cloud 硬體進行密碼學可驗證、僅可附加的帳本」。²Apple 晶片上 PCC 的架構模式也一併沿用：在專屬命名空間程序中對每個請求進行網路解析、以短存活時間（TTL）回收共享的推理軟體、把經證明的金鑰存放在一個與外部輸入隔離的獨立機密 VM 中。²控制權仍維持集中：「Apple 保有對 PCC 軟體的完全控制；Apple 裝置只會信任由 Apple 以密碼學方式核准的 PCC 軟體」，所有二進位檔皆公開供大眾檢視，而上線的研究模式節點可透過 Apple Security Bounty Program 觸及。²推出採分階段進行，「在夏季預覽期間逐步推進至完整的保護集合」。²

實驗室補上了什麼

Privacy and Security 小組的實驗室在同一週舉行，而 Apple 不為實驗室發布任何字幕，因此以下內容是根據一份在本機轉錄的錄音改寫，而非引述。³這場座談把議程的準則與出貨介面連結起來：那套「確定性加機率性」的堆疊運行於 Siri AI、Safari 與 Xcode 的代理功能之間，而當 Xcode 作為 MCP 伺服器運作時，它會以允許工具的清單來約束代理。³關於 Siri AI 架構，一位與會者描述了一個專屬的、經強化且沙箱化的精靈程序（daemon），以權限授予（entitlement）作為門檻，是收集與格式化使用者資料、使其離開前往 Private Cloud Compute 之前的唯一路徑，而多輪請求會在對話進行中針對新存取的資料重新請求權限。³

另有兩條實驗室線索值得標記以供後續追蹤。座談指出，Foundation Models 的隱私保證並不延伸到透過框架的語言模型協定所觸及的第三方模型；開發者自行負責閱讀那些供應商的條款並據以揭露。³而在那個長期困擾 WebAuthn 採用的 passkey 生命週期問題上，一位與會者指出 Signal API 即是已解決的答案：網路標準如今定義了 signalUnknownCredential、signalAllAcceptedCredentials 與 signalCurrentUserDetails，用於在依賴方與驗證器之間保持憑證同步，而這套 API 已真實存在並在 W3C WebAuthn Level 3 中出貨。⁴

該從中汲取什麼

有用之處不在於 Apple 解決了 prompt injection；議程明白表示沒有人做到。有用之處在於，目睹一位平台供應商對某種排序作出承諾：先在執行路徑中設置確定性控制、其次是模型層級的提示、底層則是基礎設施證明。對於不在 Apple 平台上開發代理的人來說，每一塊都有對應物：.onToolCall 是你的工具呼叫攔截器，.historyTransform 是你的脈絡淨化器，schema 繼承的風險中繼資料是你的工具分類表，而只准更嚴格的 authenticationPolicy 覆寫則是你的政策下限。框架名稱是 Apple 的；架構則可移植，且它與本部落格在一個具備兩個不可信輸入的代理與工具增強代理的執行階段防禦中所闡述的縱深防禦相符。

常見問題

Apple 建議的 prompt injection 防禦是什麼？

先做威脅建模（辨識不可信的脈絡來源與動作副作用），接著套用「確定性緩解措施作為基準，因為其安全保證更易於稽核與推理」，再於其上加上 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 生態系系列。

參考資料

Apple, WWDC 2026 session 347, Secure your app: mitigate risks to agentic features. Official transcript. Source for the Simon Willison Lethal Trifecta citation (private data, untrusted content, external communication), the indirect-prompt-injection definition (“instructions embedded in extra context provided to the model with the intent to redirect control flow”), the data-poisoning and action-poisoning distinction, the active-research-area framing, the deterministic-baseline doctrine and the spotlighting caveat, the Siri AI usage statement, the timer-label context-poisoning example, the .onToolCall contract (guaranteed trigger before execution, throwing blocks the tool), the .historyTransform behavior (fires before each inference render, spotlighting delimiters, “[REDACTED]” placeholder, per-iteration scoping, @SessionProperty for stateful transformations), and the App Intents guardrails (schema-inherited risk metadata, the risk evaluation system combining static metadata and dynamic system state, contextual confirmations, authenticationPolicy with sensitivity-based schema defaults and stricter-only overrides enforced by a build error). ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩
Apple Security Engineering and Architecture et al., Expanding Private Cloud Compute, Apple Security Research blog, June 8, 2026. Source for the Google Cloud and NVIDIA expansion (“extending our industry-leading PCC privacy commitments to third-party data centers for the first time”), the unchanged core requirements (“stateless computation, enforceable guarantees, no privileged runtime access, non-targetability, and verifiable transparency”), the implementation stack (NVIDIA Confidential Computing, Intel CPUs with TDX, Google’s Titan chip), the dual-vendor attestation (“software attestation is rooted in at least two separate roots of trust from independent vendors”), the append-only hardware ledger, the carried-over architectural patterns (namespaced per-request parsing, short-TTL software recycling, isolated attested-key VMs), Apple’s retained software control, public binary inspection with bounty-program research access, and the summer preview ramp. ↩↩↩↩↩↩↩↩↩
Apple, WWDC 2026 session 8009, Privacy and Security Group Lab. Paraphrased from a locally transcribed recording; Apple publishes no official captions for the labs, so the wording here is a paraphrase, not a quotation, and exact phrasing is unverified. Source for the deterministic-plus-probabilistic stack described across Siri AI, Safari, and Xcode; the Xcode MCP-server tool allowlists; the Siri AI hardened-daemon architecture with entitlement gating and mid-conversation permission re-prompts; the statement that PCC guarantees do not extend to third-party models reached through the language model protocol; and the panel’s pointer to the WebAuthn Signal API for passkey lifecycle. ↩↩↩↩↩↩
W3C, Web Authentication: An API for accessing Public Key Credentials Level 3. Source for the Signal API methods signalUnknownCredential, signalAllAcceptedCredentials, and signalCurrentUserDetails, which let relying parties signal credential changes so authenticators can remove or update stale passkeys. ↩