대부분의 프롬프트 인젝션 (Prompt-injection) 논의는 단 한 번의 잘못된 턴을 가정합니다. 즉, 오염된 웹 페이지나 문서가 모델의 컨텍스트 (Context)에 명령어를 몰래 끼워 넣고, 모델이 해서는 안 될 행동을 수행하면 세션이 종료된다는 가정입니다. 컨텍스트를 비우면 문제는 사라집니다.

지속성 메모리 (Persistent memory)는 이러한 가정을 깨뜨립니다. 에이전트 메모리 (Agent memory)의 핵심 목적은 한 세션에서 작성된 내용이 다음 세션까지 유지된다는 점입니다. 따라서 만약 주입된 명령어가 메모리에 기록된다면, 그것은 세션 종료와 함께 끝나지 않습니다. 공격자가 더 이상 근처에 없는 대화에서도 에이전트가 해당 메모리를 검색할 때마다 컨텍스트로 다시 유입됩니다. 단 한 번의 인젝션 (Injection)이 지속적인 인젝션이 되는 것입니다.

메모리가 어떻게 단일 인젝션을 반복적인 인젝션으로 만드는가

그 메커니즘은 매우 평범하며, 바로 그 점 때문에 간과하기 쉽습니다. 에이전트가 공격자의 영향을 받은 콘텐츠(페이지, 파일, 도구 결과 등)를 읽습니다. 그 콘텐츠에는 명령어가 포함되어 있습니다. 정상적인 경우라면 해당 명령어는 컨텍스트 윈도우 (Context window)가 비워질 때 사라질 것입니다. 하지만 에이전트에 메모리 기능이 있고, 해당 명령어가 스스로를 저장하도록 구성되어 있다면(예: "이것을 기억해"라는 지시어, 또는 에이전트가 성공적인 경험으로 기록해 두는 오염된 기록), 이제 그것은 영구 저장소 (Durable storage)에 살아남게 됩니다.

그때부터는 검색 (Retrieval)이 공격자의 역할을 수행합니다. 이후의 작업이 해당 메모리를 불러올 만큼 유사할 때마다, 오염된 항목이 컨텍스트로 다시 돌아오며 에이전트 자신의 이전 지식이나 행동으로 취급됩니다. 악성 사이트에 두 번 방문할 필요조차 없습니다. 여기서 무너지는 신뢰 경계 (Trust boundary)는 에이전트의 추론 (Reasoning)과 에이전트 자신의 이력 사이의 경계입니다. 에이전트는 자신의 메모리가 '자신의 것'이기 때문에 신뢰할 수 있다고 가정합니다.

이것이 바로 검색 증강 생성 (RAG, Retrieval-Augmented Generation)이 동일한 공격 표면 (Attack surface)을 공유하는 이유이기도 합니다. RAG와 에이전트 메모리는 동일한 패턴을 따릅니다. 즉, 유사도에 따라 저장된 콘텐츠를 가져와 프롬프트 (Prompt)에 삽입하는 방식입니다. 저장소가 "문서"를 보유하든 "과거의 경험"을 보유하든, 저장소에 담긴 후 나중에 검색되는 모든 것은 신뢰할 수 있는 입력값으로 취급됩니다. 저장소를 단 한 번만 오염시키면, 이후에 발생하는 의미론적으로 일치하는 모든 쿼리 (Query)가 그 독성을 물려받게 됩니다.

두 가지 구체적인 사례

SPAIware는 이를 입증한 사례입니다. 2024년, 보안 연구원 Johann Rehberger (Embrace The Red)는 신뢰할 수 없는 웹사이트를 통해 전달된 프롬프트 인젝션 (Prompt injection)이 ChatGPT의 장기 메모리 (Long-term memory)에 공격자가 제어하는 명령을 기록할 수 있음을 보여주었습니다. 이러한 메모리는 서버 측 (Server-side)에 저장되었기 때문에 세션, 기기, 대화 초기화 여부와 관계없이 유지되었습니다. 심어진 명령은 ChatGPT에게 향후의 대화 내용을 유출하도록 지시했습니다. 즉, 이후의 모든 채팅은 보이지 않는 이미지 렌더링 (Image rendering)을 통해 공격자의 서버로 조용히 전송되었습니다. 그는 2024년 6월에 이 사실을 OpenAI에 보고했고 9월에 공개했습니다. OpenAI는 ChatGPT macOS 1.2024.247 버전에서 유출 채널에 대한 수정 사항을 배포했으나, 메모리 인젝션 (Memory-injection) 단계 자체는 여전히 가능했습니다. The Hacker News가 이 공개 내용을 보도했습니다.

MemoryGraft는 자율 에이전트(autonomous agents)를 대상으로 하는 동일한 아이디어를 학술적으로 일반화한 것입니다. 해당 논문(arXiv:2512.16962, Srivastava 및 He)은 사실적 지식 베이스(factual knowledge base) 대신 RAG(Retrieval-Augmented Generation) 기능이 활성화된 에이전트의 경험 검색(experience retrieval) 시스템을 목표로 합니다. 에이전트가 알고 있는 내용을 공격하는 대신, 에이전트가 이전에 효과적이었다고 생각하는 내용을 공격합니다. 즉, 검색된 성공적인 작업의 패턴을 복제하려는 에이전트의 경향성인 "의미론적 모방 휴리스틱(semantic imitation heuristic)"을 악용합니다. 공격자는 에이전트가 정상적인 작동 중에 흡수하고 성공적인 경험으로 기록하도록 무해해 보이는 아티팩트(artifacts)를 심어둡니다. 이후 검색 과정에서 이러한 이식된 메모리(grafted memories)가 표면으로 드러나면, 에이전트는 내장된 안전하지 않은 행동을 채택하게 됩니다. GPT-4o를 사용한 MetaGPT의 DataInterpreter 에이전트를 통해 검증한 결과, 소수의 오염된 기록만으로도 일반적인 워크로드에서 검색되는 경험의 상당 부분을 차지할 수 있음을 발견했습니다. 이는 반복적인 공격 없이도 세션을 넘나들며 지속적으로 발생하는 행동 드리프트(behavioral drift)를 유발합니다. 주목할 점은, 그 트리거(trigger)가 에이전트 자체의 자기 개선 루프(self-improvement loop)라는 것입니다.

실무자 시사점 (Practitioner takeaway)

만약 사용 중인 에이전트에 지속적인 메모리(persistent memory)가 있거나, 읽기 및 쓰기가 모두 가능한 RAG 저장소(RAG store)가 있다면, 메모리 쓰기 작업을 단순한 부수 효과(side effect)가 아닌 신뢰할 수 없는 입력(untrusted input)으로 취급하십시오.

초기에 도입할 가치가 있는 세 가지 제어 방안은 다음과 같습니다:

• 인스턴스 또는 유형별로 메모리 범위(Scope)를 지정하십시오. 한 사용자, 테넌트(tenant) 또는 작업 범주를 처리하는 동안 작성된 메모리가 관련 없는 다른 범주로 조용히 재진입해서는 안 됩니다. 범위를 엄격하게 제한하면 폭발 반경(blast radius)을 줄여, 오염된 항목이 에이전트의 모든 곳을 따라다니지 못하게 할 수 있습니다.
• 인젝션 시그니처(injection signatures)를 기준으로 쓰기 작업을 검증하십시오. 메모리를 쓰는(writing) 작업에 대해서도 인바운드 프롬프트(inbound prompts)에 적용하는 것과 동일한 정밀 조사를 적용하십시오. 데이터가 영구 저장되기 전에 내장된 지침, 데이터 유출 지시(exfiltration directives), 그리고 "항상 ...하는 것을 기억해라"와 같은 패턴이 있는지 확인하십시오. 처리 비용이 가장 저렴한 오염된 항목은 아예 저장하지 않은 항목입니다.
• 항목별 출처(provenance)를 유지하십시오. 각 메모리가 어디에서 왔는지 — 어떤 세션, 어떤 소스, 어떤 검색된 문서인지 — 기록하십시오. 출처가 없다면 정당한 메모리와 이식된(grafted) 메모리를 구분할 수 없으며, 사고 발생 후 가장 중요한 질문인 "어떤 항목이 오염되었으며, 정확히 그 항목들만 어떻게 제거할 것인가?"에 답할 수 없습니다.

이러한 방안들이 중요한 이유는 비대칭성 때문입니다. 단발성 인젝션(one-shot injection)은 컨텍스트(context)를 비우는 것으로 차단할 수 있습니다. 하지만 메모리 포이즈닝(memory-poisoning) 인젝션은 해당 인젝션이 남긴 특정 항목을 찾아내어 제거할 수 있을 때만 차단됩니다. 그리고 이는 사고가 발생하기 전에 이를 대비하여 시스템을 구축했을 때만 가능합니다.

이 연구는 자율 AI 에이전트 보안을 위한 개방형 및 벤더 중립적 프레임워크인 *BRACE*의 근거 자료 중 하나입니다. BRACE의 런타임 가이드(run-time guide)는 메모리 위생(memory hygiene)인 범위 지정(scoping), 쓰기 검증(write validation), 항목별 출처(per-entry provenance)를 다룹니다. BRACE는 각종 사고 사례와 연구를 검토하며, 매번 "어떤 구체적인 제어 방안이 이를 방지하거나 차단할 수 있었을까?"라는 질문을 던지며 구축되었습니다._