AI 代理身分、權限與稽核怎麼記？從企業帳號到 Android 動作

先建立看得懂的五欄任務紀錄

做 AI 代理身分、權限與稽核，先讓一筆紀錄回答：誰提出要求、誰實際行動、能碰哪些資源、這次核准了什麼，以及最後發生了什麼。以下是團隊可自行填寫的人工範例，不是產品內建的日誌格式或匯出功能，也不是已執行的測試結果。

假設專案成員林先生請文件助理代理 A 讀取指定工作文件，準備回覆草稿，但不寄出。可把這次請求標為 R-001，讀取與草稿準備分別標為 A-001、A-002。這些是自行約定的示例編號；若系統已有請求與動作識別碼，應保留它們供交叉查詢。

五欄是五組問題，不代表每組只能放一個值。發起者、代理執行身分與核准者可能不同；憑證驗證連線，授權限制資源，核准決定當次動作，結果則由實際證據支持。聊天中出現姓名，或持有 API 金鑰，都不足以替代這些關係。

如果文件已讀取，但草稿尚未產生，就分別記為「讀取成功」與「草稿未完成」，不要把整個任務標成成功。紀錄只需保留足以定位的文件參照、動作與結果，不必複製完整文件、私人訊息或秘密。敏感內容的存取與保留仍依組織政策處理。

選對企業代理身分與授權範圍

在 Microsoft Entra 的代理身分機制中，官方授權說明區分委派權限與應用程式權限。委派權限讓代理代表已登入的使用者，在使用者可用權限及已授予範圍內行動；僅由應用程式使用的權限則由管理員授予。員工在對話中提出要求，不代表已授予所有應用程式權限，也不代表每個後續寫入都獲得核准。

企業設定時，要從任務反推所需存取：只是讀取指定文件，就不應為方便而授予廣泛寫入或管理員角色。Azure 資源角色、目錄角色與 Microsoft Graph API 權限管理的是不同資源，應逐一核對。Entra 代理身分也有高權限角色與 API 權限限制，不能把一般應用程式的授權方式直接套用成代理必然可用。

可依「目標資源、所需操作、執行身分、授權方式」逐項確認。例如文件唯讀任務，不應因稍後可能準備郵件草稿，就提前增加寄送權限。若工作改為對外寄送，應另列動作、目標及核准要求；OAuth 同意授予的存取能力，不等於同意每一次實際寄送。

再記下誰負責這個代理、連線及授權。帳號所有者離職、任務結束或用途改變時，要能找到撤銷點；若組織要求到期或定期複查，也應保留相應日期。這套企業身分設計屬於 Microsoft Entra 的範圍。若要評估企業本地部署、手機權限與稽核需求，可閱讀企業 AI 代理安全：手機層級代理該如何在本地、權限與稽核之間落地。

分開蒐集身分事件與動作結果

Microsoft Entra 代理登入與稽核說明列出可用來關聯代理的 agentType、blueprintId 等資訊。代理藍圖活動顯示為應用程式事件，代理身分顯示為服務主體事件，代理使用者帳號則顯示為使用者事件。具備至少「報告讀取者」（Reports Reader）角色的人員，可在 Entra ID 的「監視與健康狀態」中開啟登入記錄，使用代理相關篩選條件查詢。

登入成功只能說明當時發生了身分驗證事件，不能證明指定文件已被讀取、草稿已產生或郵件已寄出。查核時，以請求編號、執行身分、目標資源與時間範圍關聯身分事件，再到業務應用程式查實際操作。若只有時間接近，卻沒有一致的身分或目標，不宜直接認定是同一項動作。

以 R-001 為例，先找代理 A 的相關登入，再核對 A-001 指向的文件存取結果，以及 A-002 的草稿參照。每一項結果都應說明證據來自哪個系統、何時取得。下游沒有證據時，保留「未確認」，不要因登入成功就填成草稿完成；查詢範圍不完整，也不能把找不到紀錄當成從未執行。

若使用 Microsoft Graph 查詢代理日誌，官方所述相關查詢使用 /beta；正式作業的保留期限、存取權與可用性仍要依組織實際政策確認。外部技能與插件可能擴大資源存取，可參考AI Agent 技能安全：為什麼手機 Agent 不能只靠安裝前掃描檢查能力來源與授權。若還引用已儲存記憶，則搭配AI 代理記憶投毒手機安全指南：Ask AI、推薦偏差與已儲存記憶稽核核對影響決策的內容。

成功、拒絕、待核准與部分失敗怎麼記

以下四筆仍是人工紀錄的建議範例。各筆都沿用行動者、憑證參照與範圍，再把「是否獲准」「是否嘗試」「實際結果」分開填寫，避免把一句成功或失敗遮住中間狀態。

待核准與拒絕不能混為一談。待核准表示仍有決定尚未完成；拒絕則應留下是哪個權限、工具設定或核准決定阻擋。核准後也不要立刻改成成功，還要看到執行嘗試與結果。若無法確認目標未變，就記為未確認，而不是為了填滿表格推斷。

部分失敗尤其需要拆開：讀取成功不代表寫入成功，工具回應逾時也不代表寫入沒有發生。應用程式可能已建立內容，但回傳沒有抵達；此時再執行一次，可能產生重複事件或訊息。先用已知目標、時間與內容查詢實際狀態，再記錄「已有結果」「確定未建立」或「仍不明」。仍不明時保留暫停狀態，由負責人決定下一步。

把同樣的問題用在手機任務

在 FoneClaw，這五組問題可以用來整理使用者自行填寫的手機任務紀錄。以「讀取目前電量與省電模式」為例，device_battery_status 只讀取狀態，不修改設定。先記錄誰提出請求、使用哪項工具、模型連線參照及實際核准設定，再核對是否回傳裝置狀態與取得時間。

工具的風險與預設核准標示，可協助理解操作；實際是否出現核准提示，仍由全域工具核准模式及個別工具覆寫設定決定。唯讀電量工具的預設為自動執行，不能因此推論所有工具都免核准，也不需要把沒有提示本身記成異常。FoneClaw 功能頁可供查看支援的手機動作。

若任務改為透過 calendar_create_event 建立行事曆事件，就屬於會寫入目的地的動作。可用一個明確的建議要求：「在已確認的日期，上午 10 點到 10 點 30 分建立專案討論，提前 10 分鐘提醒。」日期、起訖時間、提醒或目標行事曆仍有缺漏時，先補齊，不讓模型猜測。使用者若未指定行事曆，記錄實際使用的目的地即可，不必虛構曾選定某個帳號。

執行後以工具回傳的 actualStart、actualEnd 核對實際建立時間，再到行事曆比對標題、日期、起訖、提醒及所屬行事曆。全天事件也要確認日期範圍；其結束邊界是次日的本地午夜，不應誤讀成多占一天。Android 系統權限、工具啟用、動作核准與模型供應商憑證是不同控制。線上模型可能處理所提供的任務脈絡，手機動作紀錄不能代替供應商資料處理政策；這裡使用的是人工核對方法，不是企業身分整合或不可竄改匯出。

確認拒絕有效，收回不再需要的權限

可安排一項無害的驗證：記下原設定，暫停非必要的電量讀取工具，再提出相同的唯讀請求。預期觀察是該工具受停用控制阻擋，沒有產生新的工具讀取結果；舊回覆或模型一般說明不能當成新查詢成功。把實際提示、時間及工具狀態填入人工紀錄，測完依原計畫保留停用或恢復設定。這是建議檢查，不是已觀察到的測試結果。

收回未來存取，不等於撤回已完成的寫入。停用行事曆工具後，先前建立的事件仍需到行事曆查看；若確實需要修改或刪除，另列目標與動作，再依權限及核准政策處理。結果不明時，更不能用「權限已收回」推論事件不存在。先核對目的地，再決定是否重試，並保留兩次嘗試之間的關係。

定期由負責人檢查不再使用的代理身分、連線、授權及核准覆寫。可能暴露的憑證應依供應商與組織程序處理，紀錄只保留參照，不保存秘密本身。企業端收回授權後，也應依適用機制確認後續存取狀態；不要只因設定已儲存，就假設所有既有存取立即失效。

最後限制誰能讀取紀錄，按自身政策安排保留與刪除，並標明尚未補齊的證據。可追查的紀錄應回答兩件事：代理當時被允許做什麼，以及目標系統最後實際發生了什麼。人工表格與手機對話可協助核對，但不能單憑它們宣稱證據不可竄改或已符合特定認證。