AID-H-002.002
極高
Inference-Time Prompt & Input Validation
這是最直接的第一道防線。送進本機 LLM 的內容，在過濾前就要先做正規化，包含 Unicode 雙向文字控制字元、隱藏方向性、異常編碼，以及那種看起來不像一般使用者輸入、而是想把原本 app 請模型處理的事情，改成攻擊者指定任務的對抗文字。
Apple Intelligence 本機模型遭提示詞注入：app 資料與功能被帶偏的風險
RSAC 的研究人員把 Neural Exec 這種對人看起來像一長串破碎字元、不自然片段，甚至近似亂碼，卻能把模型往特定任務帶的對抗輸入，和 Unicode 由右至左覆寫控制字元（right-to-left override，RLO）結合，用來繞過 Apple Intelligence 本機 LLM 的輸入、輸出過濾與內部防護規則。Apple 已在新版 iOS 與 macOS 修正受影響系統。這邊學到的重要概念是：OS 級本機 LLM 不能因為「跑在本機」就被當成可信，還需要輸入正規化、輸出驗證、限制每個 app 能讓模型看到什麼、能叫模型做什麼，以及 client 端隔離。
威脅分析
- 攻擊目標是 iOS 與 macOS 由作業系統代管的本機大語言模型。 Apple Intelligence 透過 Foundation Models framework 開放 app 呼叫裝置上的 LLM，所以第三方 app 不需要碰到模型權重或執行期，也能把資料送進系統級模型處理。
- 這個繞過方式分成兩步。 第一步是用 Neural Exec 這類對抗輸入，把模型帶往攻擊者想要的任務。第二步是把攻擊內容混進 Unicode RLO 這種會改變文字顯示順序的字元裡，讓畫面上看到的文字順序和底層真正送進模型、過濾器的內容不完全一樣。這樣輸入與輸出過濾器就更難判斷真正的攻擊內容。
- 成功率不低。 RSAC 的研究人員表示，在 Apple 強化前，他們用 100 個隨機提示詞（prompt）測試，平均攻擊成功率達 76%。
- 真正的風險取決於 app 本來能做什麼。 如果一個健康 app 能讀取使用者的健康紀錄，被帶偏的模型就可能把這些資料整理、摘要或外洩出去；如果是健身或影片編輯 app，攻擊者可能誘導模型改掉訓練計畫、產生錯誤建議，或操作該 app 原本就有權處理的媒體內容。
- 平台已修補完成。 Apple 已在 iOS 26.4 和 macOS 26.4 修正受影響系統；使用者應升級。app 團隊在開發時，也應該限制哪些資料可以送進本機模型，以及模型回覆可以觸發哪些 app 功能。
![RLO rendering example showing the underlying string invoice_2026_[U+202E]fdp.exe and the visually misleading result that appears more like invoice_2026_exe.pdf](../../../assets/aia/rlo-rendering-example.png)
U+202E 會改變後面字元的顯示順序。底層字串仍然包含 .exe，但畫面上可能看起來更像安全的 .pdf 檔名。適用的 7 項 AIDEFEND 防禦手法
AID-H-006.002
極高
Output Content Sanitization & Validation
這次攻擊明確繞過了輸出過濾。由本機 LLM 產生的回應，在顯示給使用者或交給 app 邏輯前，都應該先正規化並檢查，避免 Unicode 重新呈現後才露出真正內容，或讓違反政策的文字、不安全網址、app 動作參數因為原始字串看起來無害就通過。
AID-H-019.004
極高
Intent-Based Dynamic Capability Scoping
app 呼叫 Apple Intelligence 時，只應該拿到完成該使用者意圖所需的最小資料與功能。就算提示詞注入攻擊劫持了摘要或編輯任務，也不該順手繼承健康資料、媒體庫、檔案操作或其他 app 能力。
AID-I-007
高
Client-Side AI Execution Isolation
模型跑在使用者裝置上，所以隔離仍然很重要，即使模型由作業系統管理也一樣。每個 app 都應該待在自己的沙箱裡；app 之間如果要傳資料或呼叫功能，也要經過受控管的本機溝通機制和權限檢查。這樣就算本機模型被帶偏，也比較不會讓 A app 借模型讀到 B app 的資料，或觸發 B app 原本不該被它觸發的功能。
AID-D-001.001
高
Per-Prompt Content & Obfuscation Analysis
Unicode RLO 正是淺層過濾器容易漏掉的混淆手法。提示詞檢查不該只看原始字串，而是要同時分析原文、正規化後、實際呈現後、移除方向控制後的多個版本，再判斷輸入是否安全。
AID-M-009.002
高
Authority Envelope & Action Risk Classification
改動 app 可存取的健康資料、媒體檔案或其他使用者內容，應該被歸類成高風險動作，而不是一般文字生成。app 和 OS framework 都需要明確規則，定義哪些動作要再次確認、直接拒絕，或只把完成任務需要的最少資料交給模型。
AID-H-030.002
中
Lifecycle-Stage Authorization Gate
高機敏 app 資料不該只因為 app 本來讀得到，就自動送進本機 LLM。資料被放進模型上下文前，系統應該先確認三件事：這類資料能不能用在本次推論、這個 app 有沒有權限使用、這次使用者意圖是否真的需要它。
身為資安防禦者，我們應該這麼做
- 把 Apple 裝置升級到 iOS 26.4、macOS 26.4 或更新版本。短期內無法升級的舊版裝置，應該列入風險清單，限制可用 app 或本機模型功能，並優先排程修補。
- 盤點哪些 app 使用 Apple Intelligence 或 Foundation Models framework，接著分類每個 app 能把哪些資料送進本機 LLM 呼叫。
- 在推論前先正規化並檢查模型輸入。Unicode 雙向控制字元、隱藏方向性、巢狀編碼和對抗式亂碼，都應該視為高風險訊號，預設阻擋或要求額外審查。
- 不要只檢查原始輸出字串，要在呈現正規化後再驗證輸出。凡是經 Unicode 呈現後才變危險，或試圖觸發使用者原始意圖外 app 動作的回應，都應該擋下來。
- 把本機模型呼叫限制在完成任務所需的最小 app 能力內。高機敏資料與會改動狀態的動作，在進入模型上下文或模型導向工作流程前，都應該先取得明確的使用者或政策核准。
1 個額外的防禦考量
本機 LLM app 的端點層級權限透明度
除了上面對應的 agent 與 skill 權限控制，平台與企業端點管理層也應該看得見每個本機 LLM app 的實際活動：哪些 app 會呼叫裝置上的模型、連到哪些本機服務、讀寫哪些路徑、能碰到哪些 API key 或 token，以及模型輸出可以影響哪些 app 動作。
建議做法: 在 app review、MDM、隱私設定和端點資產清單中揭露 AI 權限 manifest；讓管理員能阻擋本機 LLM 存取高機敏資料類別；並要求 app 說清楚模型輸出是否能改動檔案、健康紀錄、媒體、訊息或其他使用者內容。
結論
這個案例提醒我們，本機 AI 也會影響整個平台的安全。模型跑在裝置上，確實能降低一部分雲端曝險，但它也因此更靠近 app 資料、使用者檔案和作業系統代管功能。AIDEFEND 對應到的防線包括：先清理模型輸入、驗證模型輸出、限制每個 app 能交給模型的資料和可觸發的功能、隔離 client 端執行環境，以及在高機敏資料被使用前加上授權關卡。實務目標很清楚：就算本機 LLM 被帶偏，它也只能拿到應該有的權限、處理必要資料、執行原本被允許的功能，而不是變成攻擊者操作 app 或資料的入口。