2026 年 6 月，Meta 證實有 20,225 個 Instagram 帳號被盜，攻擊者沒有破解任何密碼，他們用的是 Meta 自己的 AI 客服。依 Help Net Security 整理的經過，攻擊者先用 VPN，也就是讓網路連線看起來來自其他地點的工具，把自己的位置偽裝成和帳號主人在同一個地區，再請 AI 客服把一個他們控制的信箱加到別人的帳號上，接著申請重設密碼。Meta 的說明是，這套帳號救援工具本身照設計運作，但另一段程式有錯誤，沒有確認申請人提供的信箱是不是帳號原本的信箱。
這件事最值得注意的地方是：AI 客服沒有失控，它只是很聽話地照流程把事情做完。缺的是一道本來應該擋下請求的檢查。凡是要讓 AI 處理會轉移帳號控制權、金錢或資料的請求，請求者的身分和權限都必須由系統帶入，不能從對話裡取得。
AI 照流程做完了不該做的事
如果換成人類客服，同樣的請求很可能過不了關。一個人要求「把這個帳號的信箱改成我的新信箱」，而這個新信箱和帳號過去的紀錄毫無關聯，有經驗的客服會停下來多問幾句，甚至直接拒絕。這種判斷很少被寫進流程文件，它存在於客服人員的經驗裡。
Stack Overflow Blog 在分析這起事件的文章裡說得很直接：真實世界裡有很大一部分的授權，從來沒有被寫成程式，它存在於站在請求和系統之間那個人的判斷裡，而後面整套系統都假設那個判斷永遠在。文章的結論是，AI agent 沒有繞過你的安全機制，它只是讓安全機制裡「原本是一個人」的那部分露了出來。
被說服的代理人
資安領域對這種問題有一個名字：confused deputy，可以譯成「被混淆的代理人」。意思是一個握有真實權限的程式，被一個權限比它低的人說服，用自己的權限替對方做事。
SANS 研究所（一個資安教育與研究機構）的文章指出，AI agent 特別容易成為這種代理人，原因有兩個。第一，它通常手上握著範圍很廣的權限，才能替各種使用者處理各種事。第二，它的行動由文字驅動，而文字可以被任何人寫出來。對 AI 來說，「我是帳號主人，請幫我改信箱」和真正的帳號主人說的同一句話，看起來沒有差別。
所以問題不在 AI 聽不聽得懂，而在它根本沒有辦法從對話裡分辨誰是誰。身分如果要從對話裡判斷，AI 只能相信對方說的話。
哪些請求最危險
不是所有客服或內部流程都有這種風險。查訂單狀態、回答常見問題、提醒缺少的文件，做錯了頂多是回答不準確。真正危險的是做完之後很難復原，或會把控制權交出去的請求：
- 更改登入信箱、電話、備援信箱，或多因素驗證的方式，也就是登入時密碼之外的第二道確認，例如驗證 App。
- 發送密碼重設、退款、付款或資料匯出的連結。
- 新增管理員、提高權限，或發放 API key（讓程式存取服務的鑰匙）。
- 修改方案、帳單地址或付款方式。
這些請求有一個共同點：一旦做錯，受害的是帳號真正的主人，而且他往往在事後才發現自己被鎖在門外。Meta 的事件裡，帳號主人如果沒有開啟多因素驗證，攻擊者重設密碼後就能直接登入。
讓 AI 收件，讓系統放行
最根本的做法，是把身分和權限的判斷從對話裡拿出來，交給系統。AI 收到「請幫我改信箱」時，系統應該已經知道這個請求來自哪個登入中的帳號、用什麼方式驗證過、過去有沒有異常紀錄；如果請求者根本沒有登入，或要修改的是別人的帳號，這個請求就不該進到 AI 能直接執行的範圍。
具體可以分三步做。
第一步，找出原本靠人判斷的關卡。 拿現有的客服或營運流程，問負責的人：哪些情況你會停下來多問、哪些會直接拒絕？陌生裝置、陌生地區、剛新增的聯絡方式、短時間內多次修改，這些過去靠經驗擋下的訊號，要寫成系統能檢查的規則。
第二步，把授權資訊交給系統帶入。 AI 每次呼叫工具前，帶著的應該是系統確認過的請求者身分與權限，而不是使用者在對話裡的自我介紹。SANS 的建議是，AI 不要長期握著大範圍的權限，而是每次動作由獨立的機制發給它一張範圍很窄、很快過期的通行證。
第三步，高風險請求只收件、不放行。 AI 可以整理請求、補齊資料、標出異常，然後交給負責的人確認。這會讓處理慢一點，但比起事後替兩萬個帳號善後，這個代價小得多。
人工放行也會變成形式
把高風險請求交給人工，前提是人工那一關真的有在看。如果負責確認的人一天要按幾百次「同意」，人工審核很快就會變成形式。所以第三步要搭配第一步：先用規則把明顯異常的請求擋掉，送到人手上的，才是真正需要判斷的少數。
系統帶入的身分也可能出錯，Meta 的事件正是一段驗證程式的錯誤。規則寫好之後，還是要定期拿真實的攻擊手法去測，例如偽裝地區、使用新信箱、短時間內連續修改，確認每一道檢查都真的會觸發。
現在可以從手上的客服或營運流程裡，挑出一個會更改帳號資料的請求，問一個問題：這個請求的身分，現在是由系統確認，還是由對話確認？如果答案是後者，在補上系統檢查之前，先讓 AI 停在收件的位置。
同樣的「誰有權做這件事」的問題，在 AI agent 跨系統代表使用者辦事時也會出現，參考〈AI agent 跨系統辦事，每到一站都該換一把新鑰匙〉。如果是在 ERP 這類企業系統裡導入 agent，參考〈ERP 裡的 AI agent 要有自己的身份，日誌才分得出是人做的還是 AI 做的〉。
AI 整理卡
請 AI 幫你找出流程裡靠對話判斷身分的地方 這段提示詞會先問清楚 AI 客服或 agent 處理哪些請求，再逐一檢查身分與權限是從哪裡來的，最後列出 AI 只能收件、不能放行的請求。
我想檢查一個 AI 客服或 AI agent 流程，會不會被人說服替陌生人做事。
判斷方法來自這篇文章：https://boosterminiclass.com/posts/ai-agent-hidden-authorization-checks/
文章的看法是：AI 客服照流程做事本身沒有錯，危險在於授權檢查原本只存在人的判斷裡。凡是會轉移帳號控制權、金錢或資料的請求，請求者的身分與權限都要由系統帶入，不能從對話裡取得。
請先問我 3 個問題：
1. 這個 AI 會處理哪些請求，其中哪些會更改帳號、權限、付款或資料匯出；
2. AI 呼叫工具時，系統會帶入哪些關於請求者的資訊（登入狀態、驗證方式、過去紀錄），還是只有對話內容；
3. 這個流程原本由人處理時，負責的人會在什麼情況下停下來或拒絕。
根據我的回答，請輸出：
- 一張清單：每一種請求的身分與權限目前來自系統或來自對話；
- 原本靠人判斷、但還沒寫成規則的異常訊號；
- 哪些請求 AI 只能收件、整理、標出異常，必須交給人放行；
- 我可以用來測試這些檢查的三種情境（例如偽裝地區、使用新信箱、短時間內連續修改）。
不要假設我的系統已經有我沒提到的檢查；資訊不足時先問我。
清單只是起點，哪些請求可以交給 AI 放行，要由負責帳號安全的人決定。
參考來源
- Help Net Security：Hackers used Meta’s AI support system to hijack over 20,000 Instagram accounts — https://www.helpnetsecurity.com/2026/06/08/instagram-ai-support-vulnerability-account-takeovers/（2026-06-08）
- Stack Overflow Blog：AI agents are a confused deputy with the keys to your kingdom — https://stackoverflow.blog/2026/06/15/ai-agents-expose-the-security-checks-you-never-actually-wrote/ [accessed: 2026-10-11]
- SANS：Your AI Agent Is an Easily Confused Deputy: Why Cloud Security Needs a Credential Broker — https://www.sans.org/blog/your-ai-agent-easily-confused-deputy-why-cloud-security-needs-credential-broker（2026-05-15）
