WorkOS 本週發布了 auth.md——一個開放規範加上一個具體的檔案 artifact,解決幾乎每個 agent 團隊都在手工拼裝的問題:agent 如何證明它正在代表使用者 X 行動,憑證是 user-scoped、可撤銷的、而不是塞在環境變數裡的裸 API key。形狀:一個小的 Markdown 檔案由應用程式發布在服務根目錄(既作為人類開發者的文件,也作為 agent 能在執行時以程式方式讀取的 artifact),加上 OAuth 2.0 元資料擴充。對那些把 agent 部署到生產環境、需要代表使用者呼叫第三方 API 的 builder 來說,這是處理正確問題的規範。
發現是一個兩跳元資料鏈。Agent 打 `/.well-known/oauth-protected-resource`(Protected Resource Metadata)以找到 authorization server,然後獲取 `/.well-known/oauth-authorization-server`,其中包含一個新的 `agent_auth` 區塊,有四個 URI:`register_uri`、`claim_uri`、`revocation_uri` 和 `identity_types_supported`。新 grant 類型是 ID-JAG(Identity-scoped JSON Authorization Grant)按 RFC 9728——agent 身分提供者透過簽名 JWT 來證明使用者身分,authorization server 驗證這個斷言,返回 scoped 憑證。受保護端點上的 401 回應包含 `WWW-Authenticate: Bearer resource_metadata="..."`,使 agent 無需預先設定即可啟動到發現鏈中。OpenAI、Anthropic 和 Cursor 被引用為潛在的身分提供者;規範不要求任何單一供應商。
與 RFC 7591 動態用戶端註冊的區別很重要,規範對此說得很明確。RFC 7591 讓一個用戶端向 authorization server 註冊自己——有用,但用戶端以*它自己*的身分認證。auth.md 解決一個不同的問題:agent 以*使用者*的身分認證,代表使用者,authorization server 理解這個區別並發放 user-scoped 可撤銷的憑證。這是 agent-loop 世界的正確原語:一個呼叫 `send_email` 的 agent 應該以使用者的 email 權限行動,而不是以全域的「我是 agent 服務」權限行動,使用者應該能夠撤銷這個特定 agent 的存取而不必輪換自己的憑證。今天大多數 agent 產品要嘛讓使用者貼上裸 API key(不安全、每個 agent 不可撤銷),要嘛透過 agent 廠商自己的 auth 執行一切(鎖定)。auth.md 是標準化的中間道路。
週一早上:如果你在 ship 一個需要代表使用者呼叫第三方 API 的 agent,閱讀 github.com/workos/auth.md 上的規範,檢查你的 auth 提供者(Auth0、Okta、自訂)是否有走向 ID-JAG 支援的路線圖。誠實的缺口是實作狀態——只有 early access,沒有廣泛的生產伺服器,文章指出 MCP server 或裸 LLM API 呼叫在此階段通常不能參與 agent-verified 流程。與現有 OAuth 函式庫的相容性在發布中沒有明確處理;預期會有 rough edges。但架構決定是合理的:這是 AWS MCP 伺服器的 IAM-OAuth 橋在資源端解決的同一問題的使用者端,agent 基礎建設棧兩邊都需要。WorkOS 在規範上很早;問題是 OpenAI、Anthropic 和雲廠商是幾個月還是幾個季度 ship 互通。