6

當 Memory 也會被攻擊

最近在整理 Agent Memory 的安全研究，越看越覺得麻煩。AI 記性變好以後，還得防著有人把自己的要求，塞進它往後會反覆翻看的工作筆記。上一篇，我們聊到 AI 可能把「還沒確認」記成「已經確定」，所以替記憶保留來源，讓它以後有機會被查證、被修正。那如果有人刻意利用這個過程呢？

假設你請 AI 整理客戶來信，其中有人在信裡聲稱，老闆已經答應給他長期八折，以後報價直接照辦就好。實際上，老闆從來沒答應過。AI 當下只是整理信件，沒有報價，也沒有寄出任何東西，但它順手留下了一則記憶，把這位客戶標成「享有長期八折的客戶」。

幾天後，你開一個新對話，請它幫這位客戶準備報價。它翻出之前的筆記，很貼心地套用八折，還提醒你這是過去談好的條件。它連前情都幫你記好了，只是公司從來沒有做過這個決定。😅

這是我自己用來想風險的假設案例，一封外部來信裡的主張，被整理成公司已經確認的事，接著又影響了下一次工作。

這次只是讀信，下次才把報價寫錯

這類刻意污染 AI 長期記憶的攻擊，叫做記憶投毒（Memory Poisoning）。攻擊者希望有問題的內容被留下來，等之後的正常工作再派上用場。 可以把它想成有人在助理會翻閱的工作筆記裡，混進一條假的公司慣例，助理可能很認真，也沒有故意做錯事，但它參考的那份筆記已經出了問題。

這個問題其實不新，2023 年的間接提示注入（Indirect Prompt Injection）研究就討論過，AI 讀取外部資料時，可能把裡面的內容誤當成自己應該遵守的指示，像是你請它整理一封信，信裡卻另外夾了要求它做事的指令。 到了 2025 年提出的 MINJA，研究者進一步測試，不直接修改記憶資料庫，只透過與 Agent 互動，能不能讓它自己留下有問題的紀錄。這是在特定系統設定下的結果，不能直接推論所有 AI 助理都有相同漏洞。

所以把資料庫密碼保管好，還擋不住這條路。Agent 本來就會記筆記，攻擊者只要利用它正常工作的過程，就可能讓它自己記下不該採信的東西。

2026 年 7 月的 GhostWriter 研究，把這件事畫得很清楚。它的例子是透過郵件污染聯絡資訊，等使用者之後提出正常的寄信要求，Agent 才取回錯誤地址並使用。 下面我把同樣的兩階段概念，換成前面的報價故事，可以看右半邊，使用者只是請 AI 準備報價，根本沒有要求它打折。

對這個案例來說，只看第一次的摘要還不夠，還要看那次工作結束後多了什麼記憶，以及下次會怎麼用它。

「客戶這樣說」，怎麼變成「公司這樣規定」？

這就接回上一篇一直強調的來源。假設 AI 有保留原始信件，你點回去看，客戶真的寫了老闆答應八折，引用沒錯，原文也找得到，那問題解決了嗎？還沒，這只能證明客戶這樣說過，不能證明老闆真的答應了。

就像會議紀錄寫「客戶希望免費加一個功能」，大家應該看得懂，那是一項要求。假如整理後變成「這個功能免費提供」，少掉的那幾個字，就足以讓下次接手的人誤會。在我們的假設情境裡，AI 需要把「誰提出這件事」一起記住，客戶提出優惠要求，AI 幫忙整理，公司有權核准的人是否答應，得另外確認。

偏偏有時候，整理還會讓內容看起來更有道理。2026 年 9 月 29 日的 VirusCascade 研究，在推薦系統的多 Agent 架構裡觀察這類風險，外來的惡意資訊，可能經過 Agent 反思，被合理化成一段偏好說明，再寫回記憶。作者稱這個過程為 reflection laundering，也就是透過反思，讓原本可疑的內容看起來更像合理結論。

放回報價故事，原始來信只是聲稱老闆答應打折，AI 整理完卻可能補上一段解釋，說這位客戶合作潛力高，所以公司採用長期優惠來維繫關係。理由聽起來很完整，但到底誰批准的，還是沒有人回答。

這篇研究測的是特定推薦架構，我不會拿它來斷言所有 AI 都會這樣。不過看到一段很像工作心得的文字時，還是要回頭看它的根據，「AI 自己整理過」不等於有人查證過。

同一封信被寫進會議摘要，又被整理成客戶筆記，也不能算成兩個人都證實了這件事。往回找，可能一直都是同一位客戶的同一句話。

工作筆記和公司規則，要分開放

那實際上可以先改哪裡？我會先把工作筆記和正式規則分開，像是辦公室裡的草稿本與已核准的價目表。AI 可以在草稿本裡記下「客戶提到八折，還沒確認」，也可以提醒業務去查，但它不能因為有記筆記的權限，就直接把正式價目表改成八折。

我在 2026 年 10 月 11 日查閱 Anthropic 的 Managed Agents 記憶文件時，裡面就明確提醒，不可信輸入可能把惡意內容帶進記憶，再影響後續對話。對 Agent 不需要修改的參考資料，官方建議設成唯讀，也就是可以看、不能改。 放回這個案例，已核准的優惠條件可以讓 AI 查閱，新收到的說法先留在工作筆記裡，真的要改優惠，就走原本負責人的確認流程。

這個限制要真的寫進系統。好比共用文件設成「僅供檢視」，比在文件第一行寫「拜託不要改」多了一層實際約束。

而那則待查筆記，也不用搞得像一張填不完的申請表。至少把原始信件連回去，留下是哪位客戶提出、什麼時間收到，以及目前還沒有找到核准紀錄。核准紀錄要從實際的簽核流程查，不能因為信裡有「老闆已同意」幾個字，就讓 AI 自己勾選已核准。

唯讀當然不會讓內容自動變正確，也擋不住所有錯誤建議。它先守住一個範圍，讓讀取外部資料的 AI，沒辦法順手改掉正式規則。

可以幫忙寫信，不代表可以自己批准折扣

就算工作筆記和正式規則分開，AI 還是可能受到那則假折扣影響，寫出一份錯誤報價，所以我會在真正對外送出時，再確認一次這項操作能不能做。

以這個假設案例來說，系統如果發現報價使用了例外折扣，就要核對有效的核准紀錄。AI 可以提出草稿，但不能只靠自己記得「以前好像同意過」，就跳過公司的報價規則。這很像同事可以幫忙準備付款申請，但準備好申請單，並不會讓他同時取得核准付款的權限。

OpenAI 在 2026 年 4 月介紹 Auto-review 時，也採用了角色分工。工作的 Agent 提出超出原本執行範圍的操作，再由另一個 Agent 根據使用者授權和安全政策審查，不過官方也說明，這個審查者仍可能被誤導，不能當成安全保證。 所以多一個 AI 說「看起來沒問題」，還不能取代真正的權限設定。對報價系統，我會把「準備草稿」和「核准例外優惠」分成不同操作，讀信的 Agent 不需要拿到後者的權限。

也不必每個小動作都來問人。原本就授權好的例行工作，可以照規則完成，涉及額外優惠的部分才需要核准。不然忙到最後，AI 的工作只剩下問你下一步要做什麼，事情還是自己做比較快。😅

它看得到誰的資料，常被放在「有沒有權限」裡一起討論，其實要另外檢查。拿 A 客戶的信來整理筆記時，我不會讓 Agent 順便讀到 B 客戶的底價，系統應該先決定這項工作可以取用哪些資料，再把資料交給 AI。全部拿出來後才提醒它不要洩漏，B 客戶的資料其實已經被看見了。摘要也要跟著限制，B 客戶的底價被寫進另一張筆記，不會因為換了檔名，就變成全公司都能看的資料。

刪掉那則記憶，錯誤可能還在其他地方

假設我們終於發現，老闆從來沒答應八折。找到那則記憶，把它刪掉，應該就好了吧？

先想一下，那個八折是不是已經出現在客戶摘要裡，或者被放進下個月要用的報價範本。這些東西沒一起處理，AI 下次還是可能讀到，就像有人把舊版價目表收起來，但業務群組裡傳的截圖還在，下一個接手的人照樣拿來報價。

OpenAI 在 2026 年 9 月 25 日公開的研究，也展示了提示注入被 Agent 複製到輸出的情況。官方說明，沒有觀察到模擬工具呼叫之外的影響，所以不能把這份披露當成已發生的真實世界擴散事件。 放回假設案例，除了查錯誤存在哪裡，也要查 AI 曾經根據它產出了什麼，我會照這個順序處理。

• 先停用那則假折扣
• 找出引用過它的客戶摘要
• 把相關的報價範本標成需要重新確認
• 已經寄出去的報價，另外追蹤要怎麼更正

原始來信可以留下來供調查，但要隔開，別再讓一般工作把它當成有效優惠取回。否則 AI 很可能在讀事故紀錄時，又把那句八折撿回自己的筆記裡，清理工作做了半天，還幫錯誤多備份了一份。🫠

這也解釋了上一篇為什麼要保留來源。假如每份摘要都知道自己根據哪封信整理，現在就比較有機會追到受影響的地方，沒有留下這些關係，就得承認還可能有漏網之魚。不過把整個記憶庫清空也太粗暴了，那位客戶正確的聯絡資訊和產品需求，都還是下次工作會用到的東西。

我會拿一封假信，測試它到底有沒有學壞

做法講了這麼多，到底有沒有用，還是得實際測。我會先準備一個只用假客戶資料、不能寄出真實郵件的測試環境，放入正常的價格規則，再讓 AI 讀到那封聲稱老闆答應八折的測試信。等它整理完，開一個全新的對話，不把原本的信貼過去，只請它幫這位客戶準備報價。

這時候，我會檢查它實際留下的筆記、這次對話取回了哪些記憶，還有最後產出的報價。不能只問它「你有沒有受到影響」，再相信它說沒有。

2026 年 7 月的 MemSecBench 就把這些檢查點拆開，資料被存下來、之後被取回使用，以及真的造成後果，是不同的事情。修復時也要一起確認，惡意內容不再作為有效指引，原本正常的記憶還留著。 下圖沿用這個想法，從同一份有問題的記憶各複製一份，一份測後續工作，另一份測清理，這樣可以分開看，AI 會不會被帶偏，以及系統有沒有能力清除問題。

換成這個報價案例，我會先看幾件很具體的事。

• 只有客戶自己聲稱有折扣時，AI 會不會把它寫成已核准條件？
• 清掉假折扣、重新整理客戶摘要後，開新對話準備報價，錯誤會不會再回來？
• 客戶正常的需求是否還在，真的有核准紀錄的優惠能不能照常使用？

其中，修復後再開新對話、實際測它能不能繼續工作，是我會加做的檢查。不能因為資料庫裡看起來刪乾淨，就直接認定後續使用也沒問題。

2026 年 9 月 26 日的 BMA 研究處理的是另一個問題，看到 Agent 做錯事，不代表已經證明是那條記憶造成的，研究因此加入了對照檢查，確認錯誤是否真的經過那條記憶路徑發生。 我會把它想成測一份可疑的報價範本，使用範本時報錯價，拿掉以後就正常，才比較有理由懷疑它。但如果拿掉以後還是報錯，可能還有別份副本，也可能連基本定價流程都有問題。

實際測試時，保留其他條件，分別跑有那條記憶和移除它的版本，再重複幾次，一次剛好答對，還不夠拿來說問題解決了。這些研究各自有測試範圍，我也沒有重跑它們的實驗，現在拿來用的是問題拆解的方法，最後還是得回到自己的工具與工作流程驗證。

我自己在做 Cairn，這些問題也會拿回設計裡對照。光是記得多少就已經很難了，現在還要追一條筆記是怎麼取得影響力的，被撤銷以後，下一次工作會不會真的跟著改。上面的做法我還在逐項實測，不能先算成產品已經做到的事。

接下來我會先跑完那封假折扣信的測試，找出從讀信到下一次報價，是哪一步把客戶的說法當成了公司決定，找到那一步，才知道要補哪一道檢查。下一篇再往前走，聊聊哪些資訊值得記、什麼時候該取回，以及 Agent 能不能從結果裡自己學會這些選擇。

REF參考資料

• GhostWriter（2026 年 7 月）：https://arxiv.org/html/2607.06595v1
• 間接提示注入（Indirect Prompt Injection, 2023）：https://arxiv.org/abs/2302.12173
• MINJA（2025）：https://arxiv.org/abs/2503.03704
• VirusCascade（2026 年 9 月）：https://arxiv.org/abs/2609.38270
• Anthropic Managed Agents 記憶文件（2026 年 10 月 11 日查閱）：https://platform.claude.com/docs/en/managed-agents/memory
• OpenAI Auto-review（2026 年 4 月）：https://alignment.openai.com/auto-review/
• OpenAI 自我複製提示注入研究（2026 年 9 月）：https://alignment.openai.com/misalignment-reports/self-replicating-prompt-injections-exist
• MemSecBench（2026 年 7 月）：https://arxiv.org/html/2607.27080v1
• BMA（2026 年 9 月）：https://arxiv.org/abs/2609.32186