Permissions

2.0.1 的 Admin authorization 以 permission path + action code pair 執行。Controller 宣告需要的 pair，登入 member 則透過 assigned roles 取得權限。

Runtime 實例

因此只有 authentication 並不足以執行這些操作；所需 path/action pair 還必須能從 member 的 roles 解出。

Permission-action templates 是 authoritative inventory

Role API 提供 permission-action-templates inventory。每個 template 包含：

• permission ID、name、path；
• action ID、code、name。

Role payload 用 { PermissionId, ActionId } pair 提交選擇。Role service 會去除重複，並只保存 template inventory 中真實存在的組合。

Role 是 assignment unit

Member 被指派 roles，而 role 內含 permission/action selections：

Member
  └─ Role(s)
       └─ Permission path + Action

一個 member 可以有多個 roles，有效 Admin access 是這些 roles permission surface 的合併結果。

Authorization 變更會讓 stale state 失效

Role edit 屬於 security-sensitive mutation。Permission 改變時，role service 會找出受影響 members、遞增其 security version，並透過 auth runtime-state cache barrier 完成更新。

目的就是避免已登入 session 在 role definition 改變後仍長時間使用 stale authorization。

Protected SuperUser role

SuperUser 是 2.0.1 的 built-in protected role，不能透過一般 role management 修改或刪除，避免 full-control role 被偷偷重新定義成另一套 permission set。

相關文件

• Members 與 Roles — member lifecycle 與 role guardrails。
• Database Management — DB / semantic permission examples。
• MCP Keys — MCP credential 與 Admin roles 是不同 authorization boundary。
• Security Policies — 透過獨立 Admin permission 管理 runtime SQL/rate/concurrency policy。