Microsoft Security Blog 於 2026 年 9 月 4 日發表一篇關於 customer-owned Edge AI 的研究文章。核心判斷很直接：當 inference 在裝置、sensor、gateway 或其他由客戶擁有和運行的環境中進行，模型權重、客戶資料、credential 和 system authority 會更接近彼此，誰負責建立信任也會隨之改變。
Cloud AI 通常由不同供應商負責硬件、平台和 model weights 的 attestation；Edge AI 則把更多 stack 交給客戶控制。Microsoft 特別指出，prompt injection、model tampering 和 malicious firmware update 可能在同一個環境出現，而該環境同時保存模型、資料、credential 及通往實體系統的權限。Local 不等於天然安全，反而令客戶要承擔更多 verification。
文章提出四個互相配合的控制：用 attestation 驗證 runtime，用 provenance 驗證會影響模型行為的 artifacts，用 deterministic mediation 約束 model actions，再用 evidence-based release 決定何時把 weights、keys 或 data 放入環境。四者不是同一件事：乾淨的 runtime 仍可載入被污染的 artifact；來源可信的 artifact 也可能在已被入侵的平台上執行。
Deterministic mediator 應該在模型之外工作，將可用 action allowlist、限制 argument scope、控制頻率，並只在批准後釋放 credentials。Microsoft 的說法是，model output 應該是 recommendation，不應該本身成為 authorization。對高後果或不可逆的動作，仍要有獨立批准、interlock 或 fail-safe；mediator 可以縮小 blast radius，但不保證每一個已允許的動作都是安全的。
Edge AI 的另一個難點是 disconnected operation。裝置在失去雲端連線時，不能依賴即時 detection、policy update 或 revocation，因此本地要保留 verification 和 enforcement。如果 runtime 或 loaded components 沒有足夠 evidence，風險操作應該延後或要求重新驗證，而不是因為系統仍然可以運行就繼續執行。
Microsoft 亦把 model security 擴展到 data、context 和 tool call。Prompt injection 可以改變代理行為；被污染的 retrieval document 可能看似來自可信來源，卻不代表適合給模型解讀；同一輸入在不同 context 下也可能產生不同 output。這些特性令 signed binary、傳統 vulnerability scanning 和單純的 content filter 不足以單獨畫出可接受的 authority boundary。
在 release 流程上，attestation 回答「這個 runtime 是否可信」，provenance 回答「這個 component 從哪裡來、由哪個 build pipeline 產生」。Microsoft 建議把 release 當成會過期的 lease：系統狀態改變、evidence 不再符合 baseline 時，scheduler placement、storage、identity 和 credential release 都要重新評估。這種思路比一次性批准一部 edge device 更接近真實營運。
這篇文章的實際價值，是提醒企業不要把「模型放在自己的設備」直接等同於資料主權或安全。Edge AI 需要從 hardware、firmware、runtime、model、integration 到 customer policy 的完整 evidence chain，亦需要把 agent output 當作不可信輸入。真正可落地的設計，是把模型的推理能力和系統的授權能力分開，讓每次高風險 action 都有可驗證的條件和人手介入點。
