Meta 這次在 Instagram 帳號安全上栽的跟頭，說穿了不是 AI 太聰明，而是寫代碼的人太想當然。他們家那個 AI 聊天機器人確實照著指令工作了，壞就壞在驗證邏輯跟 AI 之間隔了一層紙，而這層紙被攻擊者輕易捅破。這不是什麼好萊塢電影裡的黑客攻防，純粹是系統在處理密碼重置請求時，AI 沒去確認那個接收郵件的地址到底是不是帳號本人的。這種「自動化漏洞」最諷刺的地方在於，工具本身運作得非常完美，它只是太聽話，聽話到把家門鑰匙遞給了任何一個開口要鑰匙的陌生人。
現在的問題在於，我們給了這些 AI 聊天機器人太高的權限，卻沒給它們足夠的防護意識。在 ChatGPT 的開發文檔裡，OpenAI 一直在強調 Function Calling 的安全性，但實踐中，當你把 GPT-4o 接入一個龐大的遺留系統，API 接口的權限校驗往往會出現斷層。攻擊者不需要寫任何代碼，他們只需要用自然語言去「說服」AI 繞過那個沒寫好的校驗路徑。這不是 AI 的 bug，這是系統架構的傲慢。開發者總以為 AI 只是個翻譯官，沒想到這位翻譯官在翻譯的同時，順便幫外人把金庫門給開了。
在處理這類敏感操作時，Claude 的做法顯然比 ChatGPT 謹慎得多。Anthropic 在設計 Claude 3.5 Sonnet 時，對於涉及用戶隱私數據的工具調用，有一套更為嚴格的對齊協議。如果你試圖引導 Claude 去修改一個它無法確權的系統參數，它更傾向於直接拒絕，而不是像 Meta 的 AI 那樣「熱心腸」地幫你完成。這種謹慎在產品經理眼裡可能是「用戶體驗不佳」，但在安全架構師眼裡，這是救命的保險絲。Gemini 在這方面則顯得有些搖擺，雖然它背靠 Google 強大的安全體系，但在處理多步邏輯推理的授權請求時，依然偶爾會出現邏輯幻覺，把權限邊界搞模糊。
相比之下，DeepSeek 在架構設計上的邏輯層次感也經常被開發者拿來討論。當我們回頭看 ChatGPT 的插件生態，OpenAI 其實走過一段彎路。早期的插件模式幾乎是把權限全權委託，後來的 Actions 才開始強調 OAuth 的強制性。Meta 這次的災難，本質上是把一個具備高權限的 AI 扔進了一個驗證邏輯有漏洞的舊池子裡。Grok 在 X 平台上的權限控制則更為粗獷，它幾乎能訪問所有的實時數據，但這也意味著如果它的 API 調用鏈條出現類似 Meta 的「郵件不匹配」漏洞，其造成的帳號連鎖反應會比 Instagram 更加難以收拾。
很多公司現在迷信所謂的「AI 取代人工客服」，覺得這樣能省下大筆的人力成本。但他們忘了，人工客服雖然慢，但至少知道在改密碼前看一眼後台數據是否對得上。Meta 把這部分邏輯交給了代碼路徑，而這條路徑恰好沒跟 AI 溝通好。這就像你請了一個會說五十國語言的管家，卻沒告訴他不能隨便把鑰匙給路人。Qwen 在某些特定垂直領域的處理邏輯也展現過類似的工具調用特性。
如果我們繼續把 AI 當作一個「萬能接口」來使用，而不去重新審視後台那些腐爛的代碼邏輯，Instagram 的悲劇只會是個開端。當 AI 具備了操作真實世界的權力，我們是否真的準備好了一套能防住「語言攻擊」的防火牆？還是說，我們只能一邊享受著自動化的便利，一邊祈禱下一個被盜的帳號不是自己的？當技術的邊界變得模糊，權限的歸屬究竟該聽 AI 的判斷，還是回歸到那幾行枯燥但絕對的安全代碼手裡？