你已經決定哪些風險承受得起。但公司裡的數位員工，到現在還沒有一個自己的身分。
Day 14 那張清冊盤完之後，下一步呢？
你列出了公司裡在用的 AI，知道誰在用、用在哪、碰得到哪些資料。接下來要把它們收編。收編聽起來像是把它們掛到某個人底下，其實要做的相反：給它一個自己的身分。
需要工號的不是清冊上每一項，是會自己動手去做的那幾項。它們現在多半掛在某個員工的帳號底下。這不是誰便宜行事，是導入的時候借一個現成帳號最省事，後來也沒有人回頭收。
Day 6 講過，權限不是設計出來的，是繼承來的。當初 IT 開那個帳號，是為了讓採購流程自己跑完，所以連付款核准都給了它。當時把關的是流程接不接得起來，沒有人問它的權限該切到哪裡。
這裡有一個前置條件。agent 讀得到什麼，取決於你原本的權限設得多細。多數公司的雲端硬碟是一路「先開給大家再說」長出來的，部門資料夾全公司讀得到，離職同事的檔案沒人收。在人的時代，這種鬆散要有人真的去翻才會出事；交給一個不會累、會把整個資料夾翻過一遍的 agent，它就是放大器。工號要有用，底下那一層得先收乾淨。
AI 進來之後，這件事被放大一次。它用誰的身分做事，就接收誰的權限範圍。OWASP 今年的《代理式應用十大風險》（OWASP Top 10 for Agentic Applications 2026）把這種情況列成常見樣態的第一條：上游把任務交下去的時候沒有縮小範圍，常常只是圖方便，或架構上做不到，結果一個職責很窄的下游，拿到了完整的存取脈絡。同一份清單還點名一種更日常的：某個人開了一個 agent，它用的是那個人的身分，接著其他同事也開始用它，等於一群人共用了一個人的權限，而且沒有留下誰是誰。
比範圍變大更麻煩的是另一件事：沒有自己的身分，最小權限在技術上就不成立。OWASP 的原話是，缺少一個獨立、受治理的身分，agent 會處在一個歸屬落差（attribution gap）裡，讓真正的最小權限無法被執行。不是做得不夠好，是前提不存在：你沒辦法把權限縮到「這個角色需要的範圍」，因為系統裡根本沒有那個角色。
有了身分之後要做的事，同一份清單給了三件。用 agent 自己的憑證，而且是短效的；把它當成一個被管理的非人身分納管，跟人的帳號一樣有生命週期；權限綁在主體、資源、用途、期限這四件事上，閒置或異常就自動撤銷。微軟、AWS、Salesforce、Workday 都已經在自家的身分系統裡開了這一格，Google 也在往這個方向走。開一個獨立帳號本身不難，多數方案都做得到；難的是把它當成一個要被管理的身分：誰發、誰收、多久檢查一次。
至於有了身分之後該怎麼給權限，Kaggle 的 AI agent 課程白皮書提過一個好用的分法：只能讀、能擬稿但不能送出、和能真的動手。分界是它被允許對真實世界做什麼，副作用越大、越收不回來，要過的驗證就越嚴。那是下一層的題目，本篇先把身分這一層補起來。
多數公司第一次處理這件事，是當成 IT 的工單發下去的：幫 agent 開個權限。問題是開權限之前要先有一個對象，而多數情況下根本沒有這個對象。
這件事的後果不在資安那一欄。它碰得到的資料與系統，本來應該只有它工作用得到的那些。但這有個前提：得先知道「它」是誰。借來的身分不會自動縮小，因為那個範圍是照人給的，不是照任務給的。
所以你真正要決定的是歸屬。AI 做的事，算在公司名下，還是算在負責人用的員工名下？選前者，它就得有公司給的身分，跟人的帳號分開；選後者，你等於把公司的責任放在一個員工的帳號上，而那個人多半不知道自己扛了什麼。
這也是為什麼盤點排在這一步。清冊本身不解決任何問題，它只是讓你知道要替誰開身分。NIST 那份框架把清冊寫在治理功能裡，而它另外一份實作指引（Playbook）講得更直接：指定一個人或一個團隊負責維護，不是列一次就算。盤出來之後的動作不是禁，是收編：把已經在跑的那幾套，收成公司認得的用法。
同一份框架還有一條，是這件事的驗收標準：要有機制能夠取代、停用或關閉表現不如預期的 AI 系統，而重點在後半句，責任要被指派，而且被指派的人知道自己是那個人。
若是將盤點完的 agent 都收編，除了管控 AI 員工的身分，還有一個額外的好處。那些原本用個人帳號、用免費版在跑的，第一次進得了公司看得到的範圍。Day 13 說過，帳單暴增通常不是用量變多，是某一段流程沒設計好；但那要先看得到是誰在用。
iThome鐵人賽
看影片追技術