077 · 舊授權模型接不住 agent
從一次延遲異常追出根本問題：agent 既不是人、也不是決定性的程式，舊的身份驗證模型完全撐不住。
原標題：You Didn't Ship a Bug. You Just Wrote It for a Human. - Ravi Madabhushi, Scalekit
重點摘要
- 從延遲異常查出架構盲點ScaleKit 發現效能每 15 分鐘規律尖峰，追根究柢是身份系統原本只為人類設計，agent 打 API 的頻率遠超預期，逼出更深的架構問題。
- 舊有身份模型只有兩種，都不是為 agent 設計不管是使用者帶 API key 的應用程式，還是走 OAuth／SPIFFE 的服務帳號，核心假設都是認證者就是行動者，權限在註冊當下就固定死。
- 這套假設在 agent 身上站不住腳agent 常常代替使用者行動，principal 與 actor 因此分離，而且行為不像人類寫的程式那樣有決定性，今天沒問題不代表明天也一樣。
- 多數 MCP server 把權限管理丟給 agent 自己判斷它們往往曝露全部工具，而不是依授權使用者限制存取範圍，安全邊界等於交給 agent 自由心證。
- 解法是更細粒度、動態的授權，而不是加大 OAuth scopeagent 應該有自己的身份、綁定 principal，預設最小權限，需要更高權限時走即時授權。
- 這不是理論問題已經有 agent 誤刪 production 資料庫的真實案例，講者也用客戶 ref.tools 限縮 coding agent context 的做法當範例。
時間軸
時碼點下去會跳到影片的那一段。
| 時碼 | 段落 | 重點 |
|---|---|---|
| 00:00 | 開場 | Ravi 自我介紹身分，點出要談的是為人類設計的架構為何不適用於 agent。 |
| 00:17 | 效能異常追蹤 | ScaleKit 觀察到延遲每 15 分鐘規律尖峰，決定深入排查原因。 |
| 01:07 | 找到病灶 | agent 打 API 的頻率是人類的 60 倍，讓原本為人類設計的 last-seen 時間戳機制不堪負荷，雖然好修，卻點出更深的疑慮。 |
| 01:56 | 講者背景 | Ravi 曾在 Freshworks 打造服務千萬使用者的身份驗證平台，累積十年經驗。 |
| 02:28 | 權限過大是常態 | 開發者給 agent 的權限普遍超出其工作所需，不是粗心，而是現有做法下的預設結果。 |
| 03:11 | 兩種舊身份模型 | 不管是使用者帶 API key 的應用程式，還是服務帳號走 OAuth／SPIFFE，都不是針對 agent 設計。 |
| 04:24 | 核心假設：認證者＝行動者 | 傳統模型裡權限在註冊當下就固定，之後每次行動都照那組權限走。 |
| 06:04 | 為何過去行得通 | 因為程式是人寫的、行為可預期，甚至能像 Google 審查敏感 scope 一樣被檢查。 |
| 07:13 | agent 打破假設 | agent 不是人寫的決定性程式，代替使用者行動時，principal 與 actor 也不再是同一個。 |
| 08:18 | MCP 曝露過多工具 | 多數 MCP server 不會依授權使用者限制工具存取，而是把全部工具丟給 agent 自己判斷。 |
| 09:15 | 解法：agent 專屬身份 | agent 該有自己的身份並綁定 principal，權限要細到屬性與情境層級，不只是套用現成 OAuth scope。 |
| 11:00 | 不是未來式的問題 | 已經有 agent 誤刪 production 資料庫的真實案例，講者以客戶 ref.tools 限縮 coding agent context 為例。 |
| 11:51 | 結語：可視性與防護 | 沒有完整可視性與決定性防護，等於只能祈禱 agent 不出包，而祈禱不是策略。 |
值得記的話
名詞與人物
延伸
- Google 開發者帳號申請敏感 scope 時會做安全審查，這場只提了一句，沒有展開細節。
- OAuth 的 client credentials 模式在 agent 場景下實際怎麼運作，講者沒有進一步說明。
- ref.tools 具體怎麼判斷「overscoping」、怎麼收斂權限，這場沒有講細節。