嗨，我是 Jeongwoo，目前在 LY Corporation 擔任資安平台工程師，負責開發與營運 Athenz。
在我先前的文章，Why ID-JAG is the future of AI agent security - LY Tech Blog 中，我討論了為何身分斷言式 JWT 授權授予 (ID-JAG) 對 AI agents 越來越重要，說明它如何把傳統的單一登入 (SSO) 信任模型延伸到 API 範疇，以及對 AI 開發者與企業而言的核心好處與應注意事項。
今天，我們要從理論走向實作。為了縮短從抽象規格到實務執行的距離，我準備了一個實作教學範例：athenz-community/id-jag-the-hard-way。
這個本地實驗環境讓你可以直接觀察在 AI agent 代表使用者存取受保護 API 時，所需的實際 token、policy 與信任關係。
示範影片:
TL;DR：你將學到
- 如何在本地重現端到端的 ID-JAG 流程，讓 AI agent 能在已登入使用者的名義下安全地存取受保護的 API。
- AI agent 如何與受保護的模型上下文協議 (MCP) 伺服器互動、企業政策如何由 authorization server 評估，以及 resource server 如何強制執行產生的最小權限存取 token。
- 確切地知道 tokens 在哪裡被簽發，以及當某項特定 policy 缺失時整個流程在哪個環節崩潰。
1. 超越架構圖
ID-JAG 是 IETF OAuth 工作群的一份活躍 Internet-Draft（截至 2026 年 5 月為 draft-ietf-oauth-identity-assertion-authz-grant-03），它利用下列 RFC 的既有原語來促成安全的委派跨域 API 存取：
雖然架構圖能提供高階視角，但在實作時常常無法回答那些實務工程問題：
- 當使用者登入 AI agent 時，會產生什麼樣的 token payload？
- 如果我們已經有一個 ID token，為什麼不能直接把它換成 access token，而非透過 ID-JAG？
- 能否讓 IdP（身份提供者）持續負責認證，同時把企業授權政策的管理與評估放在獨立的政策決策點 (PDP)？
- 在呼叫 MCP 伺服器時，AI agent 具備哪些具體權限？它如何證明自己是代表該已登入的人在執行？
- 企業 IdP 與 authorization server 之間的系統層級信任要如何設定？
2. AI agent 的授權挑戰
在傳統應用程式安全模型中，使用者或服務帳戶會以固定憑證（密碼、憑證）取得靜態存取權限。AI agents 並不完全符合這兩種模型：它們既不是以固定、可預期流程運行的服務帳戶，也不是可立即對其行為負責的人類使用者，而是一種不同且持續演化的 actor 類型。
AI agents 會在背景持續呼叫內部 API、SaaS 工具與資料庫。如果在這個自動化的連鎖中每一步都去打擾人類使用者請求同意，會嚴重破壞使用體驗。
反過來，給予 agent 廣泛且永久的同意，則會造成巨大的 blast radius 與責任歸屬問題。如果 agent 行為異常或遭到利用，很難區分是使用者本意還是被委派的 agent 行為。這會持續增加個人去手動監控 agent 行為的認知負擔，浪費寶貴的人力注意力與營運成本，也可能導致企業內部出現 Shadow AI，使組織暴露於像 prompt injection 這類新興攻擊向量，並大幅擴大攻擊面。
「這個 AI agent 現在有權在這個精確的權限範圍下，代表這個使用者存取這個特定資源嗎？」
ID-JAG 的作用就是遠離碎片化、臨時的點對點連線，而是在企業 IdP 與資源授權伺服器之間建立一個由細緻企業政策所治理的集中信任結構。
3. 示範架構元件
本實驗環境使用五個核心元件：
| 元件 | 技術 | 角色 |
|---|---|---|
| Requesting Agent | Open WebUI, Ollama, Gemma 4, AI Client Gateway | 本地 AI agent 與 gateway，代表使用者執行工具。 |
| IdP | Keycloak (on Docker) | 管理使用者認證與 subject 斷言的身份提供者 (IdP)。 |
| IdP authorization server | Athenz KeycloakTokenExchangePlugin | 負責驗證身分斷言並簽發 ID-JAG token 的外掛元件 / 授權伺服器。 |
| Authorization server | Athenz (on Local K8s) | 作為政策決策點 (PDP) 並簽發 access token 的授權伺服器。 |
| Resource server | Sample Document API | 目標受保護的資源伺服器。 |
架構設計說明
在參考的 ID-JAG 模型中，IdP authorization server 通常是那個認證使用者、評估某個 client 是否可以代表該使用者行事，並簽發 ID-JAG 的元件。
本教學刻意把這些責任分離。Keycloak 扮演上游的 IdP，負責使用者認證與原始的身分斷言；而 Athenz 透過 KeycloakTokenExchangePlugin 作為聯邦式的 IdP authorization server，針對 ID-JAG 流程驗證 Keycloak 簽發的斷言、套用企業政策，並簽發 ID-JAG 斷言。
這和草案中最簡化的部署模型略有不同，但保留了相同的安全邊界。Resource authorization server 不會盲目接受上游 Keycloak 的 token 作為資源授權授予；相反地，它信任的是 Athenz 簽發的 ID-JAG，而這個 ID-JAG 只有在完成 issuer、簽章、audience、subject、client binding 與企業政策檢查之後才會被產出。
4. 追蹤執行流程
在執行此實驗時，內部會發生以下序列：
- 使用者透過 Keycloak IdP 登入系統。
- 使用者輸入 prompt，啟動 AI agent 的任務。
- AI agent 向 Athenz 的 IdP authorization server 請求 ID_JAG token。
- Athenz 評估並驗證企業政策，以確保所請求的委派被允許。
- AI agent 向 Athenz 的 authorization server 請求 access token。
- AI agent 帶著該 token 向 MCP 伺服器送出請求。
- MCP 伺服器與 authorization server 執行 token 交換。
- MCP 伺服器帶著交換後的 token 向最終的 resource server 發出請求。
關鍵是，AI agent 避免持有長期存在的 master key；它在企業政策引擎評估所限定的特定邊界內運作。
5. 以失敗為設計：從阻礙中學習
AI agent 授權架構最好透過其失敗路徑來理解，而非僅看成功的路徑。當你觀察系統如何處理未授權的狀態時，安全設計會更清晰；因此本實驗會有意帶你經過幾個故意設下的失敗點：
- 你會在沒有 token 的情況下呼叫受保護的 API，觀察到
401 Unauthorized。 - 你會設定一個企業角色但忽略成員關係，導致 token 交換失敗。
- 你會嘗試在沒有明確授予 agent 必要權限的情況下做委派呼叫，使委派鏈中斷。
架構深入：為什麼不直接交換 ID token？
在本教學的簡易本地部署中，直接把 Keycloak 的 ID Token 換成 Athenz 的 access token 在技術上也是可行的。Athenz 可以驗證 Keycloak token 的 issuer、簽章、audience 與 subject，然後評估 Athenz policy 並簽發 access token。
然而，那個模型隱含地把登入 token 視為資源存取的 authorization grant。這個區別在失敗與稽核路徑上尤其重要。ID Token 證明使用者已向某個 client 完成認證；而 authorization grant 則是提交給授權伺服器以請求某資源與 scope 的資源授權憑證。
透過引入一個授權授予邊界，我們能將認證失敗、授權授予驗證失敗、agent 委派拒絕、企業政策拒絕與資源 token 拒絕分開處理。簡言之，它避免把身分資料與明確的存取權限混為一談，確保一次認證事件不會自動等同於跨域授權權利。
6. 快速上手：在本地執行此流程
要開始實作練習，請前往下方儲存 庫連結：
🔗 儲存庫: athenz-community/id-jag-the-hard-way
在主頁點選 START THE TUTORIAL NOW 按鈕，會引導你完成本地環境的設定步驟並驗證 ID-JAG 流程。
結語
隨著 AI agents 在企業工作流程中規模化，僅在前門驗證認證通常不足以保障安全。現代架構需要系統性的控制與對委派存取的明確稽核。
ID-JAG 提供了一個結構化的方式來管理這種複雜性，而透過直接的動手實驗可以更容易理解其運作原理。歡迎在 id-jag-the-hard-way 提出貢獻、問題或回饋。
💡 Tech-Verse 2026 預告
我們將於 Tech-Verse 2026（LY Corporation 年度技術大會）發表此主題，場次題目為：
「ID-JAG：面向 MCP 與 A2A 世代的企業級 AI agent 授權標準」。
我們會超越基本協定機制，討論中央政策控制模型，探索 agent 生態圈的相關動向——包含 Google 的 Agent2Agent (A2A) 工作、以及雲端平台在 AI agent 安全性的做法——並分析這些策略與由 Okta 與 Ping Identity 等貢獻者參與的 ID-JAG 草案之比較。屆時見！
同一作者的其他文章
![[I/O Extended Taipei] 在 Gemini API 家族中建構應用程式：從呼叫 API，到架構一個會自己完成工作的系統](/static/adae21cfc0c573393d486386200ed4cd/d990e/9d4ba616811b4f9e9be4ff927f65090e.png)
