克勞德在公司內部的影響力越大，.env 就越危險。在共享辦公室時代，我們需要的是一個可以儲存機密資訊的地方，而不是「便利」。

這篇文章非常切中要點

坦白說，我認為這篇文章相較於“Claude在公司裡流行”的說法，更為直接地指出了AI代理時代的安全隱患。

即使非工程師，仍舊可以使用Claude Cowork和Claude Code來執行業務。

在這裡重點在於，AI不再僅僅是“回答問題的聊天工具”，而是實際上在PC或開發環境中操作的工具。

Claude的Cowork是將與Claude Code相同的代理型架構擴展到Claude Desktop，使其不再僅僅是單次響應，而是朝著整合多步驟工作執行的方向前進。Claude幫助中心 +1

因此，文章裡提到的“將秘密金鑰放在.env裡是危險的”這一句話尤為重要。

在過去，只要使用.gitignore進行排除，運作還算安全，但如今當AI假設會接觸本地文件或命令時，風險瞬間變得不再那麼令人放心。

究竟什麼這麼危險

根據Claude Code的官方文件，設定中可明確拒絕 Read(./.env) 或 Read(./secrets/**)。也就是說，官方設計上預設環境文件和秘密信息文件應受到保護。Claude

此外，認證文件指出，Claude Code自身的憑證存儲在macOS上的加密Keychain中，並可以通過類似apiKeyHelper的機制進行密鑰的外部化獲取。Claude +1

這部分相當重要。

Anthropic的幫助文檔作為API金鑰管理的基本，建議使用環境變數或Secrets，但這主要是針對應用程式或雲端運行的語境。在本地由AI代理執行命令的場景中，“僅靠環境變數就能夠保證安全”並無法簡單下結論。實際上，已經有報告指出Claude Code中的環境變數可能無意間暴露。這不是“危險已確定”的斷定，而是認為威脅模型已經改變更為自然。Claude幫助中心 +1

一天內完成OSS的價值

這篇文章中，我個人覺得最有趣的是，它不僅僅停留在“這很危險”的結論，而是團隊成員一天內創建了OSS。

實際上，與這一問題意識相當接近的公開案例是於3月1日發布的macOS Keychain管理CLI“LLM Key Ring（lkr）”。這個工具將密鑰存儲在Keychain中，並通過 lkr exec 僅將環境變數注入子進程，基本上不向標準輸出、文件或剪貼板輸出明文。此外，還防止在非交互式環境中輸出明文的TTY保護機制也包含在內。Zenn

這個設計雖然不起眼，但非常合理。

在AI代理時代的防護中，並不僅僅是導入大型安全產品，還需要積累這樣的小巧而鋒利的設計，比如“避免明文存放”、“僅在需要的瞬間注入”、“將人類與代理的經路分開”等等。

而這類工具能夠在一天內作為OSS成型亦具象徵意義。

隨著AI的普及，新問題和漏洞不斷增加。但同時，現場工程師能發現、迅速修復、公開，並加速周圍的採納速度也在提高。