AI 拿得到 OTP，不代表它什麼都可以做

最近兩件事情剛好撞在一起，都關於 AI Agent 的「權限」。

一次原本很普通的 User Testing

這週用 Grokbot 實測，原本只是想做一次 User Testing，結果它可以一路完成：

• 註冊／登入
• 取得 Email OTP
• 填寫資料
• 選擇方案
• 完成預約
• 再取消預約

最後還能整理缺陷與測試紀錄。

看到這裡，我第一個感受其實不是「AI 好厲害」，而是：

當 AI 已經可以代表一個人操作系統，我們準備好讓它做到哪裡了？

以測試來說，這當然很有價值，它幫我省下很多重複操作的時間。但換個角度想，如果今天操作的不是測試帳號，而是真實客戶的帳號，那這一整串動作，每一步都牽涉到授權。

另一件事：平台開始擋 Agent

很巧的是，最近看到 Amazon 擋下 Meta 的 Muse。Muse 可以代表使用者到 Amazon 找商品、下單，但 Amazon 認為這個 Agent 並沒有取得平台授權，也沒有清楚表明自己的身分。

這件事很有意思，因為問題已經不是「AI 做不做得到」，而是：

• 誰授權它做？
• 平台允不允許？
• 它到底代表誰？

技術上能做到，和被允許去做，是兩件事。過去這兩者之間的距離，靠的是「人」本身：只有本人會登入、會輸入密碼、會按下確認。Agent 出現之後，這段距離突然變得很短。

Login 不夠用了

以前 Login 解決的是：「你是不是這個帳號的使用者？」

Agent 時代還要再多問幾層：

• 這次操作的是本人，還是 AI？
• AI 是代表誰執行？
• 被授權看到哪些資料？
• 可以做到哪一步？
• 哪些動作需要本人再次確認？
• 發生問題，能不能完整追溯與立即停止？

不能因為 AI 拿得到 OTP，就代表它什麼都可以做。

OTP 原本的設計，是確認「這個人能收到這封信」，進而推定是本人。但當 AI 也能讀信，這個推定就不成立了。很多我們以為理所當然的安全假設，都需要重新檢查一遍。

從 Login 到 Delegation

所以我覺得，Agent 時代真正要重新設計的，不只是 Login，而是 Delegation（委託）。可以拆成一條鏈：

Identity → Permission → Action → Audit → Human Control

• Identity：清楚辨識是誰在操作，是本人，還是代表本人的 Agent。
• Permission：這個 Agent 被授權的範圍是什麼，看得到哪些資料。
• Action：哪些動作可以自動完成，哪些需要本人再確認一次，例如付款、刪除、對外送出。
• Audit：每一個動作都留下紀錄，事後能完整追溯。
• Human Control：任何時候，人都能叫停，而且停得下來。

AI 越會做事，這條鏈反而越重要。

企業接下來要回答的問題

Amazon 擋 Muse，其實只是很早出現的一個訊號。未來企業真正要回答的問題可能會是：

我要不要讓別人的 AI，進到我的系統裡替客戶做事？

如果答應，要開放到什麼程度？如果拒絕，會不會把客戶推到願意開放的平台？這個問題沒有標準答案，但每個有線上服務的企業，遲早都要想。

對做健康相關服務的我們來說，這件事更敏感。客戶的資料、預約、方案選擇，每一步都和信任有關。

最後

這背後談的已經不只是 AI，而是信任、權限、責任，以及誰擁有 Customer Journey。

那次 User Testing 最後的測試紀錄很完整。但它留給我最重要的一筆紀錄，其實不在缺陷清單裡，而是這個問題：我們準備好讓它做到哪裡了？