那時我正興奮地叫 Antigravity 幫我搭一個 Claude Skill 掃描器的PoC。老實說，連 Prototype 都稱不上，只是個想證明AI 能掃出資安漏洞

為了求快、能動就好，我順手把自己的 Google Gemini API Key 整串貼進對話框，叫它直接寫死在 App 程式碼裡。 程式跑通的那一刻我很爽，但下一秒我背脊發涼：等等，我一個想做資安工具的人，竟然親手把鑰匙塞進給全世界看的前端程式碼裡？

現在它是免費方案沒錯，但如果我哪天升級成付費帳號、忘了設上限，這把鑰匙隨時能把我的信用卡刷到爆額。 那是我第一次深刻意識到為了便利我們可能會付出的代價是什麼？
別再讓 Agent 帶著你的提款卡出門

連本地端寫死一個免費的 API Key 都這麼危險，那當我們的 AI Agent 真的需要幫使用者存取外部服務或工具（像是 Google Drive、GitHub）時，該怎麼辦？

我們不能只是偷懶地叫使用者直接把 Token 或密碼雙手奉上。正確的做法，是使用 PKCE（Proof Key for Code Exchange）——這是一套專門用來防禦「授權碼被半路截胡」的動態驗證機制。

別被一長串英文名詞嚇到，它的核心比喻其實就像小學生對暗號一樣簡單：

出發前先想暗號：Agent 就像替我們跑腿的小幫手。在出發前，它心裡會先偷偷想好一組只有自己知道的隨機暗號（Code Verifier），並透過單向演算法把這組暗號攪碎成一串代碼（Code Challenge）。

去櫃檯登記代碼：小幫手先把這串攪碎的代碼傳給伺服器櫃檯，櫃檯在登入前先把它記在小本本上。

拿到臨時取件牌：使用者在官方頁面確認授權後，伺服器會發給小幫手一張短暫有效的「取件號碼牌」（授權碼 Authorization Code）。

截胡也領不到包裹：就算有惡意程式在網路中途或瀏覽器歷史裡搶走了這張號碼牌，它也沒用，因為櫃檯會要求核對原始暗號。

親自對暗號領 Token：小幫手帶著這張號碼牌，加上當初藏在自己心裡的那組原始暗號一起交給櫃檯。伺服器重新驗算一遍，確認算出來的結果跟當初記下的代碼完全一致，證明沒有被中途掉包，才放行核發真正的 Access Token。

給 Vibe Coder 的警醒：守住你的信任邊界

叫 AI 幫你寫程式、跑任務真的很過癮，但千萬別把「把關的責任」也一起外包給它。

當你把權限交出去的那一刻，你必須清楚知道自己的「信任邊界」在哪裡：

哪些資料可以給 AI、哪些不行？為什麼不行？

哪些敏感資料必須在出境前徹底去識別化？

哪些操作只能給最小權限的拋棄式憑證，而不是大剌剌塞一把萬能鑰匙？

PKCE 不只是一套暗號交換機制，它是給所有開發者的一道保險絲：
能用拋棄式暗號解決的事，不要拿你的身家密鑰去賭。享受 AI 帶來的極致便利很好，但別讓你的工具在替你打工的同時，悄悄替你把家門大開。