Agent Memory 是什麼？

LLM 本身不是真的像人類一樣把所有對話永久記在腦中，實際的 AI Application 通常需要透過額外的系統把需要長期使用的資訊保存起來，之後再取回並放進 Context，例如使用者曾經告訴 AI 自己寫程式主要使用 JavaScript，下一次使用者要求幫忙寫 api 時，Application 就可以把之前的 Memory 取出來，讓 LLM 知道使用者偏好 JavaScript，所以 Memory 就是說把過去的重要資訊保存起來，在未來需要時再次提供給 LLM。

Memory 為什麼會有 Security 問題？

因為 Memory 最後會再次影響模型，跟前面其實很像，有段惡意內容被植入後可能當下沒有造成任何事情，但如果它成功進入長期 Memory，未來 Agent 再次讀取這段內容時，就可能重新影響模型，這類風險可以稱為 Memory Poisoning（記憶投毒）。

Memory Poisoning 跟 Prompt Injection 有什麼不同？

Prompt Injection 通常是在目前這次互動中影響模型，Memory Poisoning 更麻煩的地方在於惡意內容可能被保存下來，之後再次進入模型的 Context，也就是說攻擊可能具有一定的持續性，這跟前面介紹的 Data Poisoning 也有一點相似，但被污染的不是 Training Data，而是 Agent 使用的 Memory。

2025 年一篇名為 MINJA（Memory Injection Attacks on LLM Agents） 的研究，就專門探討具有長期 Memory 的 LLM Agent 是否可能遭到 Memory Injection Attack，研究者展示了一種情況，攻擊者不一定需要直接修改 Memory Database，而是可以透過與 Agent 的互動，嘗試讓惡意內容被系統當成有用資訊保存進 Memory，之後再影響 Agent 的回答，重要的點就在於攻擊者不一定需要駭進資料庫才能污染 Memory，如果 Application 本身就允許模型自動判斷哪些內容值得記住，那麼「讓 AI 記住什麼」本身就可能成為攻擊目標。

最直接的防禦方式就是不要把所有內容都自動寫進 Memory，例如：

function saveMemory(content) {
  if (!validateMemory(content)) {
    return;
  }
  memoryStore.save(content);
}

這裡的 validateMemory() 可以檢查資訊是否需要長期保存嗎、來源是否可信、是否包含敏感資訊、是否包含疑似指令或惡意內容等等，也就是 Memory Write 也需要 Validation，當然除了寫以外讀也很重要，誰可以讀也是一樣很重要的問題，假設公司建立了一個 AI Agent，Memory 裡同時保存不同使用者的資料，原本這樣的資料：

User A → User A Memory
User B → User B Memory

若控制權現出了問題變成 User A → User B Memory，這時候就可能造成 Sensitive Information Disclosure，所以 Memory 一樣需要前面介紹過的 Authentication、Authorization 與 Least Privilege，不能因為資料是 AI Memory，就跳過原本 Web Application 應該有的權限控制。

Memory 不應該變成另一個 Secret Storage

另外當然不能拿 Memory 可以長期保存資料的特性去存 api key 等的 secret，Memory 不是 Secret Manager，API Key、Password、Token 等憑證還是應該交給專門的 Secret Management 機制處理，而不是讓 LLM 把它們當成記憶。

Memory 可以讓 AI Agent 在不同時間的互動之間保留重要資訊，讓 Agent 不需要每次都重新認識使用者或任務，但從 Security 的角度來看只要一份資料未來還會再次影響 AI，它就值得被保護，所以除了保護 User Input、Tool 與 RAG Knowledge Base，我們也要注意什麼內容可以寫入 Memory、誰可以修改、誰可以讀取，以及 Memory 之後會如何影響模型，否則一次惡意輸入可能不只是影響現在這一次回答，而是被保存下來，在未來再次影響 Agent。

下一篇：Day 26｜AI Supply Chain Security：我們使用的 Model、套件與外部服務都可信嗎？