採購主管只想讓Agent比較三家供應商的報價。接入時卻用了一個既能讀報價、又能改訂單和發郵件的賬號。提示詞寫著“只交草稿”，系統憑據仍然擁有更大的許可權。
這個虛構場景裡，缺的不是最後一遍檢查，而是接入前的AI Agent許可權清單：誰的賬號、能看哪些資料、能做哪些動作、誰來撤回。結果稽核能發現一份比較稿寫錯，卻不能自動消除背後的寫入能力。
先把“整理採購資料”拆成動作
先確定任務：只讀指定三份脫敏報價，交一份比較草稿。價格缺項保留未知，不聯絡供應商、不修改採購系統、不傳送郵件、不付款。
不要只寫“採購工具已連線”。把動作拆開，才能發現任務需要與賬號實際能力之間的距離。
| 動作 | 本次業務要求 | 接入前必須確認 |
|---|---|---|
| read | 讀指定三份報價副本 | 賬號是否還能看到其他供應商或合同 |
| draft | 在指定輸出目錄寫比較稿 | 輸出是否共享，是否含無關客戶資訊 |
| write | 不改正式採購記錄 | provider端scope或角色是否真的排除寫入 |
| send | 不發郵件或通知 | 郵件登入、API許可權是否仍可傳送 |
| delete | 不刪除任何原始檔 | 檔案/工具許可權是否允許刪除 |
這是一份擬定的任務許可權矩陣，不是Buda原生逐工具ACL的介面，也不是已執行拒絕寫入測試。業務上“不允許”和系統上“做不到”必須分欄。
清單裡寫賬號，不寫金鑰
access-inventory.csv至少保留：任務ID、工具、實際賬號主體、資源範圍、允許動作、實際角色或scope、認證位置、授予人、複核人、到期時間或撤回責任、核驗依據與狀態。
任務：Q-01，三份報價比較（虛構）
主體：採購測試賬號的可識別名稱，不使用個人全權賬號
資源：三份已授權報價副本；不含其他採購記錄
業務動作：read指定輸入；draft指定本地輸出
實際scope：unknown，待賬號管理員在provider控制檯核實
認證位置：Agent變數名稱或登入位置，不記錄值
負責人：賬號管理員授予；採購主管複核範圍
接入狀態：等待scope確認，不連線生產憑據
如果工具背後使用的是共享賬號，應列清共享者與責任人；顯示名稱不能證明實際認證主體。瀏覽器登入、API token和另一個整合可能分別代表不同身份，不能只登記其中一個就視為盤點完成。
unknown-scopes.md把不知道的許可權變成具體待辦：哪個系統、哪個賬號、缺什麼證據、由誰核實、核實前暫停哪一步。一次讀取成功，只證明這次讀取發生了，不能證明賬號沒有寫許可權。
masked只是顯示方式，不是程序隔離
Buda環境變數文件說明：變數屬於單個Agent，但會注入它的雲端計算機，可供Terminal、指令碼、開發伺服器以及該Agent執行的程序讀取，並跨sandbox重啟保留。
變數在UI裡被遮住，不意味著指令碼無法讀取它。不要在聊天裡貼值，不把真實token寫進清單，不用列印敏感變數的命令“證明連線正常”。用管理員可見的角色配置、scope說明和非敏感狀態驗證；不要為了核許可權把憑據複製到報告或截圖裡。
同樣，單個Agent的範圍不等於單個Session的範圍。新Session把對話上下文分開，不會把同一Agent的檔案和環境變數自動分開。共享Agent如果需要真正不同的資料或憑據範圍，應先由管理員設計獨立身份與許可權，而不是僅開新對話。
Drive的官方區別是Agent Drive私屬於一個Agent，Space Drive用於空間共享。資料夾叫approved只是名稱，不會施加ACL；放進共享位置之前，仍要確認誰能訪問。
Skill規則、工具清單和系統許可權是三件事
安裝與管理Skill可以檢視完整SKILL.md、來源和範圍。Skill說明如何工作；任務裡“不要傳送”也是行為要求。它們都不能替代連線系統裡的OAuth scope、角色和資源授權。
一個Skill列出某工具，不等於已經取得該系統認證；一個賬號已認證，也不等於只獲得本次任務需要的動作。先讓管理員在provider端核實許可權，再檢查Skill是否按這些邊界工作。不要從manifest的工具名稱推斷平臺提供任意細粒度許可權開關。
如果provider無法細分讀寫，優先採用獲准的脫敏匯出或專用低許可權測試賬號，而不是把全權賬號接上後依賴提示詞自律。業務確實需要寫入時，應另立動作範圍、複核和執行授權。
接入驗收要驗證“允許”和“拒絕”兩面
以下是建議驗收，不是已執行的安全測試。由賬號管理員選無敏感資料的測試環境，明確可接受的測試動作，再安排執行：
- 用指定測試身份讀取允許的樣本，確認來源和範圍。
- 選應被拒絕的寫動作，在不會影響真實記錄的受控物件上驗證provider拒絕；若無法安全測試，標為未驗證，不去碰生產資料。
- 核對其他路徑：瀏覽器登入或另一token是否仍能寫。一個路徑拒絕不代表所有路徑拒絕。
- 記錄測試身份、資源、配置依據和結果，不記錄secret。失敗就停在接入環節，不先安排週期任務。
“不列印敏感值”與“許可權正確”也不是一回事：前者減少暴露，後者需要實際授權依據。兩項都要做，但不能互相替代。
撤回不止是關閉對話
revocation-checklist.md列出provider token或角色、Agent環境變數、瀏覽器登入與會話、已分發共享副本各自的責任人和核實方式。先確認需要撤回哪項，再按對應系統操作並保留確認記錄。
關閉Session或取消任務，不等於provider憑據失效。刪除環境變數也不應被當成已結束的程序、瀏覽器登入和所有副本都已清除的證明。共享副本的保留或清理要按組織規則另行處理；不要讓Agent自行刪除檔案來製造“已撤回”的表象。
三個產物，讓管理員能接手
先在Buda工作區準備無secret的清單、未知項、撤回檢查表。可以要求：
只根據指定工具說明和管理員提供的非敏感配置整理接入清單。分開任務允許動作與實際賬號許可權，未知項不推斷。輸出access-inventory.csv、unknown-scopes.md、revocation-checklist.md。不讀取或列印金鑰，不連線新生產賬號，不嘗試修改、傳送或刪除。
主管確認業務範圍，管理員確認系統授權，執行者記錄受控驗收。角色可以由同一人承擔，但三個判斷不能混在一句“可以用了”裡。
不知道scope，還能先試讀嗎？
先用脫敏檔案副本驗證方法。正式賬號的許可權保持unknown，交管理員核實；不要把試讀成功升級成接入批准。
共用Agent，開一個新Session就夠了嗎？
如果只是分開討論，可以；如果要分開檔案、憑據或可作業系統，不夠。先核實際身份和資源許可權，必要時另設Agent及相應低許可權身份。
UI遮住了token，能放心執行任意Skill嗎？
不能由masked推出這個結論。閱讀Skill全文與來源，核它需要的工具和資料範圍；環境內程序可能讀取該Agent變數，避免把不需要的憑據放進去。
只要草稿，怎樣減少許可權？
從授權匯出開始，正式系統不接寫許可權；輸出放指定目錄。確需實時讀取時，先讓管理員選擇受限賬號和資源，再做受控驗證。
在Buda AI的Marketplace搜尋並安裝適用Skill，先核方法，再給許可權。最有用的接入清單不是列出Agent“能用多少工具”，而是讓每一種能力都有業務理由、實際範圍與撤回負責人。