如何讓 AI 代理安全地註冊你的應用程式——WorkOS 產品經理 Isabelle Williams

WorkOS 產品經理 Isabelle Williams 主張，應用程式必須把 AI 代理（agent）當成第一級使用者：讓它們能自行註冊、代表真人行動，而且許可權可以被限縮、可以被撤銷；做法是採用開放標準，而不是把真人的憑證直接交給代理。她用一個名為 Waypoint、靠 vibe coding 做出來的旅遊 App 來闡述這套做法，依序拆解三個機制：auth.md 檔案讓代理自行得知如何註冊；ID-JAG 身分斷言讓代理供應商為使用者背書，App 因此能在無需使用者動手的情況下建立帳號；以及範圍限定在使用者許可權與代理「藍圖」交集的代理 Token。這場演講是節奏緊湊的 18 分鐘 demo 實演；企業差旅只是承載情境的載體，並非主題本身。

Williams 是從代理驗證基礎設施業界內部發聲——WorkOS 賣的就是驗證基礎設施，OpenAI、Anthropic、Cursor 都是它 3,000 多家客戶之一——因此她對「安全的」代理存取該長什麼樣子的框架，本身也是一套產品論述。讀者讀完應該能建立具體的心智模型：兩條註冊路徑（先匿名、後認領 vs. 身分斷言）、ID-JAG 的結構解剖，以及為什麼另外簽發一個範圍限定的代理 Token，會比重複使用使用者 Token 或 API key 更好。

核心問題：探索與註冊，如今由代理代勞

Williams 用產品驅動成長（product-led growth）的框架來談這個轉變。在代理出現之前，工作重點是讓真人從發現產品快速走到「啊哈時刻」。有了個人代理——她舉近期竄起的「Muse 與 Instinct」為例——使用者會把研究、產品探索與 onboarding 全部交給代理。這對 Waypoint 這類 App 帶來三個問題：怎麼讓代理進來、怎麼把代理的匿名成果連結到真實客戶，以及怎麼限制並撤銷代理能做的事（對企業差旅這個層級尤其關鍵，因為牽涉真金白銀與法遵）。

她明確表示，整件事必須建立在開放標準上：「我們要安全、可信地做到這件事，就必須全部建立在開放標準上」——讓代理能與服務溝通、執行操作、付款、註冊帳號。她提到，「就在過去一週」（也就是 2026 年 10 月中前後）有大量標準化工作發布。

`auth.md` 讓代理得知如何註冊——但驗證仍由你的 API 把關

auth.md 是一套開放協定：一個與應用程式一同託管的 markdown 檔案，代理讀了就知道如何取得存取權、建立帳號、呼叫你的使用者 API。Williams 強調責任分工——這個檔案只*描述*存取方式與操作，真正在 API 層執行驗證的是應用程式（Waypoint）。她指向一個以 auth.md 結尾的線上連結，說真人當然讀得懂，但「那不是寫給我們的，是寫給代理的。」

Waypoint 的 auth.md 定義了兩種模式：

| 模式 | 代理取得什麼 | 使用者必須做什麼 | 取捨 |
|---|---|---|---|
| 匿名試用 | 存取 Token + 一組認領 Token | 之後：開啟連結、註冊／登入、輸入一次性驗證碼、驗證 email | 代理能用有限操作證明價值，但認領流程是典型的 PLG 流失點 |
| 身分斷言（ID-JAG） | 以使用者名義簽發的存取 Token | 無需手動操作——只需同意分享姓名與已驗證的 email | 需要代理供應商是受信任的簽發方 |

匿名流程是這樣運作的：代理先執行有限操作，取得存取 Token 與認領 Token；當使用者想要擁有這份成果時，代理交給他一個連結與一次性驗證碼；使用者完成註冊、輸入驗證碼，成果就轉移到他的帳號之下；接著由 OAuth 讓授權伺服器以使用者名義簽發存取 Token。Williams 直言這個做法的弱點：「要點連結、走註冊流程、輸入驗證碼、驗證我的 email——如果你懂產品驅動成長，你就知道使用者正是在這裡流失的。」

ID-JAG 讓代理供應商為使用者背書，註冊從此無需動手

她對這個流失點的解法是：代理早就知道你是誰——你用 Claude Code 或 Muse 時本來就處於登入狀態，而該供應商已經驗證過你的 email。那為什麼不讓供應商直接告訴 App 你是誰？這正是 ID-JAG 能做到的事。

flowchart TD
    A["代理透過 auth.md 得知 API 與授權伺服器"] --> B["代理徵求使用者同意分享姓名與已驗證 email"]
    B --> C["代理向代理供應商請求 ID-JAG"]
    C --> D["代理將 ID-JAG 送至 App 的授權伺服器"]
    D --> E["App 驗證簽章，決定是否建立帳號、連結既有帳號與許可權範圍"]
    E --> F["App 以使用者名義對代理簽發存取 Token"]
    F --> G["代理以使用者身分呼叫 App API"]

ID-JAG 全名是 Identity Assertion JWT Authorization Grant（身分斷言 JWT 授權授予），是 IETF 的一份規格。它是對使用者身分的斷言，由簽發方（在此為代理供應商）簽章，並送往特定受眾（在此為 App）。Williams 指出，Anthropic 的企業託管授權（enterprise managed authorizations）與 MCP 相關工作，以及 Okta 的跨應用存取，背後用的都是同一份規格——而全場只有一個人聽過它，「而且他是我的同事。」

她拆解這個 Token 的結構：

標頭（Header）： 型別為 ID-JAG、簽章演算法、簽章金鑰。
酬載（Payload）： 簽發方（代理供應商）；來自供應商的使用者資訊——姓名、email、email 是否已驗證；受眾（Waypoint）以及 Waypoint 認得的 client ID；有效期間。
簽章（Signature）： 由簽發方的公鑰簽署。

App 的授權伺服器負責驗證簽章，之後的一切由 App 自行決定：要不要建立帳號、要不要連結既有帳號，以及回傳的存取 Token 要帶哪些許可權範圍。

Demo：全新使用者零手動操作就拿到完整行程

Williams 在她自己打造、能簽發 ID-JAG 的代理執行環境中跑這個流程，登入身分是 Sam Rivera——一個 Waypoint 從未見過的使用者。她請這個環境為 AIE New York City 規劃一份行程，並設成可與同事分享。這個環境逐一檢視可用工具：Maple itinerary 需要開瀏覽器註冊，TripleEdger 需要 API key，而 Waypoint 接受代理註冊。接著它徵求同意，分享 Sam 的姓名與已驗證 email，另外還有一項在 Waypoint auth.md 中定義的進階同意——預訂晚餐的許可權。

結果：身分驗證完成、Waypoint 帳號在無需使用者操作下建立、行程訂好、在 Quality Bistro 訂了晚餐（她推薦這家），還產生一個可分享給同事的行程連結。「我這邊完全不用動手。」她在這一段的收尾重點是：安全、可信的代理存取，全面都需要開放標準——讓代理能與服務溝通、進行交易、付款、註冊。

代理 Token 勝過使用者 Token：可稽核、可撤銷、可設上限

針對企業層級，Williams 介紹了 Jordan——公司裡掌管預算與核准規則的人。Waypoint 為 Jordan 推出兩個代理：一個唯讀聊天機器人（只回答問題，不做任何變更），以及一個資金代理，能在使用者之間排程資金——例如把錢從搭火車抵達波士頓的旅客，挪給機票昂貴的舊金山旅客——前提是不超出預算與已核准的規則。Jordan 的硬性要求是：資金代理絕不能為了把事情辦成，而改動預算或核准規則。

這裡的設計決策是：App 簽發代理 Token，而不是把 Jordan 的使用者 Token 交給代理，理由有三：

1. 稽核與歸屬——每個動作都能追溯到特定代理。
2. 撤銷——Jordan 或 App 可以撤銷代理，而不必動到 Jordan 自己的 session 或存取權。
3. 許可權限縮——Token 只帶代理該有的許可權。

每個代理都有一份藍圖——存取許可權的上限。簽發出去的代理 Token，其許可權範圍是使用者許可權與代理藍圖上限的交集。在 session 檢視中，代理 Token 的主體是代理 ID（可歸屬於該代理），並記錄它是代表 Jordan 行動，許可權則是前述的交集。

資金代理的 demo 展示了上限確實生效：被要求補上 Alex 的 250 美元缺口時，代理只能就現有的 70 美元重新排程，無法調高預算。Jordan 改用使用者 Token 把預算提高到 2,000 美元後，代理才完成補足。代理能在規則內排程資金，卻無法改寫規則。

三個重點與規格去哪裡找

Williams 最後以三部分框架收尾，並附上兩個 QR code——一個指向 auth.md（開放標準），一個指向 WorkOS 的代理驗證（說明她如何用代理 Token 把範圍限定的代理做進 App）。

| 重點 | 機制 |
|---|---|
| 讓代理進來 | 與 App 一同託管的 auth.md 檔案 |
| 把代理連結到真實客戶 | auth.md 中的使用者認領流程，或 ID-JAG 身分斷言 |
| 限制並撤銷代理動作 | 代理藍圖、範圍限定的代理 Token、撤銷機制 |

值得關注：標準整合的速度快過採用速度

最關鍵的一條線索是：ID-JAG 並非 WorkOS 的發明，而是 IETF 的規格，且已出現在 Anthropic 的企業託管授權、MCP 規格與 Okta 的跨應用存取之中。若這些實作走向整合，App 只要支援一次 ID-JAG，就能接受來自多家代理供應商的身分斷言，不必逐一客製整合。尚未化解的張力在於信任：ID-JAG 裡要相信什麼，完全由 App 自行決定，Williams 把這項政策整個留給應用程式——對於該接受哪些簽發方、哪種驗證等級，並沒有公認的基準。至於匿名認領流程，則仍是她點名、卻未真正解決的 PLG 負擔，她只是把 ID-JAG 路徑當成替代方案提出。值得持續追蹤的是：auth.md 與 ID-JAG 能否在目前已出貨的廠商之外取得正式背書，以及代理 Token 的許可權限縮會成為預設模式，或仍停留在各 App 自行設計的選項。