API key 就是 agent 的身分：用預算、速率、模型白名單與凍結管住自動化

人透過帳號登入，agent 透過 API key 行動。當一個 coding agent 或排程中的自動化流程呼叫模型時，平台看到的只有那把 key，所以 key 實際上就是 agent 的身分。〈Authenticated Delegation and Authorized AI Agents〉（arXiv 2501.09674）指出，目前 agent 代替使用者發出的 API 呼叫，常常和使用者本人的操作在紀錄上無法區分，出事時責任追不到人。要補上這個缺口，第一步不是新協定，而是把 key 用對。

最基本的原則是一把 key 對應一個用途。不同的 agent、不同的環境（開發、測試、正式）、不同的專案，各自使用自己的 key，不要把個人的 key 交給 agent，也不要讓多個自動化流程共用一把。這樣做的好處很直接：用量可以分開看，出問題時可以只停掉那一把，而不必讓整個組織停擺。

在這個基礎上，每把 key 至少需要四種控制。月預算上限，超過就停止，避免失控的迴圈燒掉整個月的預算；每分鐘請求數上限，擋住重試風暴；模型白名單，讓這把 key 只能呼叫被核准的模型；以及凍結，分成會自動解凍的暫時凍結，和必須由管理員解除的凍結。X Cube 的每把 API key 都可以設定這四項，對應的錯誤碼分別是 402（預算用完）、429（速率限制）與 403（模型不允許或 key 已凍結）。

這些錯誤碼對 agent 而言是行為指令，應該寫進給 agent 的說明文件。402 代表「停下來告訴你的人」，不該重試；429 代表退避後再試；403 代表換一個允許的模型，若是 key 被凍結則回報給人。把這些規則寫清楚，agent 碰到邊界時才會做出可預期的反應，而不是一路重試，把限流當成需要繞過的障礙。

身分的另一半是可追溯。平台應該能回答：這次呼叫用的是哪把 key、屬於哪個組織、呼叫了什麼模型、花了多少錢。X Cube 提供 /v1/key 讓呼叫端查詢自身這把 key 的資訊與花費，提供 /v1/usage 查詢組織在一段期間的用量，平台端則有多租戶隔離與稽核紀錄。這讓「agent 做了什麼」不再只能靠事後猜測。

標準層面，為 agent 設計的身分與授權規範仍在發展，例如在 OAuth 2.0 與 OpenID Connect 之上加入 agent 專屬憑證的提案，目前多半還是個別草案。在這些標準成熟之前，企業最可靠的做法，是把現有的 API key 管理做到位：一用途一把 key、四項控制全開、錯誤碼寫進 runbook、用量定期檢視，並在 agent 不再需要時立刻撤銷。