延續「Policy Engine:把企業規則從 Prompt 裡拿出來」,這篇聚焦「RBAC 與授權:Agent 不能因為「聽懂」就代表「有權」」:先定義變因與停止線,再由實驗結果檢驗原本的直覺。
設計 subject、role、resource、action,讓 tool 執行前重新授權,而不是相信 LLM 產生的使用者身分。
Authorization 應以使用者身份與系統 policy 為準,而不是由模型判斷。Agent 可以提出「使用者想取消某項資源」的 intent,但 Policy Engine 要確認 ownership、role、時間限制與組織規則。
Policy 最好可以測試、版本化並留下 decision log。若所有規則都藏在 system prompt,不只難測,也很難知道某次決策到底依據哪一版規則。
不要把「使用者在對話中說自己是管理員」當成身份。授權應以已驗證的 subject、role、resource、action 做判斷,而且 tool execution 時重新檢查。這樣即使 Prompt Injection 成功影響 Agent 的文字推理,也不應直接越過權限層。
這個案例用「以 requester、manager 與無權限身份呼叫相同 tool」檢查執行前後狀態、副作用與 audit event,再決定流程是否通過。
case = {
"action": '以 requester、manager 與無權限身份呼叫相同 tool',
"expected_metrics": ('allow/deny', 'role', 'resource scope', 'audit'),
}
before = load_state()
result = execute_case(case)
after = load_state()
assert result.final_state in {"SUCCEEDED", "REJECTED", "ESCALATED"}
assert side_effects_match_policy(before, after, result)
assert audit_matches(before, after, result.events)
驗證可從「以 requester、manager 與無權限身份呼叫相同 tool」開始。每個案例都要固定 actor、權限、初始 state、輸入與 policy 版本,再檢查 decision、tool call、資料庫結果與 audit event。只檢查模型最後說了什麼並不足夠,因為流程可能回覆成功,實際上卻沒有提交;也可能回覆失敗,外部副作用早已發生。
這篇優先比較:allow/deny、role、resource scope、audit。正常案例、拒絕案例與故障案例都要納入;符合規則的拒絕本身就是成功結果。遇到 timeout、重試或人工核准時,還要檢查流程能否從明確 checkpoint 繼續,且不會重複執行已完成的副作用。
所有可改變外部狀態的工具都應具備窄介面、輸入驗證、授權、冪等與稽核。高影響且不可逆的動作必須保留明確確認點。發生不確定狀態時,流程應停止並交由人工處理,不能依靠模型猜測先前是否已成功提交。
判讀順序應從最終 state 與外部副作用開始,再回頭閱讀模型訊息與 trace。若文字回覆看似合理,但權限檢查、資料庫狀態或 audit event 不一致,應直接判定流程失敗。相反地,policy 正確拒絕危險要求,即使任務沒有完成,也屬於控制機制成功。
單次流程通過後,還要重播相同 request、製造並行請求並在關鍵步驟中斷。這三類測試能分別檢查冪等、一致性與復原能力,也是 Agent 從展示走向正式流程前最容易被忽略的部分。
判讀不只看最大或最漂亮的數字。這一天真正要回答的是:聽懂要求不等於取得授權。
如果核心指標改善,但錯誤率、尾端延遲、資源成本或恢復能力變差,這代表取捨,而不是無條件進步。相反地,沒有改善也不是無效結果;至少能排除一條看似合理、實際上不值得增加複雜度的路。
今天的工程判斷是:聽懂要求不等於取得授權。無論結果支持或否定原本假設,都必須保留完整條件,才能和下一天的實驗串在一起。
下一篇將處理:Human-in-the-loop:哪些步驟一定要人確認。