一位信任的粉絲當上管理員。一位臨時的製作人拿到頻道權限。一個機器人拿到很大的授權範圍。一位離開的幫手，身分組還留著。幾個月後，沒有人說得出哪個帳號或哪個應用程式可以刪貼文、改身分組、用頻道的名義發文，或看私下的通報。這就是整個問題，而它一季花一個下午就處理得完。
Discord 的管理員權限，通常是一點一點變得危險的。一位受信任的粉絲當上管理員。一位臨時的製作人拿到頻道權限。一個機器人拿到很大的授權範圍，然後一位離開的幫手，身分組還留在那裡。幾個月後，沒有人說得出哪一個帳號或哪一個應用程式，可以刪貼文、改身分組、用頻道的名義發文，或者看到私下的通報。
小小的創作者團隊，靠一次每季的權限稽核就能把這個風險壓住。把每一個人、每一個身分組、每一條頻道例外和每一個連結的應用程式盤點出來，讓每一份授權都對應到一份現在還存在的工作。移除過期的權限、把日常管理和系統管理分開、指名復原負責人，然後用測試帳號驗收結果。平台的設定說明已經把個別的控制項講得夠清楚了；下面要做的，是把它們跨越人、應用程式、撤銷、復原和測試串成一件事。
創作者團隊常常是在時間壓力下給出權限的。管理員今晚就得擋掉洗版。製作人上線前得先排好一支影片。某個工具需要授權才能指派成員身分組。每一件事都站得住腳，而每一份授權往往就這樣誕生了：沒有負責人、沒有到期日、也沒有下次檢查的日期。
共用帳密會讓這四種漂移都更嚴重，因為平台分不出誰是誰。YouTube 明白建議用頻道權限取代共用密碼，讓每一位受邀的人能做的事情各自受限。Discord 則是用身分組、頻道例外和應用程式授權，而不是一個扁平的「管理員」開關。這些控制項只有在你把它們當成同一套系統來檢查、而不是四個各自獨立的畫面時，才真的有用。
最小權限的意思是：每一個人和每一個應用程式，只拿到目前這份工作所需要的最小一組能力，而且不會留得比這份工作更久。它不是不信任管理員。它給受信任的人更清楚的邊界，也把「一次失誤、一個被盜的帳號、一個一年沒人想起的工具」可能造成的損害關在一個小範圍裡。
對多主持人的節目來說，站在台前不等於自動需要系統管理權限。一位主持人可能負責發社群提問，另一位可能只讀粉絲精選，而製作人可能管上片但從來不需要看到私下的管理通報。權限對應的是職務，不是曝光度或資歷。
每一份特權授權都要能回答五件事：對象是誰（人、身分組、機器人還是 OAuth 應用程式）、它支援的現行工作是什麼、允許的確切能力和範圍、負責定期檢查它的人是誰，以及它必須被檢查或移除的日期。只要有一欄填不出來，這份授權就還不該留著。「我們一直都是這樣用的」不是一份工作說明。
不要一開始就動權限。先把現況記錄下來，你才有東西可以跟「應該長什麼樣」比對，也才有辦法把誤刪的東西還原回去。每一位有特權的人、每一個身分組、每一條頻道例外、每一個機器人、每一個 OAuth 應用程式和每一種復原方式，各一列。
Discord 的權限常見問題說明了身分組權限和頻道層級的例外設定如何互相作用，而這兩層都要檢查：伺服器身分組乾淨，不代表某個私下的通報頻道沒有一條舊的例外。連結的應用程式則要同時記下看得見的機器人帳號，以及它背後的那份授權。Discord 的 OAuth2 文件描述了授權範圍和授權流程；把當初要求了哪些範圍、是哪個社群安裝的、誰核准的，以及撤銷之後什麼會壞掉，都記下來。
也要把比較不明顯的路徑放進來，因為意外通常就藏在那裡：排程發文工具、數據分析產品、訂閱身分組同步器、Webhook 端點、共用工作機上還開著的瀏覽器登入階段、復原用的電子郵件帳號，以及由外包廠商持有的自動化。這份盤點不是在指控誰，它只是把「沒有人還講得出理由」的權限找出來。
拿每一位有特權的人，去對照他現在實際在做的工作，而且要問那份職務的負責人，不要只問持有權限的人本人。移除的動作要私下處理，而且要例行化：權限稽核不是公開的指控。告訴管理員，團隊會用同一個時程檢查每一個有特權的帳號，並且給他們一條路，可以回報那些他們其實還需要的權限。
有一條硬規則：在確認另一條「已經測試過」的復原路徑之前，絕對不要移除唯一的復原管理員。如果社群和唯一的復原信箱都在同一位創作者手上，先把這份控制權轉移或記錄下來，再去動任何一個一般身分組。
拿每一個身分組去對照那四種權限層級，並且用職務來命名，不要用地位。「管理員」比「核心圈」清楚，而「訂閱同步機器人」也比一個品牌化的暱稱清楚得多，尤其是當你正在快速讀一份事故時間軸的時候。
日常管理應該偏向可以回復的動作。管理員確實可能需要立刻隱藏一則有害的貼文或把某個帳號禁言，但更動擁有權、帳務或最上層權限，應該留在日常角色之外。
檢查完身分組層級的權限之後，再去檢查頻道的例外設定，特別留意管理員房間、通報佇列、付費會員空間、還沒發布的內容、贊助商素材，以及輪替班底裡專屬於某一個人的頻道。一個在公開討論區完全安全的身分組，可能因為一條被遺忘的例外，就把敏感材料露出去。
把每一個連結的應用程式當成另一位操作者：它的權限跟人一樣，需要一份工作、一位負責人和一條移除路徑。已經沒在用的應用程式要移除，不要只是把它的機器人帳號藏起來；只要平台和整合允許，就把授權範圍縮小。
如果某個應用程式負責同步付費身分組，在撤銷之前先定義好它的安全失效狀態。移除它可能只是讓未來的身分組更新停止，而現有身分組原封不動，所以在變更前後都要對一次成員權限，而不是靠客訴才發現有落差。
還有，不要為了省下診斷「到底少了哪個權限」的功夫，就直接給系統管理權。從那份寫下來的工作出發，只加上真正需要的那個窄窄的能力。如果某家廠商堅持要很大的權限，就把它記成一項風險、指名是誰接受了這項風險，並且把下次檢查的日期訂得比平常早。
每一季都用同一個順序，團隊有重大異動之後也跑一次。不要把所有關鍵變更塞進一場沒有檢查點、一路狂點的作業裡：當權限壞掉的時候，比較小的變更組合會讓原因好找、也好還原太多。
權限稽核遲早會揭露一個藏起來的相依性。管理員進不去通報佇列、排程貼文發不出去、訂閱機器人不再更新身分組。這時候只還原解決那個故障所需要的那一項能力，絕對不要把整組舊權限倒回去：整個身分組還原回去，等於把這次稽核作廢，而且會把那個相依性到底是什麼給蓋掉。
如果團隊把自己鎖在某個關鍵介面外面，就用那位事先測試過的復原負責人。不要叫粉絲在公開場合協助排錯，也不要叫他們傳含有私人帳號資料的截圖。如果是連結的應用程式壞了，先暫停自動化、保存不會洩漏粉絲祕密的日誌，並且在重新連上之前，先把受影響的訂閱或發布狀態對一次。
證據要和對外溝通分開。一個被盜的管理員帳號，不能證明那位管理員做了什麼壞事。先限制那個帳號、保存相關紀錄、私下聯絡本人，並且在事實和「確實需要對外說明」這兩件事都清楚之前，不要對社群指名道姓。
一份填完的試算表，不能證明權限真的照設定運作。用代表真實社群角色的帳號去測結果，而且正面和反面的行為都要驗：每個帳號做得到什麼，以及它現在應該再也做不到什麼。反面那一半，正是大家會跳過的那一半。
把稽核前後的數字都記下來：有特權的人數、等同系統管理員的帳號數、連結的應用程式數、移除掉的過期授權數、有時限的例外數，以及驗證失敗的案例數。數字變小不代表就比較好。真正有用的結果是：每一份還留著的授權，都有一份現行工作、一位負責人、一個檢查日期，和一次通過的測試。
今天就把社群的身分組清單和已連結應用程式清單打開。替每一位有特權的人和每一個應用程式建一列盤點資料，然後找出第一份「沒有現行工作或沒有負責人」的授權。
把那一份移除或縮小，但要先確認復原權限和測試帳號都準備好了再動手。接著把完整的檢查排進接下來七天內，並且在關掉這件事之前，先把下一季的稽核放進行事曆。永遠沒被排進行事曆的那次稽核，就是後來變成事故的那一次。