端點權限只是第一道門
許多企業 API 從角色型存取控制開始：管理者可以呼叫管理端點，業務人員可以讀取客戶，客服可以更新案件。這種設計容易理解，也適合快速建立基本防線，但它回答的只是「這個身分能不能執行這類動作」。真正困難的問題通常是：他能讀取哪些客戶、修改哪個部門的案件、下載哪個租戶的附件，以及在訂單進入鎖定狀態後是否仍可變更。
因此，授權模型至少要同時描述主體、動作、資源與情境。主體不只包含使用者與角色，也可能包含服務帳號、所屬租戶、部門及代理關係；資源要有租戶、擁有者、分類與狀態等屬性；情境則可能包含請求來源、驗證強度、委派範圍與操作時間。工程團隊應先寫出具體規則，例如「北區業務可讀取北區客戶，但只有案件負責人或主管能修改聯絡資料」，再決定使用角色型、屬性型或關係型模型。不要先選授權產品，再勉強讓業務規則配合工具。
把粗粒度與細粒度檢查分層
實務上，單一模型很難處理所有層次。API Gateway 適合驗證權杖、受眾、簽章與粗粒度 scope；應用程式服務適合判斷業務動作；資料存取層則最接近真正的資料範圍。分層並不表示同一條規則要複製三次，而是每一層只負責它能可靠判斷的部分。Gateway 可以拒絕沒有 orders.read 的請求，但不能只靠路徑規則判斷呼叫者是否有權讀取某一張訂單。
每個受保護的操作都應建立一致的授權輸入與結果。輸入包含主體、動作、資源屬性與必要情境；結果除了允許或拒絕，也可回傳資料過濾條件或欄位遮罩。常見的責任分工如下：
- 身分層：確認誰正在呼叫、權杖是否有效，以及此次委派允許哪些用途。
- 服務層：判斷 create、approve、export 等業務動作，避免把所有行為簡化成讀取與寫入。
- 資料層：強制套用 tenant_id、部門、擁有者或可見性條件，防止漏加查詢條件。
- 回應層：依權限移除薪資、成本、個資或內部備註等敏感欄位。
資料範圍必須進入查詢，而不是查完再過濾
最危險的實作之一，是先用 ID 取得資料，再於程式碼中檢查使用者是否可以查看。只要某個端點、批次匯出或背景工作忘記檢查，就可能形成越權存取。較穩健的方式是把授權條件直接合併到資料查詢，例如同時以 resource_id 與 tenant_id 查找，或由共用 repository 接受授權範圍並產生查詢。找不到與無權存取通常應回傳相同的外部結果，避免透過錯誤訊息探測其他租戶的資源是否存在。
列表查詢比單筆查詢更能暴露模型缺陷。授權服務若只能回答某一筆資料能否讀取，應用程式可能需要逐筆呼叫，產生延遲與一致性問題。設計時應確認政策能否轉換成 SQL 條件、搜尋引擎 filter 或預先計算的關係集合。若規則無法安全下推，應限制候選資料集並採批次授權，而不是先載入大量資料再於記憶體中刪除。分頁也必須在套用權限後進行，否則筆數、排序與空頁可能洩漏不可見資料的輪廓。
AI 與 RAG 系統也遵循相同原則。文件權限必須在檢索階段套用，而非等模型產生答案後才遮蔽文字。向量索引需保存租戶、文件分類、群組與來源系統 ACL 等中繼資料，並讓檢索查詢帶入使用者的有效範圍。若來源權限發生變更，索引與授權快取也要有明確的失效機制，否則 AI 助理可能持續引用已被撤銷的內容。
政策、快取與稽核要一起設計
集中式政策引擎有助於統一規則與稽核，但每次 API 呼叫都遠端詢問也會增加延遲與可用性依賴。適合集中管理、分散執行，或針對穩定判斷做短期快取；但快取鍵必須包含主體、動作、資源與政策版本，不能只依使用者角色。高風險操作如付款核准、權限變更與大量匯出，通常應採較即時的決策並在授權服務不可用時拒絕執行。低風險讀取可依業務需求選擇短暫快取，但要明確定義撤權多久內必須生效。
稽核紀錄不能只寫下 HTTP 狀態碼。至少要能回答誰以什麼身分、對哪個資源、嘗試什麼動作、套用了哪個政策版本，以及允許或拒絕的主要理由。紀錄應使用穩定的規則識別碼，避免保存不必要的敏感內容。對批次與服務對服務呼叫，還要保留原始使用者、委派鏈與追蹤識別碼，否則事件發生後只能看到某個後端服務曾經存取資料，卻無法還原業務來源。
導入時不必一次重寫所有權限。可以先盤點高風險資源與目前散落的判斷，建立共用授權介面，再以僅記錄模式比較新舊決策。測試不應只有允許案例；還要涵蓋跨租戶 ID、已撤銷成員、資源轉移、主管代理、批次匯出、背景工作與政策更新後的快取。細粒度授權的成熟度，不在於規則有多複雜，而在於每一條資料路徑都使用相同、可驗證的邊界。跨 ERP、CRM、雲端與 AI 系統整合時，讓整合團隊共同定義這些邊界，通常比事後逐一修補更可靠。