這真的是 A16Z 趨勢報告的最後一篇了 XDD, 要補的是報告內的第五段 (正好蹭一下熱門話題: 網紅 Vibe Coding + APIKEY 風波)

( 5 ). Beyond .env: Managing secrets in an agent-driven world

第一個談 secret management, 報告裡舉的是 .env 的例子, 其實是後端服務設定 APIKEY 等等這類 secret 很常用的做法。比起直接寫 config, 資訊存在 disk 上就不及格了, 典型的做法是透過環境變數 ( env ), 而 .env 不也是檔案嗎? 沒錯, 但是至少不是應用程式直接去讀取, 通常會是 k8s, docker 等等這類 host 環境管理, 正式環境都會統一做加密處理, 再用 env 的方式給應用程式。

在 Agent 的應用當中，有大量的 Agent → Tool → 外部服務，都需要某種程度的認證或授權。如果通通都用 .env 來處理應該會搞死人吧… 我直接拿一段對話當作案例:

使用者: Hello ChatGPT, 幫我看一下明天何時有 30min 的空閑時間，我要安排會議

ChatGPT: 好的，我替你確認 ( 使用 Calendar MCP 查詢 Google Calendar, 看看 2025/10/09 的行程 … )

ChatGPT: 你好, 我看到你明天的 14:00 ~ 15:00 沒有預約, 我幫你安排 14:00 ~ 14:30 進行會議 … blah blah..

其他我就略過了。在這個案例中，因為 Agent 的介入，其實這背後有好幾套系統跟角色介入，包含 使用者 (你)，ChatGPT (OpenAI)，MCP (3rd Party)，Google Calendar (Google)。 而最關鍵的問題是:

” 使用者 (你), 你願意授權給誰 (系統) 取得你的個人資訊 (行事曆)? 允許他存取多久? “

用 .env 不可行的原因就在這邊，你總不能想用的時候再去改 .env 吧? 其實這問題早在 SaaS 時代就存在了，也因此發展出 OAuth (第一版 2006 制定) 的三方認證授權機制。而在 Agent 時代，這樣的需求更大了，MCP 的標準規範，直接要求所有需要認證的 MCP server 一率使用 OAuth2.1 當作 User / Agent / MCP tools / Backend Service & Resources 傳遞認證與授權的標準做法。

這段趨勢報告要說明的就是, Agent 的盛行一定會帶來這樣的需求，預先設定好 secret 的作法已經不適用；取而代之的是需要時當下才由資源端直接跟使用者確認，同意後立即用安全的管道將 access token 轉發給被授權的應用程式，已經是必要的做法了。而 MCP 的標準在制定的時候, 2025/03/26 修訂的版本, 就明文把 OAuth2.1 正式列為必要的規格。

回到前陣子的熱門話題 (就是 Vibe Coding + APIKEY 事件)，核心問題根本不在 code 有沒有正確處理 APIKEY ；就算 code 真的能正確使用 USER 自己提供的 APIKEY，你敢把你的 APIKEY “貼” 到這網站上嗎? APIKEY 換成信用卡卡號，你放心貼上去嗎? 這是設計跟驗證問題, 跟 code 沒直接關聯。這次事件的結果是帳都算到自己頭上，作者本人自己花了一萬塊台幣收場 (其實我覺得這是最好的收場了)，嚴重一點，大家的 APIKEY 外洩了，或是 A 使用者用到 B 使用者的 APIKEY，很可能作者連 “該賠多少” 都算不出來 (而 Google 至少還算得出帳單)。

APIKEY 搞錯的話，你算得出該補多少或賠多少嗎? APIKEY 外洩的話，你追得出來從哪個管道外洩的嗎? (可能連 LOG 都沒有吧) 這些都屬於資安問題，從流程跟處理方法就要合規 (絕對不是列一些 checklist 就會解決的)。

安全問題靠的是 “正確的方法跟設計” ，而不是靠你寫出 “正確的 code” 而已 … 很多人寫了土炮的加解密需求，禁不起正規的考驗的。問題不在你有沒有能力寫這樣的 code, 而是在你必須按照正規的 “流程” 來處理 secret。當年 (2020/11) 寫過一篇文章就在談這件事: [架構師觀點 - 資安沒有捷徑，請從根本做起]

– 這些內容，我都收到部落格文章內了。 文章連結我放留言