MXC 教學：給 AI 代理檔案與網路權限，先做一份最小政策
Microsoft Execution Containers 以外部政策限制 AI 代理。本文從讀專案、跑測試與寫報告出發，整理檔案、網路範圍，以及各模式的差異。
讓 AI 代理修改網站，最難的問題常常出現在它開始執行命令之後。它應該能改專案，卻不應順便改正式環境設定。它需要安裝套件，也不需要讀取電腦裡所有檔案。
Microsoft 十月七日宣佈 Microsoft Execution Containers，也就是 MXC，已在 Windows 正式提供。
這篇從一個「每天讀專案、跑測試、產生報告」的工作出發，說明如何整理可審查的權限政策。
以下是依官方資料整理的政策設計與測試指南。實際 SDK、設定欄位與代理整合應以使用版本的檔案為準。我們沒有在讀者的電腦安裝 MXC，也沒有宣稱一份示意政策足以涵蓋所有企業環境。
政策應在代理工作之外被執行
提示詞可以告訴代理不要碰某些檔案，但代理仍可能誤解需求，或執行一段超出範圍的程式。MXC 的核心，是由外部政策定義工作能使用的資源，再由對應隔離方式執行。
模型不能因為認為某件事有用，就自行取得更多權限。
這個概念可以從網站專案理解：工作副本允許修改，原始資料只讀，正式服務設定不開放寫入。即使代理提出「改正式設定最快」，執行環境也應阻止超出權限的操作。
你要檢查的是實際結果，而不是隻看模型有沒有說「我會遵守」。
權限政策也不是越嚴越好。若連必要的測試檔案都不能讀，工作就無法完成。正確方向是先說清楚任務，再找出它真正需要的資源。
遇到阻擋時，調整具體資源與操作，而不是因為一次錯誤就給它整個使用者帳號的能力。
先把工作寫成三個階段
以每日專案報告為例，第一階段只讀來源專案，列出版本與待檢查專案。第二階段在工作副本執行測試，避免直接改動原始資料。第三階段把結果寫入指定的報告目錄。
三個階段的輸出很清楚，就比較容易知道哪一部分需要寫入或連網。
每個階段都應有完成條件。來源是否讀到正確版本、測試是否真的執行，以及報告是否包含成功與失敗，不應只由一句「完成了」判斷。如果某個步驟被權限擋住，報告也應明確說明，不能把未執行當成通過。
你可以先讓代理產生一份工作計畫，列出預計使用的命令、檔案與網路目的地。這份計畫是政策草案的輸入，仍需由你核對。
模型可能漏列套件下載或測試中的外部請求，所以後面還要用執行紀錄修正，不必把第一次計畫當成完整清單。
第一份資源表先寫得具體
可以從下列四列開始，路徑與服務名稱替換為實際專案：來源專案只讀、工作副本可寫、報告目錄可寫、必要套件來源可連線。其他個人資料夾與正式設定預設不給。
表格中的每一列，都應能回答「哪個步驟需要它」。
不要只寫「允許開發工具」。應列出工具執行的位置、工作目錄與必要引數。某個命令從不同目錄執行，可能讀到不同設定。環境變數也可能包含不應帶入工作中的資料。
先讓測試環境使用最小資料，會比較容易找出實際依賴。
網路則應區分外部服務與本機服務。資料送到遠端模型、套件下載網站與本機推論端點，目的不同。若工作不需要其中一項，就沒有理由一起開放。
尤其回環介面的存取也應依政策核對，不能認為只要是本機就無關緊要。
選擇隔離方式時，先看工作需要什麼
官方介紹多種後端，包括程式、Windows 工作階段、WSL 與實驗性 MicroVM 等。它們的支援平臺與特性不同。
一般的程式工具工作，和需要獨立桌面的長時間代理，不一定使用相同方式。先看官方後端表，再選擇能滿足任務的最小合理方案。
需要操作桌面的工作，應另外考慮使用者的滑鼠、剪貼簿與登入狀態。如果代理和使用者共享同一個互動桌面，就可能互相干擾。官方 Windows 工作階段隔離的方向，正是把這些界線分開。
實際支援仍依裝置、版本與整合工具確認。
如果工具主要依賴 Linux 套件，WSL 相關路徑可能較適合。但這不代表啟用 WSL 就自動建立完整政策。檔案掛載、網路與憑證仍需檢查。
對第一次匯入而言，不要同時換模型、換作業環境與換所有工具，先讓一種隔離方式完成小工作。
Learning 模式能用來找出缺少的權限
官方把模式區分為 Enforcement、Learning 與 Permissive。
在 Windows 的 MXC process containers 中，Learning 會阻擋未授權存取並留下活動報告，適合診斷政策缺口。
Permissive 則會記錄原本會被拒絕的存取，但允許繼續。它們的行為不同，不能看到有記錄就以為都在阻擋。
初次整理政策，可以在沒有敏感資料的副本中觀察活動。每一個被擋住的資源都應先問：它是完成任務所必需，還是某個工具多讀了一些檔案？如果是必要資源，就增加最小範圍。
如果與任務無關，就保留阻擋並調整工作方式。
Permissive 模式允許未授權存取，不應被當成正式阻擋已生效的證據。Learning 則仍會阻擋，不可混淆。
完成政策後，要用預計採用的執行模式再測一次，確認相同任務能完成，超出範圍的操作會被阻止。報告中把模式寫清楚，避免同事把一次觀察結果當成正式部署。
用無害檔案檢查拒絕行為
正常工作能跑完，只證明授權可能足夠。還需要確認不該發生的操作被擋住。可以在測試環境準備幾個無害檔案：一個可寫、一個只讀、一個完全不開放。
要求測試程式分別執行讀取與寫入，觀察實際結果，並儲存必要的錯誤紀錄。
不要用真正的私人資料或正式系統來驗證拒絕。測試只需要證明界線存在，沒有必要冒險接觸敏感檔案。網路測試也可以使用專門的測試目的地，確認允許與拒絕符合政策。若結果和預期不同，先停在測試環境調整。
還要檢查錯誤是否能被使用者理解。代理被擋住後，是清楚說明哪個步驟未完成，還是隻回傳一段不明訊息？好的工作流程應讓人知道如何處理，而不是讓代理一直嘗試其他路徑。
必要時由使用者或管理者調整具體權限。
不同工具的存取邊界要逐一確認
代理可能同時使用內建檔案工具、子程式、本機 MCP 與遠端服務。這些行為不一定全在相同的隔離邊界內。
Microsoft 與 GitHub 的檔案特別區分了工具路徑，因此部署時應依你使用的代理閱讀實際整合說明，而不是隻看平臺介紹。
整理方式很簡單：列出每一種工具、它在哪裡執行、它能讀寫哪些資料，以及誰執行政策。若某個遠端服務已收到資料，本機程式的隔離不能把資料收回。
若某個內建工具使用代理本身的檢查，也不能直接說它和作業系統隔離完全相同。
這份工具表可以與資源表放在一起。當新增一個外掛或 MCP 服務時，只需回到表中核對新路徑。不要因為原本的代理已通過測試，就把後續新增工具一概視為相同風險與權限。變更應有具體的檢查範圍。
正式設定先用少量任務觀察
第一輪可以只讓一個公開專案或測試專案使用政策。觀察正常工作、失敗、重新啟動與工具更新，確認結果有一致的紀錄。若每天的報告偶爾漏掉某個專案，先找出原因，不要用大量新增權限掩蓋不穩定。
自動化也要有停止與回復方式。當測試不透過、依賴變更或服務無法連線時，應留下狀態，並把需要人處理的專案指出來。代理不應為了交出一份看起來成功的報告，跳過測試或改動正式環境。
這些完成條件要在工作開始前寫清楚。
政策版本應與任務版本一起儲存。更換隔離後端、代理版本或新增網路目的地後，重跑受影響的正常與拒絕測試即可。無關模組不需要重複驗證，但曾出現問題的邊界應保留成檢查專案。
這讓維護工作有範圍，也更容易追蹤變更。
團隊應由誰負責調整政策？
個人試作可以自行管理，但團隊使用時需要明確責任。誰提出新增資源、誰核對用途、誰更新正式政策，以及誰檢視失敗紀錄，最好都能說清楚。
讓每位使用者各自放寬設定，會使相同代理在不同電腦上產生難以比較的行為。
官方也介紹組織管理與代理識別的後續方向，部分能力仍有推出時間。不要把尚未提供的整合寫成已在公司生效。內部報告應區分現有隔離、正在試用的管理工具與未來規劃，並用實際紀錄證明已完成的部分。
如果某項工作需要額外權限，應提供任務理由與具體範圍。像是「允許這個資料夾的報告寫入」，比「給代理更多權限」更容易審查。權限調整可以很小，不必每次都重新討論整個平臺。
常見問題：用了 MXC 就能讓代理自己做所有事嗎？
不能。隔離控制的是可使用資源，不會替你判斷輸出是否正確、是否應對外傳送，或某件事是否需要人做決定。你仍需設定工作完成條件與高影響步驟。
代理能寫入一個檔案，和你同意它釋出到正式網站，是不同授權。
對日常程式工作，較實際的目標是讓它在有限範圍內持續完成任務。讀取來源、修改副本、跑相關測試，再交出可檢視的結果。每個步驟都有清楚的資料與操作範圍，才方便提高自動化程度。
第一份 MXC 政策不需要很複雜，但應能回答四件事：工作需要什麼、允許什麼、拒絕什麼，以及失敗時怎麼知道。先把一個小任務做完整，再逐步加入更多工作，比一開始就給代理整臺電腦更容易維護。
用一份可閱讀的政策說明交接
即使最後採用 JSON 設定，也建議另留一份普通文字說明。每個授權寫出用途、對應步驟與負責人。後來的同事看到某個資料夾可寫，才知道那是測試副本，不是可以任意擴大的專案資料。
這份說明應與實際設定同步更新。
例如每日報告工作可以寫成：「來源專案只讀。測試副本可改。報告只寫到輸出目錄。不允許對外傳送。依賴已準備時測試不連網。」這是人可審查的政策需求，不是 MXC 的設定欄位範例。
要轉成實際 schema 時，仍需依官方檔案核對。
如果測試要求連線，說明應指出目的地與理由，而非把「測試」當成通行證。某項測試若會送資料到外部服務，就先使用無害資料，或調整測試方式。把這個差異寫清楚，才方便管理者決定是否需要增加權限。
交接時讓另一位同事依紀錄跑一個正常工作與一個拒絕測試。兩者都符合預期，才表示說明足以支援後續維護。若只有原設定者能解釋結果，就仍有必要補充記錄。
