iT邦幫忙

2026 iThome 鐵人賽

DAY 18
0
AI Security

AI Agent 憑什麼動手?30 天拆解 Agent Identity、Delegation 與 Authorization系列 第 18 篇

Day 18|Agent 的權限應該依 Role、Context 還是 Task 決定?

  • 分享至 

  • xImage
  •  

Core Question

面對動態 Agent execution,RBAC、ABAC 與 task-bound policy 應如何組合?

今天的問題

客服 Agent 的 Role 是 support-reader,但它今天只處理 Alice 指派的 Task T-18,只能讀 owner 為 Alice 的低敏感 ticket,且必須在值班時間執行。Role 提供穩定基線,卻沒有表達 Task、owner、時間與 risk。反過來只看 context,任何呼叫都可能缺少最基本的能力邊界。

為什麼這不是傳統 IAM 問題

拿掉 Agent 便只是一般 IAM matrix;Agent-specific 的地方在於 actor 會自主產生多次 Action,Task context 在每一步可能改變,且 context 的來源和 freshness 必須可驗證。

Threat / Failure Scenario

Agent 擁有 support-reader,模型收到另一個部門 ticket 後照樣讀取;或 attacker 讓 Agent 把 task_id 改成已結束的 Task。只靠 Role 會過度授權,只信任 Agent 自報 context 會讓 policy 變成可輸入的答案。

核心概念

NIST SP 800-162將 ABAC 描述為依 subject、object、operation、environment attributes 與 policy 決策;NIST RBAC 研究資料則把 Role 作為 permissions 的中介。實務上可採 RBAC baseline ∩ ABAC constraints ∩ task grant:任一層 deny 即 deny。

Task-bound policy 不是把 Task ID 當秘密,而是把可信的 Task grant 綁定 actor、subject、purpose、resource set、expiry、step 與 action digest。attribute provider 要標記 issuer、issued_at、expiry;缺 attribute 或過期時 default deny。

Architecture Pattern

Naive / Unsafe Design

PDP 只看 role=support-reader,或直接採用 Agent request 中的 owner、risk、task_id。

Recommended Design

Identity service 提供 actor/subject,Task service 發出不可由 Agent 修改的 grant,Resource service 提供 owner/sensitivity,environment service 提供時間與風險。PDP 合併穩定 Role 與動態約束;PEP 把決策套在每個 call。

Trust Boundary

Agent 是 attribute consumer,不是 attribute issuer。Task grant、resource metadata、risk signal 與 Role directory 分別由受信任服務簽發;PDP 驗證 freshness,PEP 防止旁路。

Identity Flow

actor=agent://support/instance/18 代表執行者,subject=alice 代表被代行者;Task grant 指向兩者與 audience。Token 只提供身分/粗粒度 scope,不能取代 resource 與 Task decision。

Authorization Decision Point

對每次 Action 檢查 role ∩ {task_active, owner_match, sensitivity<=allowed, business_hours, risk<high}。政策衝突採 deny-overrides,未知值不當成 false 以外的 allow。

https://ithelp.ithome.com.tw/upload/images/20260921/201201519unkeiGWet.png

小型 PoC

def decide(role, task_active, owner_match, hour, risk):
    return (role == "support-reader" and task_active and owner_match
            and 9 <= hour < 18 and risk == "low")

assert decide("support-reader", True, True, 10, "low") is True
assert decide("support-reader", True, False, 10, "low") is False
assert decide("support-reader", True, True, 20, "low") is False
assert decide("support-reader", True, True, 10, "high") is False
print("role-baseline=ok context/task-deny=ok")

今天得到什麼

  1. Role 適合穩定 baseline,不足以描述 Agent 的每次執行。
  2. Context 可收窄權限,前提是來源、完整性與 freshness 可驗證。
  3. Task grant 把自然語言目標變成有限、可過期的 authority。
  4. RBAC、ABAC、task policy 應以交集組合,未知與衝突採 deny。

下一篇

Day 19 會把 decision 從「能不能用這個 Tool」再細化為 query、update、bulk delete 的 action risk。

參考資料


上一篇
Day 17|一個 MCP Server 暴露 20 個 Tools,Agent 都能叫嗎?
下一篇
Day 19|「查詢」和「刪除」都是 Tool Call,風險卻完全不同
系列文
AI Agent 憑什麼動手?30 天拆解 Agent Identity、Delegation 與 Authorization 共 23 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言