AID-H-002.002
極高
Inference-Time Prompt & Input Validation
行動裝置上的通知內容一旦被加進 AI 推論請求，就開始產生資安風險。助理應該先正規化多語、隱藏、連結和格式化過的通知內容，標成不可信資料，並在這些內容能影響語音助理或工具計畫前，擋下看起來像指令的文字。
Gemini 語音助理：手機通知如何變成提示詞注入入口
SafeBreach 展示了 Gemini 語音助理如何被藏在 WhatsApp、Slack、SMS 等手機通知裡的惡意指令影響。
注意：這篇的防禦責任主要落在語音助理和行動平台供應商，例如 Google Gemini、Amazon Alexa、Apple Siri、Samsung Bixby，以及正在自建助理執行環境的團隊。一般企業如果只是採用供應商提供的助理，通常無法直接修補這條 AI 執行鏈；能做的是透過裝置政策、通知內容設計和供應商治理降低曝險。
威脅分析
- 攻擊從一則看起來正常的通知開始。 攻擊者透過即時通訊 app 傳送訊息，Gemini 讀取通知時，外部訊息內容就會被帶進語音助理的上下文。
- 惡意指令不一定會被使用者看見或聽見。 SafeBreach 描述的做法包括外語文字、不會被語音唸出來的超連結文字，以及讓畫面顯示、語音朗讀和後端解析結果不一致的排版或連結處理。結果是，後端看到的內容像是一段授權提示詞（prompt），但使用者聽到或看到的卻是另一個無害問題。例如，使用者以為 Gemini 只是問「要不要幫你摘要這則訊息？」；但後端真正拿去對應的，可能是「是否允許我開啟這個網址或加入這個會議？」
- Fake Context Alignment 把「確認」變成上下文分裂。 使用者可能以為自己是在回答一個無害的語音提示，所以說了 Yes；但 Gemini 後端卻把這個 Yes 對到藏在通知裡的高影響指令，例如開啟網址、透過 app intent（手機作業系統用來把動作交給其他 app 處理的機制）叫起其他 app 的功能、加入 Zoom 會議，或控制智慧家庭設備。
- 同一條路徑也可能污染較長期的助理狀態。 研究還描述了長期記憶污染和週期性排程動作，所以一則通知不只會影響眼前這次對話，也可能影響之後的助理行為。
- 這不是單一 app 整合的小問題。 任何會讀取通知或訊息、再讓助理呼叫工具的產品路徑，都要把不可信內容和權限分開處理，因為通知通道不是授權通道。
適用的 9 項 AIDEFEND 防禦手法
AID-H-019.004
極高
Intent-Based Dynamic Capability Scoping
原本只是讓語音助理讀取通知內容的流程，不應該只因為通知內容夾帶了指令，就突然取得很大的工具權限。系統應該把每一次互動可執行的動作，限制在使用者當下明確表達的目的內；除非使用者明確要求，否則網址開啟、透過 app intent 開啟其他 app 功能、智慧家庭控制、記憶寫入和排程任務都不應該在可用範圍內。
AID-H-019.003
極高
High-Impact Two-Channel Validator
Fake Context Alignment 的核心，是讓使用者面前的提示和後端授權上下文不一致。例如使用者看到的是「要不要開啟這則通知裡的連結」，但後端真正拿來授權的上下文，卻變成「使用者已同意開啟某個 app 功能或執行後續動作」。高影響動作在執行前，應該經過另一條獨立驗證通道，確認動作、目標、來源、使用者意圖和影響範圍都對得上，不能只相信同一段模型上下文裡的說法。
AID-H-019.005
高
Value-Level Capability Metadata & Data Flow Sink Enforcement
這個案例裡危險的值來自不可信通知，最後卻可能觸發高風險動作，例如開啟瀏覽器、執行 app URI 或 intent、下智慧家庭命令、寫入助理記憶、建立週期性排程。從通知衍生出來的值都應該保留來源標記；除非另一條可信路徑明確授權，不然資料流向政策應該阻擋它們觸發這些動作。
AID-H-019.006
高
Continuous Authorization Verification (Anti-TOCTOU)
語音助理可能先讀訊息，下一輪才在使用者說 Yes 後執行動作。連續授權檢查可以補上這個檢查時間點和實際執行時間點之間的空隙：每個敏感動作要執行時，都要重新比對目前任務、來源、使用者意圖和核准上下文。
AID-D-001.001
高
Per-Prompt Content & Obfuscation Analysis
SafeBreach 的範例仰賴隱藏手法：外語指令、不會被語音唸出來的超連結文字，以及讓使用者和後端看到不同內容的提示詞。每次把通知內容送進模型前，系統都應該先還原模型可能讀到的各種版本，包括顯示文字、隱藏文字、連結文字和解碼後的內容，再一起檢查是否夾帶指令，而不是只看表面文字。
AID-M-009.002
高
Authority Envelope & Action Risk Classification
開啟連結、透過 app intent 開啟其他 app 功能、加入通話、控制家庭設備、寫入助理記憶、建立週期性動作，風險並不一樣。權限範圍應該先把這些動作分類，定義哪些在通知讀取情境下可以做、哪些要阻擋、哪些需要人工確認或進一步確認。
AID-D-003.005
中
Stateful Session Monitoring: Intent Drift + Invariant-Breach Signals
這種攻擊是有狀態的（stateful）：藏在通知裡的指令、下一輪的語音確認、最後的工具動作，可能分散在不同回合，每一步單獨看都像正常互動，要把整個工作階段串起來看才看得出攻擊。所以工作階段監控應該偵測意圖偏移、延遲出現的工具呼叫、可疑輸入後的記憶寫入，以及和原始使用者要求對不上的重複核准提示。
AID-H-018.007
中
Dual-LLM Isolation Pattern
可以讓隔離模型讀原始通知，只輸出型別明確、權限低的摘要；真正持有工具權限的模型或工具派發器，只接收通過驗證的欄位。這樣能降低藏在通知裡的指令碰到可執行工具元件的機會。
身為資安防禦者，我們應該這麼做
- 先分清楚自己站在哪一側。語音助理供應商、行動平台業者和自建助理執行環境的團隊，應該把以下項目當成工程控制；一般企業如果只是使用 Gemini 這類供應商助理，則比較適合把它們當成供應商評估、採購要求和曝險管理的檢查項目。
- 盤點所有會讀取通知、訊息、email、行事曆項目或聊天內容的助理路徑，並確認這些路徑是否能呼叫工具、開啟網址、透過 app intent 開啟其他 app 功能、寫入記憶，或排程未來動作。
- 把通知和訊息內容都當成不可信資料。不要讓它們進入開發者、系統或授權通道；同時保留來源中繼資料（metadata），例如 app、寄件者、時間戳、可見狀態，以及內容是否來自超連結或隱藏欄位。
- 在組裝上下文前，先正規化並掃描通知內容。檢查多語文字、連結、隱藏或不會唸出的欄位、Unicode 控制字元、格式技巧，以及對助理下指令而不是給使用者看的文字。
- 只要高影響動作接近通知讀取流程，就要求更進一步的確認。確認內容必須說清楚確切動作和目標，不能只是問使用者要不要繼續。
- 來自通知的資料，預設一律不能拿去觸發高風險動作；同時要記錄上下文切換，例如讀取通知後接著啟動工具、可疑內容後接著出現 Yes 確認，或從訊息內容寫入記憶。
1 個額外的防禦考量
語音與畫面授權一致性
在上述技術之外，語音助理還需要產品層級的保證：語音唸出的提示、螢幕上的確認、後端授權記錄和最後執行的動作，都必須描述同一件事。
建議做法: 把確認動作綁到一份標準化摘要，清楚列出來源 app、要求的動作、目標和風險類別，並在執行前用同一份摘要顯示或唸給使用者確認。
結論
這份研究提醒我們，語音助理的失守點不只在模型邊界。真正的問題是，不可信訊息內容、使用者感知、授權檢查和工具執行不再描述同一件事。AIDEFEND 在這裡對應到的防線包括：推論時驗證提示詞、縮限工具權限、獨立驗證高影響動作、控管資料能不能觸發高風險動作、連續授權檢查、偵測混淆內容、定義動作風險範圍、監控工作階段，以及隔離讀取不可信內容的模型。
防禦責任邊界也要講清楚。以 Gemini 這類供應商提供的助理來說，大部分控制點必須由語音助理或行動平台供應商實作；一般企業採用者可以透過裝置政策、通知內容設計和供應商治理降低曝險，但無法直接修補供應商端的助理執行環境。務實目標仍然很清楚：讓助理可以安全讀通知，但不要讓通知變成藏在背後控制助理的通道。