Agent runtime & agent identity 的一些看法

我最近一直在做 Agent Identity。

一開始我的 mental model 其實很單純: 要叫一個 agent 去做某件特定的事，至少要回答以下這幾個問題：

• 這是哪個 agent / workload？
• 它現在代表誰？
• 那個人到底授權它做什麼？
• 這份授權什麼時候過期？
• 這次 tool call 到底能不能做？

所以我花了一段時間把這整條 call path 做起來: 可以驗證 credential、 知道如何驗證 delegation 的委派鏈 (chain of delegation)、知道 scope 正不正確、 這次的委派是否在期限內 (驗證 expiry)、甚至在每次呼叫 tool 之前都要重新做 authorization。根據不同拒絕原因也能分得開。

整條 flow 慢慢接起來之後，我的 test cases 也越補越多，最後乾脆叫 Claude 幫我補到 50 幾個，當然毫不意外全部都 pass (哈)。我那時候其實滿有成就感的。 最後在 code review 的時候，不小心把呼叫 authorization 的那一行刪掉。再跑一次 test run，還是全部 pass，我當下就馬上傻眼了: 靠，測試寫爛了。

但後來越想越不對。如果這只是一個普通 library，那的確可以說是 test coverage 不夠。你做了一個 authorize()，application developer 忘了 call，那就是 integration bug。 可是我做的不是一個「想用就用」的 helper。我做的是一個 agent 理論上不應該繞得過去的 security boundary。 如果 application code 可以把那一行刪掉，agent 還是照樣 call tool，那這套 authorization 做得再漂亮有什麼用？

這時候我第一次真的卡住。我原本一直把問題想成：

Identity 還缺什麼？

後來問題突然變成：

誰保證 identity 一定會被 enforce？

這兩個問題完全不一樣。

我原本把 runtime 想錯了

我之前看到 Agent Runtime 這個詞，老實說一直有點無感。我腦袋裡的 runtime 比較接近：

「跑 agent 的東西。」

LangGraph、某個 SDK、graph executor、planner loop，差不多是這一類。所以我一直覺得 runtime 是 framework 那邊的事。 Identity 則是 security feature。把 identity 做好，接進去，就結束了。

但 authorization call 被我拔掉、測試還全部 pass 的那一刻，我第一次覺得這個模型可能根本錯了。 因為如果一個 security check 可以被 application code 選擇性繞過，那它其實不算 boundary - 它只是一個 API。

這讓我想到很多以前做 platform 的經驗。 SELinux 有意義，不是因為它有 policy file。 Android permission 有意義，也不是因為 framework 裡面有一張 permission table。

真正有意義的是：

最後碰 resource 的那條路，繞不過 enforcement。

如果 app 可以說：

我今天不想走這個 permission check。

那就沒什麼好談了。 所以我後來開始回頭去檢查我做的東西：

把這個 security check 拔掉，系統還能不能正常碰到 tool？

如果可以，那這個 boundary 還不完整，我只是做了一個 library。

然後我又發現，安全門根本沒鎖

更好笑的是，第一個洞還沒補完，我又看到第二個。 我原本所有檢查都在回答：

這是哪個 workload？

它拿的 credential 合不合法？

它有沒有一份 Alice 給的 delegation？

scope 裡面有沒有這次 action？

看起來很完整。但我回頭問了一個非常基本的問題：

等一下，現在到底是誰連進來？

才發現我沒辦法回答這個問題，假設 Alice 在 Slack 上跟 agent 說：

幫我把 device group A 全部重新啟動。

我原本腦袋裡畫的是這樣：

Alice -> Agent -> Tool

這個 flow 看起來很合理。可是這個flow 其實偷偷藏了兩件完全不同的事:

第一件：

現在跟我講話的人，真的是 Alice 嗎？

第二件：

Alice 有沒有授權這個 agent 做這件事？

在真的開始做 agent identity 之前，我把這兩件事畫成同一條線。因為 delegation 可以做得非常嚴謹。 文件裡可以寫：

delegator = Alice
actor     = Agent A
action    = restart
resource  = group_A
expires   = 16:00

當我們去檢查每一個欄位，基本上都會得到正確的答案，但如果「Alice」這個名字一開始就是從 session、conversation state，甚至任何模型碰得到的地方來的，那後面所有 authorization 都只是在很嚴格地驗一個可能是假的名字。這時候需要真的把幾件事拆開：

1. 現在跑這段程式的 workload identity 是誰？
2. 現在發出這個 request 的 user 是誰？
3. 這個 user 有沒有把這次需要的 authority 委派出去？
4. 目前這個 runtime / agent workload 能不能使用這份 delegation 做這個 action？

這四個問題回答不同的層面:

• SPIFFE / SVID 可以幫我回答第一題。
• OAuth / user authentication 處理第二題。
• delegation record 處理第三題。
• authorization policy 處理第四題。

在開始接觸 identity 之前，我可能還搞不太清楚：

SPIFFE 還是 OAuth Token Exchange？

現在我明白它們在回答不同 boundary 的問題。

我真正遇到的問題，不是「Identity 怎麼做」

到這裡我才慢慢發現，我真正遇到的問題其實不是：

Agent Identity 要怎麼設計？

而是：

這些 identity / delegation / authorization 到底要在哪裡被 enforce？

這就是我開始重新理解 runtime 的地方。不過老實說，這個詞現在每家公司可能講的還不太一樣。

有人比較偏 workflow。

有人比較偏 sandbox。

有人把 memory 也算進去。

有人講的是 framework + hosting。

每家公司根據自己的業務需求而會有不同 agent runtime 的定義。不過依照我的經驗，我現在會非常確定一件事：

Runtime 至少要擁有 execution boundary。

也就是 agent 最後要做 side effect 的時候，必須經過這一層。例如：

• call API
• restart machine
• modify data
• deploy
• send message
• change config

如果 agent application 可以直接繞過 runtime 去碰 tool，那 runtime 上面掛的 authorization、sandbox、audit、policy，其實全部都只是 optional middleware。 這個 distinction 對我來說比「runtime 是不是用 LangGraph」重要很多。

這時候 Identity 的位置也變了

以前我腦袋裡比較像：

Agent
+-- Planner
+-- Memory
+-- Tools
+-- Identity

Identity 是其中一個 feature。

現在我比較傾向畫成：

        Agent Application
                |
                |   <-- enforcement
                v
    -------------------------------
      RUNTIME BOUNDARY
    -------------------------------
      User -->  1. Authenticate user
                2. Identify workload
                3. Validate delegation
                4. Authorize action
                5. Execute tool
                6. Record audit trail
    -------------------------------
                |
                v
               Tool

這不是說 runtime 就等於 identity。而是 identity 這些東西如果不在 execution boundary 被強制 enforce，就沒有太大意義。 這個轉變是最近在做 Slack bot agent + MCP gateway 才開始慢慢清晰起來，因為我一開始真的是把 Agent Identity 當成一個 security subsystem。 現在我認爲它是一組 runtime property，或者講更精確一點：

是 runtime 必須 enforce 的 security properties。

然後更多問題開始跑出來

做到這裡之後，我才開始真正理解為什麼 Agent Runtime 這個領域現在看起來這麼亂。因為只要 execution boundary 一成立，很多本來分開看的問題突然會互相交纏在一起。 舉例來說: durable execution - 執行長時間任務時，需要確保任務能夠在中斷後恢復執行:

假設 Alice 下午兩點授權 agent：

兩個小時內，把 device group A restart 完。

agent 三點做到一半，存 checkpoint。四點機器掛了。晚上七點 runtime resume。那現在怎麼辦？原本的 delegation 早就過期了。你可以：

• 重新找 Alice 授權
• 自動 refresh
• 停下來等人
• 一開始就發更長效的 delegation

這些都是可能的選項。這讓我開始意識到：

durability 不是單純「能不能 resume」。

它會直接碰到 authorization lifecycle。這讓我很清楚地看到：

Identity 跟 execution lifecycle 其實分不開。

當然不能忘記如何做 audit。我以前很自然會想：

runtime 每次做 action 就寫一條 audit log。

不過這實在是 too simple too naive. 如果 runtime 自己被 compromise，那它同時也是自己歷史紀錄的作者。我們根本無法信任這份 audit log。Sandbox 也是一樣。 如果 sandbox 裡面自己寫「我是好人喔! 你要相信我! 我沒有做壞事」，這聽起來也是怪怪的，對吧 ?!

所以我這幾週到底學到什麼？

如果只看目前的 implementation code，這一輪我主要 focus 在 Agent Identity。

• credential。
• delegation。
• authorization。
• policy。

但如果看我描述的那些問題，我個人認為真正的 learning 不是那些 primitive 怎麼設計。而是：

Security property 沒有 enforcement boundary，就只是 metadata。

一份 signed delegation 本身不會保護任何東西。一個很漂亮的 authorization engine 也不會。它們只有在系統能保證：

所有真正有副作用的 execution 都必須經過這裡

的時候，才開始有意義。這也是為什麼我覺得自己開始慢慢理解 Agent Runtime。

接下來要做的事情

我目前不會直接說：

Agent Runtime 就是 X、Y、Z。

這次只是從 identity 這個洞鑽進去而已。接下來我還想繼續看 durable execution、sandbox、tool boundary、observability 這些東西到底怎麼跟 runtime 接在一起， 例如 Temporal、LangGraph、MCP、sandbox、OpenTelemetry，可以整理出很多重複出現的東西:

• control loop
• checkpoint / resume
• tool boundary
• sandbox
• identity / authorization
• observability
• audit

但這裡面我真的自己挖坑給自己跳的只有 identity / authorization，其他都還停在 “看過、讀過、想過”，而不是 “我跑過”。 所以我現在比較不想急著把它們包成一個漂亮 taxonomy。接下來就是一個一個鑽進去，針對不同的 areas 進行深入的了解！

Happy coding!