Project Perception 擴大保護 AI 代理：Microsoft 為何把模型視為企業內部風險？
Project Perception 擴大處理企業內部 AI 代理風險。本文整理 Microsoft 最新公布的身分、權限與執行環境控制，說明發現 60 種本機代理與實際保護的差別，並用費用審核流程解釋，團隊如何檢查 AI 能做什麼、何時必須停下來。
員工請 AI 整理費用報表，和讓它修改收款帳戶，看起來都只是同一段對話，所需權限卻差很多。Project Perception 這次擴充，處理的正是 AI 進入企業系統後，誰能限制它行動的問題。
Microsoft 於 2026 年 10 月 19 日公布新方向，把公司自己部署的 AI 代理也視為內部風險。代理就是能使用工具、連續完成工作的 AI，可能讀資料、寫程式，也可能修改系統。
因為代理能接觸工作資料，一次判斷錯誤就可能跨出原來任務。只在提示詞寫「不要亂改」，無法代替系統實際檢查它準備存取的資源。
Microsoft 因此主張，決定權限的控制必須放在模型外部。即使模型回答方式改變，哪些資料能讀、哪些動作能做，仍由企業自己的規則決定。
這對已經讓多種 AI 工具參與工作的團隊很有意義。但導入前要先分清楚，產品能發現某個代理，與能在它行動前阻擋風險，是兩種能力。
最值得先處理的，是挑一個已有 AI 參與的流程，列出它需要的權限與負責人。這份清單會決定安全產品究竟要替你攔下什麼。
Project Perception 為何開始處理「內部代理」？
這次更新把防護範圍延伸到企業主動引進的 AI。依 Microsoft 10 月 19 日公告，內部代理往往已握有資料與工具權限，因此需要持續監督。
「內部」描述的是它在組織裡的位置，不代表它有人的惡意。公司可能完全信任提出需求的同事，卻仍要限制替同事執行任務的程式。
例如同事要求把費用按部門分類，代理需要查看報表和部門對照表。如果它為了補齊資料，進一步嘗試變更付款設定，工作範圍便已改變。
這個例子說明，權限要跟著任務界線設計。員工平常能修改付款資料，不代表整理報表的代理也需要繼承同樣權限。
模型還可能接觸帶有額外指令的文件。提示注入就是把要求藏進外部內容，誘使 AI 把資料中的文字當成工作指令，因此輸入來源也會影響行動風險。
企業不必先判定模型是否「值得信任」，才開始規劃防護。先決定工作能接觸哪些資源，模型即使誤解內容，也比較容易被限制在可處理的範圍。
這也把採購問題變得具體。團隊應詢問產品能在哪個執行點介入，而不只看它是否能產生一份風險摘要。
身分、權限與執行環境，要分別控制什麼？
一個代理需要可辨識的身分，才有辦法追到誰建立它、為什麼存在，以及哪個團隊負責。沒有這個起點，後續紀錄很容易只剩一個共用帳號。
Microsoft Entra Agent ID 文件把代理當成可管理的非人類身分，並提供身分範本與父子關係，讓大量代理可以沿用一致政策。
父子關係能幫助管理，但不能直接推出權限完全相同。若總代理負責研究，子代理只負責整理文件，後者的資料範圍仍可以更小。
以下幾個層次各自回答不同問題，實作時需要一起對照。
| 控制層次 | 要回答的問題 | 費用整理的例子 |
|---|---|---|
| 身分 | 這是哪個代理、誰負責？ | 財務部的報表整理代理 |
| 權限 | 它能接觸什麼？ | 可讀指定月份報表 |
| 執行環境 | 它在哪裡工作？ | 有限制的工作容器 |
| 行動限制 | 什麼變更需要攔截？ | 修改付款設定前停下 |
| 紀錄 | 如何追查發生過的事？ | 保存工具呼叫與處理結果 |
表格裡的身分只是第一步。即使名字、負責人都完整，若工具仍接受任何寫入要求，任務界線就沒有真正落到系統行為。
執行環境則決定錯誤能影響多遠。把代理放進受限容器，意思是它工作的檔案、網路與程式空間受到約束，不能只靠模型自己承諾不越界。
這些限制也會影響可用性。若工作需要讀取兩份表，卻只開放其中一份，代理應明確回報資料不足，而不是設法尋找不在任務範圍內的替代來源。
所以導入時要同時準備「可以完成」與「應該停下」的案例。兩者都能重現，才看得出限制是否符合實際工作。
延伸閱讀：AgentID 公開推出：AI 代理有自己的登入身分，誰擁有它、能做什麼怎麼分？
發現 60 種本機 AI 代理，是否等於全部受到即時保護？
發現能力讓企業知道哪些工具正在活動，執行期保護才涉及它們工作時能否被檢查。兩者用途不同，因此不能用同一個支援數量替代。
Microsoft Security 的更新文章表示，新增 35 種本機代理發現支援，總數達 60 種，包含 Claude Code、Codex 與 GitHub Copilot。
但 Defender 支援矩陣另外列出作業系統、代理發現、工具伺服器發現和執行期保護。讀者應沿自己使用的組合核對。
文件也說明，發現以活動為依據。電腦已安裝某個工具，並不保證它立刻出現在代理清單，因為系統還需要觀察到相關活動。
對 IT 人員而言，這會改變盤點方式。軟體清單回答「裝了什麼」，活動清單回答「哪些工具正在工作」，兩份資料可以互補。
如果公司同時使用 Windows 與 Mac，也要分別檢查。某一平台支援的發現方式，不能直接套到另一個平台的執行期阻擋能力。
連接工具的通道，也需要獨立確認
MCP 是讓 AI 連接外部工具與資料的共同介面。能找出代理連了哪些 MCP 服務，有助於辨認資料可能流向哪裡，卻仍要查看各通道可做的動作。
例如同樣叫「文件工具」，一個可能只提供搜尋，另一個同時能分享、刪除或改權限。只記錄工具名稱，會漏掉兩者影響範圍的差別。
因此盤點結果最好接回工具設定。當某個工具多出寫入功能，管理者應能知道哪些代理因此取得新能力，而不是等到第一次使用才發現。
動態限制權限，如何減少工作中斷？
動態控制的目標，是依正在發生的風險調整行動範圍。它不必把每個異常都當成整套系統要停止的理由，才能兼顧工作與防護。
Microsoft 在安全部落格舉出幾種回應方式，包括保留安全讀取、阻擋寫入、縮小資源範圍、要求可證明的人類批准，或在必要時隔離代理。
回到費用報表例子，代理若試圖修改付款設定，可以先阻擋那個動作，保留已完成的分類結果。使用者便能理解哪一段工作完成、哪一段需要重新決定。
但這種分段回應需要足夠的上下文。系統得知道原任務是整理費用，才能分辨讀取報表和改付款資料之間的差距。
上下文是判斷一件事所需的背景，在這裡包括任務、資料、工具與行動紀錄。若背景不完整，正常操作也可能被判成異常。
這使人工處理仍有具體角色。安全團隊可以查看被攔截的動作，判斷是權限開太大、任務描述不清，還是工作本身確實需要調整。
批准畫面也要呈現確切動作。使用者看得到要改的資料、影響範圍與理由，才有辦法做決定，只有一個「繼續」按鈕會讓控制失去意義。
而代理狀態改變後，前端應同步反映。後端已暫停寫入，畫面卻還顯示「全部完成」，會讓同事用錯誤假設接著工作。
團隊如何用一個費用流程驗收？
先選固定資料和明確產出，比一次盤點所有代理更容易看出缺口。以下是建議的試驗設計，並非本站已完成的產品測試。
準備一份不含真實個資的費用範例，指定只整理部門總額。因為任務很小，輸入、輸出與必要權限都容易列清楚。
先跑正常情況，確認系統辨識得到代理，資料讀取也能完成。這一步若失敗，就先處理連線與權限，不急著增加安全規則。
再放入要求修改付款設定的測試情境，查看寫入是否在執行前被限制。重點是系統實際拒絕了什麼，而非模型最後是否口頭表示不做。
接著檢查使用者畫面。它應能交代分類結果仍在、付款修改沒有執行，以及需要哪個負責人處理，讓工作可以從正確位置接續。
最後由未參與設定的同事看紀錄，試著重建原因。如果他只能看到「風險偏高」，卻找不到觸發動作，後續政策調整仍會很困難。
完成小範圍試驗後，再加入第二種工具或另一個平台。因為每次只增加一個變數，團隊比較能分辨問題出在產品支援、工作設定或資料內容。
授權方案也要跟著驗收範圍核對
看到某項身分功能可用，不代表所有安全功能都包含在現有方案。Entra Agent ID 說明把身分平台與進階安全能力的授權條件分開，企業應沿預計使用的能力確認。
因此試驗紀錄可以多加一欄，寫下功能依賴的產品與方案。若阻擋能力需要額外授權，團隊就能把它放進成本比較，而不會只算模型呼叫費。
另一項成本來自處理例外的人力。如果每次正常整理都需要主管介入，工作仍可能塞住，所以要記錄被攔次數、理由，以及每次人工處理花多久。
這些紀錄也能回頭改善工作設計。反覆卡在同一份文件的讀取，可能代表資料範圍設得不合用，與需要更強模型是不同問題。
驗收還應保留一次取消任務的情境。停止後是否仍有工具繼續執行、產物是否標記未完成，會直接影響同事接手時的判斷。
有了正常、越界和取消三種結果，試驗才比較接近日常使用。它能幫團隊判斷產品是否減少處理負擔，也能辨認還需要自己補上的流程。
部署後也需要定期重跑這些案例。模型版本、工具能力或連接方式改變，都可能讓原本合理的限制失去對應，因此保留測試資料能降低重新判斷的成本。
這不表示每次都要做完整稽核。先檢查受影響的流程，確認允許與拒絕的行為仍符合需求，再決定是否擴大範圍，會比較接近團隊能持續維護的方式。
當新的代理加入公司，也可以沿用同一組範例。它能讓不同工具在相同任務下接受比較，避免只靠各自的示範影片判斷控制能力。
延伸閱讀：Workbench 多代理協作教學：用 Markdown 看板，把 AI 交接和驗收寫清楚
Project Perception 常見問題
這次是全新的 Project Perception 嗎？
產品方向在 7 月已公布。10 月更新把同一套安全架構延伸到企業內部代理，因此應分開理解最初發布與這次新增用途。
使用比較強的模型，就可以少做權限控制嗎？
模型能力與系統授權處理不同問題。即使回答更可靠，仍需要明確限制資料與工具範圍，才能把錯誤影響控制在任務之內。
家用電腦也會自動得到相同保護嗎？
不能由新聞直接推論。文件描述的是企業安全產品與已納管裝置，使用條件、平台和設定需依實際方案核對。
代理需要沿用員工的全部權限嗎？
應依任務給予必要範圍。例如整理報表只需要讀取資料，額外的帳戶管理權限並不會讓分類工作更完整。
出現阻擋紀錄，就代表產品判斷正確嗎？
還要比較原任務和被阻擋的動作。因為正常工作也可能受設定影響，紀錄應讓負責人能判斷限制是否合理。
先確認代理的工作界線，再擴大使用
Project Perception 的新方向，適合已有多種代理進入內部工作的團隊評估。產品價值要落在可辨識、可限制、可追查的工作行為，才有助於降低導入負擔。
可以先整理一份正在使用的工具清單，替每個工具補上負責人與必要權限，再挑一個流程做驗收。免費訂閱 AI 郵報，持續了解不同 AI 工具的控制方式與實作限制。
