AI Agent 權限最小化

01解決的工作問題

企業導入 AI Agent 後，很快會遇到跟「好不好用」不同層次的問題：這個 Agent 有沒有權力做它正在做的事。Agent 的技術能力通常照抄人的帳號權限裝上——能讀 Email 就順便給寄信權限，能查 CRM 就順便給寫入權限，圖個方便。但「技術上能存取」跟「組織上被授權執行」是兩回事：人在按下寄送、刪除、核准前會猶豫，Agent 不會，它照指令執行到底，一次可能做幾十件事，出事很難回溯是誰批准的。多數團隊問的是「Agent 能不能做 X」，沒人問過「該不該做、做錯了誰負責」。這篇要處理這個落差：把 Agent 會碰到的每個系統拆成 Read／Create／Edit／Send／Delete／Approve 六種動作，依風險（可逆與否、對外可見與否、有無金額或法律後果）逐格分成可自動執行、需人確認、禁止 AI 執行三級，不用「系統能不能給 Agent 用」這種粗顆粒度的是非題打發。

02什麼時候用、什麼時候別用

什麼情況下該用這一套

• 已經或計畫讓 AI Agent 直接操作 Email、Drive、Calendar、CRM、ERP 或內部 API，不只是聊天問答。
• Agent 的任務範圍會持續擴張（先讀資料，之後要寫、要送），需要一份跟著擴張同步更新的授權基準。
• 出事故時需要說得清楚「這一步是誰批的」，而不是事後各自猜測。

什麼情況下別用

Agent 只做純讀取、不寫不送的場景

如果 Agent 完全沒有 Create／Edit／Send／Delete／Approve 的能力，權限矩陣會做出六欄只有一欄有內容的空表，先把範圍確認清楚再決定要不要做這一步。

還沒決定要不要真的導入 Agent、只是評估階段

這份矩陣是給「即將上線」的 Agent 用的授權基準，評估階段做出來的分級用不到幾個月就要重做一次，先等範圍定了再做。

取代資安或法遵既有的存取控制審查

這份矩陣解決的是「AI Agent 該不該做」，不是公司整體的資安政策或法遵要求，兩者要對照，不能互相取代。

想要一次做完、之後不再管

系統會加新功能、Agent 的任務會擴張，矩陣沒有維護機制形同沒做。

誰會用到

資訊／資安

你通常是執行這份盤點的人，但最終等級的裁定不該你一個人拍板——尤其 Approve 類動作，要拉相關部門主管一起定。

主管

你要負責的是「誰有權把某個動作定為可自動執行」這件事本身的授權，以及矩陣定稿後放在哪裡、誰負責每季複查。

工程師／研發

你最容易犯的錯是把限制只寫在系統指令裡就交差。凡是「禁止」等級的動作，要確認對應的 API 金鑰或 OAuth scope 也真的拿掉了權限。

所屬工作情境

04完整步驟圖的文字版，逐步展開

一句話版（快速回顧）

1. 列出 Agent 會碰到的每個系統，寫下現在實際用的帳號與存取範圍。
2. 請 AI 針對每個系統，依 Read／Create／Edit／Send／Delete／Approve 六種動作逐格列出可能行為與風險。
3. 依不可逆性、對外可見性、金額或法律後果三個標準，為每一格初步分成三級。
4. 請 AI 整理成權限矩陣草稿，並給出對應的平台技術設定建議。
5. 有權限的人逐格複審，特別裁定 Send／Delete／Approve，刪掉 AI 放寬的等級。
6. 寫進 Agent 平台的角色／scope 設定，先小範圍 pilot 試跑再定案。

完整版（每一步誰做、產出什麼）

05開始前要準備什麼標「必要」的沒備齊就先別開始

Agent 會碰到的系統清單必要

Email、Drive、Calendar、CRM、ERP、內部 API、知識庫……列出目前已經串接與規劃中要串接的，不要只列現在用到的。

每個系統目前的存取範圍必要

Agent 現在實際上用哪個帳號、哪一組權限在操作，很多時候是直接沿用某個人的帳號，這本身就是風險來源。

過去出過包或差點出包的案例可選

哪一次自動化或人工作業出過錯、造成什麼後果，這些是分級時最好的參考基準。

誰有權核准「可自動執行」這一級必要

分級本身也需要授權——不能是寫 Prompt 的工程師自己說了算。

公司既有的資安／法遵存取規範（如有）可選

權限矩陣要跟既有規範對照，不能互相矛盾。

權限矩陣定案後的存放與維護位置必要

決定放在哪裡、誰負責更新，不然做完就變成一份沒人看的文件。

餵進去的東西要長這樣

系統清單（含既有存取範圍與帳號來源）＋過去出包案例（如有）＋公司既有資安／法遵存取規範（如有）。

• 系統清單要包含 Agent 已經串接與規劃要串接的，不要只列現在用到的。
• 每個系統要寫明現在用哪個帳號／哪一組權限在操作，共用帳號要特別標注。
• 有過去出包或差點出包的案例要附上，是分級最好的參考基準。
• 涉及客戶個資或內部機密的系統說明，上傳前先代稱或去識別化。

系統清單：
1. Email——公司 Gmail 共用帳號（原本客服團隊使用，現在要給 Agent 用同一個帳號收發信）
2. Google Drive——專案共用資料夾（含合約、報價單、客戶資料）
3. CRM（HubSpot）——客戶聯絡資訊與商機紀錄，目前用一組管理員 API 金鑰串接
4. 內部報銷系統——透過內部 API 串接，可查詢報銷單狀態、可提交新的報銷申請

過去出包案例：曾有同仁誤用共用 Email 帳號把內部討論串轉寄給客戶，事後靠信箱紀錄才釐清是誰轉寄的。

公司既有規範：對外發送郵件需經主管確認；金額超過 5000 元報銷需二級主管核准；客戶個資批次匯出需資安審核。

06Prompt（快速／完整／進階）

A 快速版貼上就能用；B 完整實戰版把角色、限制、步驟、輸出格式與驗收標準寫足；C 進階版是拿去建 GPT／Skill／Agent 的系統指令。三種都附可替換變數、使用範例、預期輸出與人工確認點。

以下是我們的 AI Agent 會碰到的系統清單，請針對每一個系統，依 Read（讀取）／Create（新增）／Edit（修改）／Send（發送／對外）／Delete（刪除）／Approve（核准）六種動作，具體列出這個 Agent 可能會做的事，並說明如果這個動作做錯了會有什麼後果（是否可逆、是否對外可見、是否涉及金額或法律責任），最後給一個建議等級（可自動執行／執行前需人確認／禁止 AI 執行），並說明理由。找不到某個系統會用到某個動作時，直接寫「不適用」，不要硬湊。
系統清單：{貼上}

系統清單：
1. Email——公司 Gmail 共用帳號（原本客服團隊在用，現在要給 Agent 用同一個帳號收發信）
2. Google Drive——專案共用資料夾（含合約、報價單、客戶資料）
3. CRM（HubSpot）——客戶聯絡資訊與商機紀錄，目前用一組管理員 API 金鑰串接
4. 內部報銷系統——透過內部 API 串接，可查詢報銷單狀態、可提交新的報銷申請

【一、Email（公司 Gmail 共用帳號）】
- Read：讀取信件內容與附件。風險：信箱內混有客戶個資與內部討論，批次讀取等於批次接觸個資，可逆（讀取本身不會改變原信），但要留意後續會不會外流。建議等級：可自動執行（讀取範圍要限縮在處理任務需要的信件，不能整個信箱通讀）。
- Create：草擬回信內容存成草稿，尚未送出。可逆，只在自己帳號內。建議等級：可自動執行。
- Edit：修改既有草稿或信件標籤／歸檔。可逆。建議等級：可自動執行。
- Send：以公司帳號對外發送郵件。風險：一旦送出無法收回，收件人可能是客戶或廠商，內容出錯會直接影響公司對外形象，甚至構成書面承諾。建議等級：執行前需人確認——即使有模板，第一次針對某類信件自動化時也要人按下最後送出。
- Delete：刪除信件。風險：不可逆（除非有備份機制），可能刪掉未來稽核需要的往來紀錄。建議等級：執行前需人確認；若信件已過公司保存年限的例行清理，可考慮改為可自動執行，但要另立規則。
- Approve：Email 情境通常不涉及核准動作。不適用。

【二、內部報銷系統（API 串接）】
- Read：查詢報銷單狀態、金額、審核進度。可逆，內部使用。建議等級：可自動執行。
- Create：依據收據資訊建立新的報銷申請草稿，尚未送出審核。可逆。建議等級：可自動執行。
- Edit：修改尚未送審的報銷單內容（品項、金額、說明）。可逆。建議等級：可自動執行，但金額欄位建議加自動比對收據金額的檢查。
- Send：這裡等同「送出審核」，一旦送出會進入主管的審核流程，占用他人時間並產生紀錄。風險中等，不算不可逆（可撤回）但會產生組織內部的追蹤成本。建議等級：執行前需人確認。
- Delete：刪除已建立的報銷單。風險：若單據已進入審核流程中刪除，可能造成對帳缺口。建議等級：禁止 AI 執行——刪單一律由人操作，並留下刪除紀錄。
- Approve：核准報銷金額是否發放。風險：直接涉及公司資金動用，且核准人依公司規定通常要有特定職級。建議等級：禁止 AI 執行——這是制度上明訂「誰能核准」的動作，不能因為 Agent 技術上做得到就下放。

【三、Google Drive】與【四、CRM】篇幅所限先給結論：Drive 的 Read／Create／Edit 多數可自動，Send（分享連結給外部）與 Delete 需人確認；CRM 的 Read／Create／Edit 多數可自動，但批次匯出聯絡人清單（等同大量 Read＋Send 給外部工具）要視為高風險動作，建議等級需人確認，理由與細項之後可再個別展開。

【建議等級只是初稿】以上等級是依「不可逆性、對外可見性、金額或法律後果」推論出的建議，最終分級要由公司內有權限的人複審裁定，尤其是標示「需確認」與「禁止」的項目，AI 不能自己降級。

以下是各系統逐動作的風險說明與建議分級初稿，請整理成一份正式的權限矩陣，並做以下工作：

1.【整理成矩陣】用表格呈現：系統 × 六種動作（Read／Create／Edit／Send／Delete／Approve），每一格填：建議等級（可自動執行／執行前需人確認／禁止 AI 執行）、一句話理由，若「不適用」請明寫不適用。
2.【標出所有不可逆或對外可見的格子】不管建議初稿寫的等級是什麼，只要動作滿足「做錯無法撤銷」或「結果會被系統外的人看到」任一條件，一律至少標為「執行前需人確認」，不能標可自動執行，並在矩陣中用★標出這些格子方便人工複審時優先看。
3.【技術設定對照】針對每一個「執行前需人確認」與「禁止 AI 執行」的格子，給出對應的技術實作建議：這個限制應該設在哪一層（Agent 平台的角色／scope 設定、API 金鑰權限、還是流程上插入人工審批步驟），並說明為什麼設在那一層比較可靠而不是只靠系統指令要求 AI「記得先問」。
4.【找出矩陣的缺口】列出「初稿裡沒有說清楚、你必須自己決定」的地方——例如某動作的風險等級取決於金額大小、對象是內部還是外部，這些是矩陣還需要補的分岔條件。
5.【與既有規範對照】若我有提供公司既有的資安或法遵存取規範，檢查矩陣有沒有跟既有規範衝突的地方，衝突處直接標出來，不要自己解讀該以哪個為準。

規則：
- 不得為了「讓矩陣好看」而把等級往「可自動執行」的方向靠。有疑慮一律標高一級的限制，交給人在複審時降級，而不是反過來。
- 不得假設某個動作「應該不會真的被 Agent 用到」而省略這一格，六個動作每一格都要填。
- Approve 類動作（核准、放行金額、核准發送）除非明確說明有其他補償機制，否則一律建議禁止 AI 執行。

建議分級初稿：{貼上}｜公司既有資安／法遵規範（如有）：{貼上}

（貼上 A 版產出的 Email 與報銷系統建議分級初稿，並附上公司資安規範：「對外發送郵件需經主管確認」「金額超過 5000 元報銷需二級主管核准」）

【權限矩陣：Email（公司 Gmail 共用帳號）】
| 動作 | 建議等級 | 理由 |
|---|---|---|
| Read | 可自動執行 | 範圍限縮在任務相關信件，可逆 |
| Create | 可自動執行 | 僅存為草稿，未送出 |
| Edit | 可自動執行 | 僅修改草稿或標籤 |
| Send★ | 執行前需人確認 | 對外可見且不可撤回，且已知公司規範「對外發送需經主管確認」，與本矩陣一致 |
| Delete★ | 執行前需人確認 | 不可逆，可能影響稽核紀錄 |
| Approve | 不適用 | Email 情境無核准動作 |

【權限矩陣：內部報銷系統】
| 動作 | 建議等級 | 理由 |
|---|---|---|
| Read | 可自動執行 | 內部查詢，可逆 |
| Create | 可自動執行 | 僅建立草稿 |
| Edit | 可自動執行 | 尚未送審可修改，建議加自動比對收據金額 |
| Send★ | 執行前需人確認 | 送出會占用他人審核時間，產生組織內部追蹤成本 |
| Delete★ | 禁止 AI 執行 | 已進入審核流程後刪除會造成對帳缺口，且不可逆 |
| Approve★ | 禁止 AI 執行 | 涉及資金動用，且與公司規範「金額超過 5000 元報銷需二級主管核准」直接相關——核准權限本身有職級限制，Agent 不能替代 |

【技術設定對照】
- Email 的 Send：不要只在系統指令寫「送出前先問我」，因為 Agent 仍握有 Send 的 API 權限，一旦指令被繞過（例如被誘導）就直接送出了。應該在平台層把這個 Gmail 帳號的 OAuth scope 限縮成不含 gmail.send，只給 gmail.compose，物理上做不到直接送出。
- 報銷系統的 Delete 與 Approve：應該在 API 金鑰層就不給這兩個操作的權限，而不是靠系統指令禁止——金鑰沒有這個 scope，Agent 技術上就做不到，比「教它不要做」可靠。

【矩陣缺口】
- Email 的 Send 等級可能因收件對象而不同：回覆內部同事與發信給客戶風險不同，初稿沒有細分，建議依「收件人是否為 @公司網域」再拆一格。
- 報銷系統的 Edit 在金額差異超過原收據多少百分比以上時，風險可能上升到需確認，初稿沒有這個分岔條件。

【與既有規範對照】
- Email 的 Send＝執行前需人確認，與公司規範「對外發送郵件需經主管確認」一致，無衝突。
- 報銷系統的 Approve＝禁止 AI 執行，與「金額超過 5000 元報銷需二級主管核准」看似一致，但規範只講了「超過 5000 元」這個條件，5000 元以下由 AI 核准是否可行，規範沒有講清楚，這是需要你去問法遵或財務的缺口，不是 AI 能自行判斷的。

請把以下定稿的 AI Agent 權限矩陣，寫成一份可以直接用來建立「Agent 權限盤點助手」的系統指令。

【系統指令要包含】
1. 角色與任務：協助同仁在導入新的 Agent 任務或串接新系統前，依權限矩陣的方法完成盤點，不能跳過任何一格直接下結論。
2. 六動作定義：完整列出 Read／Create／Edit／Send／Delete／Approve 各自的定義與判斷原則（不可逆性、對外可見性、金額或法律後果）。
3. 既有權限矩陣全文（照我提供的，不得增刪既有系統的分級，只能針對新系統／新動作提出建議分級）。
4. 分級規則：可自動執行／執行前需人確認／禁止 AI 執行三級的判斷標準，且明訂「有疑慮一律往限制嚴格的方向標」。
5. 硬限制——以下情況一律建議「禁止 AI 執行」，不得因為使用者說「這次應該沒關係」而放寬：
   - Approve 類動作（核准金額、核准發送、核准放行）
   - 明確不可逆且無法在事後稽核還原的 Delete 動作
   - 涉及對外發送且過去沒有先例可循的 Send 動作
6. 輸出格式：新系統／新動作的建議矩陣 ＋ 判斷理由 ＋ 技術設定建議 ＋ 需要人複審裁定的項目清單（不得為空，至少要列出涉及 Send／Delete／Approve 的項目）。
7. 遇到使用者要求「幫我把這個標成可自動，因為很趕」時，一律先說明風險，並要求使用者說明是誰核准了這個例外，寫進紀錄，不得直接照做。

【另外請給我】
(a) 一份「使用說明」，給第一次要串接新系統的同事看，含三個好例子與三個壞例子。
(b) 一份「維護說明」：矩陣要更新時改哪裡、多久複查一次、新系統上線時的標準流程是什麼、誰負責。

定稿權限矩陣：{貼上}｜公司既有資安／法遵規範：{貼上}

（貼上定稿矩陣：涵蓋 Email、Drive、CRM、報銷系統四個系統的六動作分級；並附資安規範：「對外發送需主管確認」「金額超過 5000 元報銷需二級主管核准」「客戶個資批次匯出需資安審核」）

【Agent 權限盤點助手 系統指令】

一、你的角色
你協助同仁在導入新的 Agent 任務或串接新系統前，完成權限盤點。你不做技術串接，也不核准任何分級，你只協助判斷與整理。

二、六動作定義
Read（讀取）／Create（新增）／Edit（修改既有內容）／Send（發送或使內容對外可見）／Delete（刪除，含撤回、撤銷、作廢）／Approve（核准、放行、批准）。
判斷原則：這個動作若做錯，是否可逆？結果會不會被系統外的人看到？是否涉及金額或法律責任？

三、既有權限矩陣
（照錄定稿全文：Email、Drive、CRM、報銷系統四張表）

四、分級規則
可自動執行：可逆、內部可見、不涉金額或法律責任。
執行前需人確認：滿足下列任一即為此級——不可逆、對外可見、涉及金額或法律責任，但已有明確的確認流程可插入。
禁止 AI 執行：Approve 類動作；無法在事後稽核還原的 Delete；沒有先例可循的對外 Send。
有疑慮一律標較嚴格的一級，不得自行放寬。

五、一律建議禁止、不得因使用者說明而放寬的情況
1. Approve 類動作。
2. 明確不可逆且無法事後稽核還原的 Delete。
3. 涉及對外發送且過去沒有先例可循的 Send。
使用者要求「這次先標可自動，因為很趕」時，先說明風險，並要求寫下核准例外的人是誰，記錄下來，不得直接照做。

六、輸出格式
【新系統／新動作建議矩陣】
【判斷理由】
【技術設定建議】設在平台角色／scope／API 金鑰層還是流程審批層
【需要人複審裁定的項目】不得為空，至少列出涉及 Send／Delete／Approve 的項目

──────────

【使用說明（給第一次串接新系統的同事）】

這個助手做什麼：幫你依權限矩陣的方法，把新系統／新 Agent 任務拆成六動作並給建議分級。
這個助手不做什麼：幫你決定要不要導入這個 Agent、幫你核准分級、幫你寫技術串接程式碼。

好例子：
1.「我們要把 Agent 接到公司的 Slack，幫忙整理討論串重點」——附上 Slack 的功能範圍，請助手先做六動作盤點。
2.「Agent 現在要能幫忙修改 CRM 裡的商機金額欄位」——這是新增的 Edit 能力，請助手針對這一格重新評估。
3.「想串接一個可以自動叫外送／訂會議室的 API」——附上 API 文件，請助手判斷 Create／Send 兩個動作的等級。

壞例子：
1.「幫我把這個系統整個標可自動，我們趕時間」——助手會先說明風險，不會因為趕時間直接標可自動。
2.「這個動作技術上做不到吧，應該不用管」——權限盤點看的是「設計上該不該給」，不是「現在技術上做不做得到」，兩者要分開評估。
3.「Approve 那格幫我想辦法標成需確認就好，不要禁止」——硬限制不因使用者要求而放寬，這類要求要走例外記錄流程，不是改助手的判斷。

【維護說明】
- 新系統串接前，一律先跑一次這份盤點，不得先上線再補。
- 每季檢查一次：抽三個「執行前需人確認」的項目，核對 Agent 平台實際設定是否與矩陣一致。
- 矩陣更新只改第三節既有權限矩陣內容，其餘（六動作定義、分級規則、硬限制）不輕易改動。
- 負責人：〔填寫〕。更新後在共用位置註明版本與日期，並通知所有使用這份矩陣的團隊。

07產出應該長什麼樣拿到的東西要長這樣

一份系統 × 六動作的權限矩陣表，每格含建議等級＋理由＋技術設定建議，外加待複審清單與矩陣缺口清單。

完成品：同一個系統的兩種盤點：只設「能不能碰」跟拆到六個動作，差在哪

【只設「能不能碰這個系統」】
盤點結果（節錄）：
「報銷系統：Agent 可以存取，用於協助同仁處理報銷相關事務。」

→ 看起來定案了。問題是：
→「可以存取」涵蓋了 Read 到 Approve 六種完全不同風險等級的動作，等於把查詢進度跟核准放款畫上等號。
→ 技術團隊串接時通常會圖方便，直接給一組功能完整的 API 權限，因為文件上沒寫清楚要限縮到哪幾個動作。
→ 沒有任何一格可以拿去跟公司「金額超過 5000 元報銷需二級主管核准」的規範對照，因為盤點結果裡根本沒有「核准」這個動作被單獨列出來。

【拆到六動作層級】
盤點結果（節錄）：
「報銷系統：
- Read：可自動執行——查詢進度，可逆，內部使用。
- Create：可自動執行——僅建立草稿，未送審。
- Edit：可自動執行（金額欄位建議加自動比對收據）。
- Send（送審）：執行前需人確認——會占用主管審核時間。
- Delete：禁止 AI 執行——已送審後刪除會造成對帳缺口，不可逆。
- Approve：禁止 AI 執行——涉及資金動用，且公司規定核准需二級主管職級，與 Agent 技術上做不做得到無關。」

→ 每一格都可以單獨設定技術限制：Approve 與 Delete 的權限直接在 API 金鑰層拿掉，Agent 物理上做不到，不是靠「系統指令說不要」。
→ Send 一格可以對照公司規範，確認目前的「執行前需人確認」跟「對外發送需主管確認」這類既有規定是否一致。
→ 之後系統加新功能（例如加了「批次核准」這個新按鈕）時，只需要針對新增的動作重新盤點，不用整個系統重新評估一次。

【差別在哪】
第一種問的是「這個系統 Agent 能不能用」，第二種問的是「這個系統裡的哪一個動作 Agent 能做、哪一個不能」。前者是二選一，後者才是真正的最小權限。

| 系統 | 動作 | 建議等級 | 理由 |
|---|---|---|---|
| Email | Read | 可自動執行 | 範圍限縮，可逆 |
| Email | Send | 執行前需人確認 | 對外可見且不可撤回 |
| Email | Delete | 執行前需人確認 | 不可逆，影響稽核紀錄 |
| 報銷系統 | Approve | 禁止 AI 執行 | 涉及資金動用，公司規定核准需特定職級 |
| 報銷系統 | Delete | 禁止 AI 執行 | 已送審後刪除會造成對帳缺口 |

【待複審清單】Email-Send、Email-Delete、報銷系統-Send（共 3 項）
【矩陣缺口】Email-Send 的風險應依收件人是否為公司網域再拆一格；報銷系統-Edit 在金額差異超過原收據一定比例時風險應上升。

08工具怎麼挑

這幾支都做得到——差別在你手上有哪一支、資料能不能外流。標「起手」的是不知道從哪支開始時的建議，不是限定。

09會卡住與會做錯的地方

會卡住的地方（流程困難點）

把風險等級放太寬

AI 為了效率，傾向把「有模板可循」的動作直接標可自動，連 Send 都放進去，人沒有逐格核對就照單全收。

唯讀被當成零風險

批次讀取 CRM 整批客戶名單、匯出 Email 清單，本身就是資料外流風險，不是「只是 Read」就沒事。

矩陣跟平台設定對不起來

文件寫「需確認」，但 Agent 平台實際的權限設定是自動執行，出事時才發現兩邊沒同步。

用角色代替動作分級

只設定 Agent 能不能碰某個系統，沒有細到哪個動作能自動、哪個要禁止，等於沒做最小化。

會做錯的地方（常見失敗方式）

其他注意事項

• AI 給的建議等級只是初稿，直接採用而不複審，常見結果是 Send 被整批標成可自動執行。
• 限制只寫在系統指令裡，遇到提示注入或內容誘導就可能被繞過，真正要靠平台層拿掉權限。
• 矩陣做完就不再更新，系統加新功能或 Agent 任務擴張時沒有重新盤點。

10人工把關與安全限制

AI／Agent／Tool 介入在哪幾步

這幾關不下放

動作分級的最終裁定

AI 只能給建議等級，可自動／需確認／禁止的最終裁定一定由人做，而且要是有權限的人，不是寫 Prompt 的工程師自己定。

Send／Delete／Approve 三種高風險動作

這三種動作不可逆或對外可見的機率最高，複審時要逐格看，不能整批放行。

矩陣與平台實際設定的一致性

文件定案後要有人去平台上核對權限設定跟文件寫的是否一致，這一步最常被跳過。

pilot 期間的異常

小範圍試跑時 Agent 做出矩陣沒預期到的動作，要由人判斷是補進矩陣還是收回權限。

定期複查的負責人與頻率

系統會加新功能、Agent 任務會擴張，由人指定誰負責、多久複查一次。

安全與權限限制

矩陣內容本身就是機密

權限矩陣詳細寫出公司哪些系統、哪些動作有弱點或還沒設防，外流等於給攻擊者一份地圖，存放與分享範圍要限制。

API 金鑰與 OAuth scope 是真正的防線

系統指令層的限制可能被提示注入繞過，凡是「禁止」等級的動作，務必確認對應的金鑰／帳號權限也拿掉了，不是只改文件。

共用帳號是常見的破口

Agent 沿用某人的個人或部門共用帳號時，出事很難追責任是誰的操作，盡量申請 Agent 專屬帳號，權限矩陣才對應得上真正的存取來源。

pilot 階段的紀錄要保留

小範圍試跑期間 Agent 實際做了什麼動作要留存紀錄，是之後調整矩陣與出事追查的依據。

跟既有資安／法遵規範的衝突要往嚴格的一邊走

矩陣與公司既有規範若有出入，不能自行解讀該以哪個為準，要送資安或法遵單位確認。

11Checklist 與驗收標準

做的時候逐項打勾

• 每個系統的六種動作都逐格分級，沒有用系統層級的是非題打發。
• 不可逆或對外可見的動作，等級不低於「執行前需人確認」。
• Send／Delete／Approve 三類由有權限的人逐格複審。
• 高風險限制設在平台角色／scope／API 金鑰層，不只寫在系統指令裡。
• 矩陣定稿後已核對平台實際權限設定是否一致。
• 已指定負責人與每季複查的頻率。

做完了才檢查：全部成立才算完成

1. Agent 會碰到的每個系統都拆成六種動作逐格分級，沒有用「能不能存取」這種系統層級的是非題打發。
2. 每一格的等級都附理由，凡不可逆或對外可見的動作，等級不低於「執行前需人確認」。
3. Send／Delete／Approve 三類逐格由有權限的人複審裁定，不是 AI 建議就直接採用。
4. 高風險動作的限制設在平台角色／scope／API 金鑰層，不是只寫在系統指令裡。
5. 矩陣定稿後已核對 Agent 平台實際權限設定是否一致。
6. 已完成小範圍 pilot 試跑，並記錄 Agent 實際觸發到哪些格子。
7. 矩陣已跟公司既有資安／法遵規範對照，衝突處已送相關單位確認。
8. 已指定負責人與每季複查的頻率。

12實際案例

13相關方法與下一步

可直接使用RELATED PROMPTS