幾個月前，安全團隊在一次審計里發(fā)現(xiàn)了一個讓我們坐立不安的事實：公司六十多個工程師在用Claude Code，而我們對它的管控，基本等于零。API密鑰散落在各個開發(fā)機的.bash_profile文件里，沒有集中可視的流量看板，不知道誰在調(diào)用哪些模型、花了多少錢、權(quán)限邊界在哪里。有人離職的時候，想收回Claude Code的訪問權(quán)，得先搞清楚他把密鑰寫在了哪臺機器上——這件事本身就不應(yīng)該成為一個問題。

Claude.ai那邊我們其實做得不差，SSO、域名捕獲、管理控制臺該配的都配了。但Claude Code完全是另一回事。它不是瀏覽器里的網(wǎng)頁應(yīng)用，是一個跑在終端里的工具，帶著開發(fā)者完整的文件系統(tǒng)權(quán)限，認證用的是一行API密鑰，不是瀏覽器的登錄會話。那些在Web層生效的管控手段，到它這里全部失效。審計結(jié)果已經(jīng)夠讓人冒汗了，而隨后爆出的兩個CVE直接把這事推到了必須立刻解決的位置。

2026年初，Check Point Research公布了兩項涉及Claude Code的漏洞，編號分別是CVE-2025-59536和CVE-2026-21852。前一個評分8.7，攻擊者可以在倉庫里埋一個惡意的.claude/settings.json文件，在Claude Code彈出信任對話框之前就執(zhí)行任意shell命令。在舊版本里，這個文件里定義的hooks會在啟動階段直接跑起來，用戶連確認的機會都沒有?？寺∫粋€攻擊者的倉庫，然后跑一句claude，開發(fā)機就被人拿了遠程執(zhí)行權(quán)限。后一個漏洞更讓人后背發(fā)涼。Claude Code通過環(huán)境變量ANTHROPIC_BASE_URL決定把API請求發(fā)往哪里，而惡意倉庫能用自己的settings文件覆蓋這個變量，把全部流量——包括攜帶著開發(fā)者API密鑰的認證頭——導(dǎo)向攻擊者控制的服務(wù)器。攻擊者再把請求代理轉(zhuǎn)發(fā)到Anthropic的正式接口，一切看起來正常運轉(zhuǎn)，開發(fā)者完全察覺不到，而你的密鑰已經(jīng)被人拿走了。

兩個漏洞現(xiàn)在都修了，CVE-2025-59536在v1.0.111版本中修復(fù)，CVE-2026-21852在v2.0.65版本中修復(fù)。但這件事情真正讓我一直琢磨的，不是漏洞本身，而是它們暴露出的那個底層假設(shè)。在此之前，我們所有人潛意識里都把.claude/settings.json當(dāng)成一份被動配置。它不是。在一個能跑shell命令、能調(diào)用外部API的代理類工具里，倉庫級別的配置文件本身就屬于執(zhí)行層的一部分。它的威脅模型應(yīng)該跟一個惡意的package.json里的postinstall腳本放在同一個等級去考慮。只是我們那會兒還沒轉(zhuǎn)過來這個彎。

沿著這個方向深挖下去，我們很快發(fā)現(xiàn)整個Claude Code的使用場景里，至少橫著四個必須填的坑。第一個是失控的API密鑰。開發(fā)者自己申請、自己配置，沒有任何統(tǒng)一的生命周期管理，離職、泄露、濫用全都沒法跟蹤，密鑰本身成了一個漂在組織外部、卻掛著內(nèi)部權(quán)限的幽靈憑證。第二個是流量完全不可見。誰在用Claude Code、用了多少次、調(diào)了哪些模型、消耗了多少token、費用落在哪個部門頭上，一概不知。第三個是文件系統(tǒng)權(quán)限的裸奔。終端里的工具天然能讀寫開發(fā)者能碰的所有文件，但沒有任何策略來約束它該碰什么、不該碰什么，也沒有審計記錄告訴你它到底碰了什么。第四個是MCP服務(wù)器完全不受管控，掛載了什么外部工具、數(shù)據(jù)源、第三方服務(wù)，安全團隊毫無感知，這些連接點本身就是擴大的攻擊面。

修補這四個坑，遠遠不只是把兩個CVE的補丁打上就完事了。它需要的是一套不同的心智模型，你得把Claude Code這類跑在終端里的AI工具，當(dāng)成一個有執(zhí)行能力的代理來對待，而不是當(dāng)成裝了智能補全插件的編輯器。倉庫層面的配置是執(zhí)行層輸入，API密鑰是需要托管和輪換的訪問憑證，文件系統(tǒng)訪問是需要策略約束的權(quán)限邊界，MCP服務(wù)器的掛載是需要審批和審計的外部集成點。想清楚這個定位之后，該怎么治，路徑才慢慢浮現(xiàn)出來。