AIDEFEND in Action AIA-0030 實證研究 發布於 AIA: 2026年6月9日

Gemini 語音助理：手機通知如何變成提示詞注入入口

SafeBreach 展示了 Gemini 語音助理（Google 的語音助理）如何被藏在 WhatsApp、Slack、SMS 等手機通知裡的惡意指令影響。

注意：這篇的防禦責任主要落在語音助理和行動平台供應商，例如 Google Gemini、Amazon Alexa、Apple Siri、Samsung Bixby，以及正在自建助理執行環境的團隊。一般企業如果只是採用供應商提供的助理，通常無法直接修補這條 AI 執行鏈；能做的是透過裝置政策、通知內容設計和供應商治理降低曝險。

Indirect Prompt InjectionSocial EngineeringTool AuthorizationInput ValidationMobile Security
9 項對應的 AIDEFEND 防禦手法
來源: Gemini's Secret Affair: Exploiting Gemini Voice Assistant Through Instant Messaging Apps 
作者: Or Yair (SafeBreach Labs)
原文發布: 2026年6月3日

威脅分析

  • 讀取通知會把外部訊息帶入助理脈絡。 攻擊者先傳送訊息，等助理讀取通知；訊息送達本身不等於工具已執行。
  • 使用者聽見的內容可能少了一部分。 SafeBreach 測試了外語問題後接無害英文問題，以及將惡意內容放進不會朗讀的超連結。
  • 稍後的確認可能被對到另一個問題。 在 Fake Context Alignment 的實測情境中，使用者說出的 Yes，可能觸發攻擊者要求的工具動作。研究者提出後端脈絡不一致作為成因解釋，但未驗證供應商內部的實作方式。
  • 研究展示了動作與持續影響路徑。 在測試權限下，包含網址與 app URI 動作、智慧家庭控制、記憶污染及週期性任務。Google 後續推出內容分類器更新；來源沒有證明所有部署或未來變體都已受到完整保護。

適用的 9 項 AIDEFEND 防禦手法

AID-H-018.004
Intent-Based Dynamic Capability Scoping
高
在可控制的工具派送位置，取呼叫者、工作負載、工具登錄資料與另行核准任務權限的交集，並檢查具簽章的權限範圍、期限與不可被並行呼叫繞過的動作次數上限；須包含 G002 的可信登錄資料與外部稽核驗證。不可信內容只能縮小權限，不能新增工具。這能拒絕範圍外的呼叫，但不會自動阻止既有允許工具遭到濫用，或任務範圍內的惡意回答。其他執行路徑也須實測涵蓋；列出此技術不代表代管平台已落實。
AID-H-018.003
High-Impact Independent Validation & Approval Gate
高
高影響動作不能只依賴模型脈絡中的 Yes。應由獨立驗證通道，讓使用者確認同一份確切動作、目標、來源與影響範圍，再將核准綁定到執行請求。來源展示了確認不一致的風險，但沒有驗證供應商內部如何配對確認。
AID-H-018.006
Continuous Authorization Verification (Anti-TOCTOU)
高
語音助理可能先讀訊息，下一輪才在使用者說 Yes 後執行動作。連續授權檢查可以補上這個檢查時間點和實際執行時間點之間的空隙：每個敏感動作要執行時，都要重新比對目前任務、來源、使用者意圖和核准上下文。
AID-M-009.002
Authority Envelope & Action Risk Classification
高
開啟連結、啟動 app 功能、加入通話、控制家庭設備、寫入記憶與建立週期性動作，風險不同。權限與風險紀錄負責分類，並明列通知情境下的處置需求；真正的放行、阻擋與確認，由 H-018 的執行時關卡負責。
AID-H-036
Multilingual & Locale-Stratified Prompt Safety Classifier Evaluation
高
依語言與地區分層測試通知入口的安全分類器，涵蓋支援、未支援與混合語言，以及不會朗讀的連結與不同呈現方式。保留研究中的外語及隱藏文字攻擊內容，產出具簽章的分群測試涵蓋率與召回率證據。這項技術提供評估結果；是否拒絕發布或部署，由另一個放行關卡決定。
AID-H-002.002
Inference-Time Prompt & Input Validation
中
依欄位規則驗證 Unicode，並以另行校準的放行檢查處理供應商實際讀入的完整通知內容，綁定確切內容與政策版本。擷取不會朗讀的連結，以及比對語音、畫面與確認內容，需要供應商專用介面。結構符合規則或完成正規化，不代表指令安全，也不代表使用者說 Yes 就已授權該動作。
AID-D-001.001
Per-Prompt Content, Intent & Obfuscation Analysis
中
在營運者可控制的入口，依 G001 使用鎖定版本、經校準的次要分類器，檢查供應商實際送入模型的完整通知文字中的任務轉向、權限宣稱或提權意圖，並產生與確切內容綁定的發現。擷取不會朗讀的連結欄位，以及比對語音、畫面與後端內容，需要供應商另行實作並測試；分類器不提供這些功能。分類結果提供證據，是否拒絕輸入由獨立放行政策決定；看似合理或被隱藏的指令仍可能漏判。放行前須另行驗證完整分類結果與必要類別的涵蓋範圍。目前 G001 範例會把空結果、缺少必要類別或NaN 分數回報為 PASS／NO_FINDING；整合端必須把這些情況視為錯誤並拒絕放行。這是額外需要實作的檢查，不是已公開範例原本就具備的行為。
AID-H-018.005
Value-Level Capability Metadata & Data Flow Sink Enforcement
中
這個案例裡危險的值來自不可信通知，最後卻可能觸發高風險動作，例如開啟瀏覽器、執行 app URI 或 intent、下智慧家庭命令、寫入助理記憶、建立週期性排程。從通知衍生出來的值都應該保留來源標記；除非另一條可信路徑明確授權，不然資料流向政策應該阻擋它們觸發這些動作。 這需要可控的執行環境，為每個衍生值維持可驗證的來源及內容綁定，涵蓋所有出口；標記不明時須拒絕。只在入口加標籤，無法追蹤模型任意改寫。本機程序、瀏覽器請求及允許的目的地須另行驗證涵蓋範圍，不能假定原版 SaaS 已落實。
AID-D-003.005
Stateful Session Monitoring: Intent Drift + Invariant-Breach Signals
中
這種攻擊是有狀態的（stateful）：藏在通知裡的指令、下一輪的語音確認、最後的工具動作，可能分散在不同回合，每一步單獨看都像正常互動，要把整個工作階段串起來看才看得出攻擊。所以工作階段監控應該偵測意圖偏移、延遲出現的工具呼叫、可疑輸入後的記憶寫入，以及和原始使用者要求對不上的重複核准提示。

身為資安防禦者，我們應該這麼做

  • 先分清楚自己站在哪一側。語音助理供應商、行動平台業者和自建助理執行環境的團隊，應該把以下項目當成工程控制；一般企業如果只是使用 Gemini 這類供應商助理，則比較適合把它們當成供應商評估、採購要求和曝險管理的檢查項目。
  • 盤點所有會讀取通知、訊息、email、行事曆項目或聊天內容的助理路徑，並確認這些路徑是否能呼叫工具、開啟網址、透過 app intent 開啟其他 app 功能、寫入記憶，或排程未來動作。
  • 把通知和訊息內容都當成不可信資料。不要讓它們進入開發者、系統或授權通道；同時保留來源中繼資料（metadata），例如 app、寄件者、時間戳、可見狀態，以及內容是否來自超連結或隱藏欄位。
  • 在組裝上下文前，先正規化並掃描通知內容。檢查多語文字、連結、隱藏或不會唸出的欄位、Unicode 控制字元、格式技巧，以及對助理下指令而不是給使用者看的文字。
  • 只要高影響動作接近通知讀取流程，就要求更進一步的確認。確認內容必須說清楚確切動作和目標，不能只是問使用者要不要繼續。
  • 來自通知的資料，預設一律不能拿去觸發高風險動作；同時要記錄上下文切換，例如讀取通知後接著啟動工具、可疑內容後接著出現 Yes 確認，或從訊息內容寫入記憶。

1 個額外的防禦考量

語音與畫面授權一致性

在上述技術之外，語音助理還需要產品層級的保證：語音唸出的提示、螢幕上的確認、後端授權記錄和最後執行的動作，都必須描述同一件事。
建議做法: 把確認動作綁到一份標準化摘要，清楚列出來源 app、要求的動作、目標和風險類別，並在執行前用同一份摘要顯示或唸給使用者確認。

結論

這份研究提醒我們，語音助理的失守點不只在模型邊界。真正的問題是，不可信訊息內容、使用者感知、授權檢查和工具執行不再描述同一件事。AIDEFEND  在這裡對應到的防線包括：推論時驗證提示詞、縮限工具權限、獨立驗證高影響動作、控管資料能不能觸發高風險動作、連續授權檢查、偵測混淆內容、定義動作風險範圍、監控工作階段，以及隔離讀取不可信內容的模型。

防禦責任邊界也要講清楚。以 Gemini 這類供應商提供的助理來說，大部分控制點必須由語音助理或行動平台供應商實作；一般企業採用者可以透過裝置政策、通知內容設計和供應商治理降低曝險，但無法直接修補供應商端的助理執行環境。務實目標仍然很清楚：讓助理可以安全讀通知，但不要讓通知變成藏在背後控制助理的通道。

最後更新: