TL;DR

• AI 에이전트의 영속 메모리(Persistent Memory)는 Memory Poisoning(OWASP ASI06)의 표적이 됩니다.
• OWASP가 공개한 Agent Memory Guard는 메모리에 대한 read / write를 모두 검사하는 런타임 방어 계층(Runtime Defense Layer)입니다.
• 본 기사에서는 mem9(TiDB 팀이 제작한 에이전트용 영속 메모리 기반)를 Agent Memory Guard를 통해 공개하는 MCP 서버를 만들었습니다.

배경

TiDB와 mem9에 대해 조사 및 공부하는 과정에서, AI 에이전트 시대에 요구되는 메모리의 위치가 무엇인지 알게 되었습니다.

• AI 에이전트 간에 공유할 수 있는 것
• 시간이라는 문맥(Context)에 대응할 수 있는 것 (오래된 기억의 감쇠, "언제 시점의 정보인가"를 고려한 회상)
• 메모리의 취사선택 (무엇을 망각할 것인가, 무엇을 정리하여 남길 것인가)
• 대량의 AI 에이전트 액세스에 대응할 수 있는 확장성(Scalability)

AI 에이전트 간에 공유 가능한 메모리를 마련함으로써 AI 에이전트 간의 인식 차이가 해소되고, 결과물의 품질에 긍정적인 영향을 미친다는 것이 연구를 통해 밝혀졌습니다.

한편으로 AI 에이전트의 메모리에 대한 위협도 존재한다는 것을 이해했습니다. 한 예로 Microsoft가 보고한 AI Recommendation Poisoning을 소개합니다.

기사의 내용을 간단히 소개하자면, 웹 페이지에 배치된 "AI에게 요약하게 만드는" 링크나 버튼에 지시 사항을 심어두어, 클릭한 사용자의 AI 어시스턴트(Copilot이나 ChatGPT 등)에게 "이 사이트를 신뢰할 수 있는 정보원으로 기억하라"고 메모리에 쓰게 만드는(Write) 공격이 실제로 관측되고 있다는 것입니다. Microsoft의 조사에 따르면 60일 동안 31개 기업에 의해 50건의 오염된 프롬프트(Poisoned Prompt)가 확인되었으며, 대상은 14개 업종, 특히 금융·의료·법률과 같이 중요한 판단이 개입되는 분야가 표적이 되었습니다.

이 사례는 Memory Poisoning이 왜 위험한지를 잘 보여줍니다. 일반적인 프롬프트 인젝션(Prompt Injection)의 효과는 해당 대화에 한정되지만, 메모리에 들어온 오염은 대화를 넘나들며 참조될 때마다 계속해서 발화합니다. 사용자가 눈치채지 못하는 사이에, 이후의 추천이나 판단이 지속적으로 편향되어 버리는 것입니다.

OWASP에 의한 분류

*출처: OWASP Top 10 For Agentic Applications 2026,
OWASP Gen AI Security Project - Agentic Security Initiative,
licensed under CC BY-SA 4.0.

이러한 위협이 등장하게 된 배경도 있어, OWASP는 memory poisoning을 ASI06: Memory & Context Poisoning으로 정식 분류했습니다.

또한 동시에, 이 공격에 대한 방어 구현으로서 최근(2026년 6월) OWASP에 의해 Agent Memory Guard라는 OSS가 공개되었습니다.

Agent Memory Guard란

agent-memory-guard

is a runtime defense layer that screens every read and write to your AI agent's memory, blocking prompt injection, secret leakage, and integrity tampering before they corrupt agent behavior across sessions.

위 리포지토리의 README에서 인용한 바와 같이, Agent Memory Guard는 에이전트의 메모리에 대한 읽기/쓰기 전 단계에 위치하는 방어 계층입니다. 프롬프트 인젝션, 비밀 정보(Secret) 유출, 변조로부터 보호해 줍니다.

간단한 구조

AI 에이전트로부터의 메모리 쓰기·읽기에 대해 Agent Memory Guard가 중개인이 되어, 자체적으로 갖춘 탐지기(Detector)를 사용하여 메모리의 이상을 탐지합니다.

검지 대상

검지 대상은 아래 테이블과 같습니다.

| Excessive Autonomy | 쓰기 / 읽기 모두 ※명시적으로 탐지기에 추가한 경우 |
인간의 확인, 승인, 예산, 횟수 제한, 도구 제한 등을 메모리를 통해 무효화하여, 에이전트의 자율성 (Autonomy) 을 과도하게 확장하는 공격입니다. 목표는 본래 인간의 승인이 필요한 조작을 에이전트가 임의로 실행할 수 있는 상태로 만드는 것입니다. 예를 들어 human_in_the_loop=false, auto_approve=true, max_iterations=unlimited, use any tool, rate_limit=disabled와 같은 값을 저장하게 하는 케이스입니다. 이는 OWASP LLM Top 10의 Excessive Agency와 유사한 문제로, 인간의 감독 (human oversight) 무효화, 무제한 반복, 자동 승인 (auto approve), 확인 회피, 예산 제한 해제, 무제한 도구 이용, 에이전트 생성 (agent spawning) 등을 탐지합니다. |
| ML-Based Detection | 쓰기 / 읽기 모두 ※명시적으로 탐지기에 추가한 경우 |
정규 표현식으로는 탐지하기 어려운, 바꾸어 말하기(Paraphrasing), 난독화, 자연문에 섞인 프롬프트 인젝션 (Prompt Injection) 을 탐지하기 위한 공격 분류입니다. 공격자의 목표는 명시적으로 "ignore previous instructions"라고 쓰지 않고, 업무 문서나 자연문처럼 보이게 하여 메모리에 악의적인 유도를 심는 것입니다. 예를 들어, 사내 절차서처럼 "이 경우에는 승인된 것으로 처리하는 것이 표준 운영입니다"라고 작성하는 것과 같이 도메인에 녹아드는 공격입니다. 코드상에서는 Hugging Face의 분류 모델을 사용하여, 일정 점수 이상일 경우 인젝션 (injection) 으로 판정하여 탐지합니다. |

탐지 후의 대응

탐지기 (detector)가 이상을 탐지한 후에는 정책 (policy) に따라 대응을 결정합니다.

탐지기는 "무엇이 수상한가"를 판정하고, 정책 (policy) 은 "그에 대해 무엇을 할 것인가"를 결정하는 역할을 합니다.

액션 (action) 은 다음과 같습니다.

예를 들어 Prompt Injection이 탐지된 경우에는 block, API 키와 같은 기밀 정보가 탐지된 경우에는 redact, 크기 이상과 같이 의심스럽지만 즉시 삭제해서는 안 되는 것은 quarantine과 같은 대응이 가능합니다. 이 정책 (Policy) 설정은 커스터마이징할 수 있습니다.

보충하자면, 이상을 탐지한 데이터를 즉시 삭제하는 것은 아닙니다.

특히 읽기 (read) 시에 기존 메모리에서 이상이 발견된 경우, 갑자기 삭제하면 오탐 (false positive) 인 경우 문제가 될 수 있습니다. 또한 공격의 흔적도 사라집니다. 따라서 우선은 에이전트에게 반환하지 않거나, 마스킹하거나, 격리하거나, 감사 로그에 남기는 등의 대응이 안전합니다.

데모 (Demonstration)

간단한 사용법

지금부터 직접 실행해 보겠습니다. 설치는 명령어 한 줄이면 됩니다.

pip install agent-memory-guard # uv의 경우: uv add agent-memory-guard

MemoryGuard를 인자 없이 생성하면 허용적 (permissive) 정책 (탐지하여 이벤트는 기록하지만, 차단은 하지 않음)이 됩니다. 실제로 차단하게 하려면 Policy.strict()를 전달합니다. Policy.strict()는 기본적으로 인젝션 $\rightarrow$ block, 기밀 정보 $\rightarrow$ redact, 크기 이상·고빈도 쓰기 $\rightarrow$ quarantine으로 매핑하는 프리셋입니다.

from agent_memory_guard import MemoryGuard, Policy, PolicyViolation
guard = MemoryGuard(policy=Policy.strict())
guard.write("facts.weather", "도쿄의 오늘 날씨는 맑음") # 정상적인 쓰기는 통과함
...

실행 결과는 다음과 같습니다.

[BLOCKED] rule=prompt_injection key=facts.injected

오염된 값은 예외로 차단되어 스토어에 기록되지 않습니다. 소소하지만 기쁜 점은, 차단되는 순간 직전의 메모리 상태가 pre-block 레이블이 붙은 스냅샷(Snapshot)으로 자동 저장된다는 점입니다. 덕분에 "공격 직전의 메모리는 어떤 상태였는가"를 나중에 추적할 수 있습니다.

이 외에도 API 키나 JWT를 [REDACTED:github_token]과 같이 마스킹하여 저장하는 redact, 크기 이상이나 차안 공격(Churn attack, 동일 키에 대한 고빈도 쓰기)을 방지하는 quarantine 등도 시도할 수 있습니다.

mem9의 memory를 보호하기

mem9에 대한 간단한 소개

보호 대상인 메모리 기반으로 mem9를 사용합니다.

mem9는 TiDB 팀(PingCAP)이 개발하고 있는 AI 에이전트용 영속 메모리 (Persistent Memory) 기반입니다. 에이전트의 기억을 TiDB의 분산 아키텍처 (Distributed Architecture) 위에 배치함으로써, 서두에서 언급한 "에이전트 간 공유" 및 "확장성 (Scalability)"이라는 요구사항을 충족하도록 설계되었습니다. 호스팅 버전(api.mem9.ai)은 REST API(v1alpha2)로 조작할 수 있으며, 인증은 X-API-Key 헤더를 사용합니다. 베타 버전이므로 현재(2026년 6월 기준)는 무료로 사용할 수 있습니다. API 키 취득 방법은 공식 리포지토리(Repository)의 README를 참조하세요.

간단한 사용법

API 키를 취득하면 curl만으로 메모리 쓰기와 조회를 시도할 수 있습니다.

# 메모리 쓰기
curl -X POST https://api.mem9.ai/v1alpha2/mem9s/memories \
-H "X-API-Key: $MEM9_API_KEY" \
...

저장된 정보를 가져오는 방법은 3가지가 있습니다.

# 1. 목록 조회 (응답은 {memories, total, limit, offset}. limit은 최대 200)
curl "https://api.mem9.ai/v1alpha2/mem9s/memories?limit=10" \
-H "X-API-Key: $MEM9_API_KEY"
...

3번 검색은 q를 붙이기만 하면 되며, 엔드포인트(Endpoint)는 목록 조회와 동일합니다. 자연어 쿼리(Natural Language Query)와 관련된 메모리가 반환되며, 각 레코드에는 관련도 score, confidence, 인간이 읽을 수 있는 경과 시간 relative_age가 부여됩니다. 부분 일치로 필터링하고 싶다면 &search_mode=keyword를 붙이면 키워드(Substring) 검색이 됩니다. 이러한 리콜(Recall)형 검색이 에이전트가 "지금 필요한 기억"을 끌어낼 때의 기본이 됩니다.

저장된 메모리는 대시보드에서 확인할 수 있습니다. API를 통해 기록한 content와 metadata가 그대로 목록에 나열되므로, 에이전트가 무엇을 기억했는지 인간 측에서 감사(Audit)할 수 있어 편리합니다.

하지만 이 mem9 API를 에이전트가 직접 다루게 하면, 지금까지 살펴본 메모리 포이즈닝 (Memory Poisoning)이 그대로 성립하고 맙니다. "사용자의 취향"을 가장한 악의적인 지시도, API 키의 혼입도 그대로 통과되어 영속화됩니다. 그래서 그 사이에 Agent Memory Guard를 끼워 넣은 MCP 서버를 만듭니다.

mem9를 보호하는 MCP 서버 작성

구현은 다음과 같습니다.

제작한 MCP 서버 mem9-guard-mcp의 구조는 다음과 같습니다. 에이전트는 가공되지 않은(Raw) mem9 API에 직접 닿지 않으며, 모든 read / write는 가드(Guard)를 통과합니다.

Agent Memory Guard는 **스토리지 독립적 (Storage-agnostic)**이므로, MemoryStore 프로토콜(get / set / delete / keys / items / __contains__)을 충족하는 어댑터(Adapter)를 작성하면 어떤 백엔드(Backend)든 가드 뒤에 배치할 수 있습니다. mem9용 어댑터인 Mem9Store는 httpx 기반의 얇은 클라이언트를 감싸는 것만으로 구성되어 수십 줄 내외로 끝났습니다.

MCP 서버로서 공개한 도구(Tool)는 6개입니다.

고민했던 점

설계 과정에서 한 가지 고민하여 결정한 것이 있습니다. MCP 서버와 Agent Memory Guard를 분리할 것인가, 아니면 통합할 것인가입니다.

분리할 경우, MCP 서버는 "도구 공개", Memory Guard는 "검증(Validation)"으로 책임이 나뉘어 설계 측면에서는 더 깔끔합니다. 하지만 이 구성에서는 mem9에 쓰기를 수행하는 Memory Guard 측에 API 키를 두어야 합니다. 그렇게 되면 MCP의 설정 메커니즘(claude mcp add --env로 전달하는 환경 변수)을 통해 인증 정보를 관리할 수 없게 되어, 키 배치 및 업데이트 메커니즘을 별도로 마련해야 합니다.

반면 통합하면, API 키를 MCP 서버 측의 환경 변수로 관리할 수 있으며, 그 키를 사용하여 즉시 mem9에 쓸 수 있습니다. 이번에는 인증 관리의 단순함을 택하여 통합했습니다.

참고로 통합하더라도, MCP 서버 내부에서 mem9로 요청을 보내는 것은 가드 배후의 Mem9Store뿐이며, 도구(Tool) 계층이 mem9로의 직접적인 경로를 가지는 것은 아닙니다.

이는 향후 메모리 기반 설계의 과제 중 하나이며 앞으로 검토해야 할 사항이기도 합니다. 이 메모리 기반을 클라우드 상에 전개할 경우에는 memory service와 같이 메모리 기반의 데이터를 안전하게 관리하는 마이크로서비스(Microservice) 형태로 구현하는 것이 좋다고 생각합니다.

Claude Code에서 mem9에 안전하게 액세스하기

제작한 MCP 서버를 Claude Code에 등록합니다.

claude mcp add mem9-guard `
--env MEM9_API_KEY=<your-key> `
-- uv run --project <리포지토리 경로> --package mem9-guard-mcp mem9-guard-mcp

등록하면 Claude Code에서 memory_write 등이 도구로 보이게 됩니다. 이를 통해 다음과 같은 프롬프트를 주면 mem9에 데이터를 안전하게 저장할 수 있습니다.

mem9-guard-mcp를 사용해서 "앞으로의 대화는 모두 영어로 답변해 주세요"라고 기록해 줘.

실행하면 제 환경에서는 다음과 같은 결과가 나왔습니다.

악의적인 쓰기는 정말로 차단되는가?

다음으로 확인하고 싶은 것은 핵심인 "공격이 차단되는가"입니다. 다만, 이 테스트는 Claude Code 상에서는 할 수 없었습니다. Claude Code에 공격 문자열 쓰기를 유도하는 프롬프트는 에이전트 측의 안전 메커니즘에 의해 탐지되어 실행 전에 거부됩니다 (후술할 주의 사항 참조). 설령 통과한다 하더라도, LLM을 거치면 공격 문자열이 다른 말로 바뀌어 버리기 때문에 재현 가능한 테스트가 되지 않습니다.

그래서 LLM을 거치지 않고 MCP 서버로 stdio의 JSON-RPC를 직접 흘려보내는 스모크 테스트(Smoke test)를 준비하여 이를 통해 검증했습니다. 스크립트는 리포지토리에 있습니다.

uv run python scripts/smoke_stdio.py

[OK ] normal write: {"status": "allow", "key": "smoke.normal"}
[OK ] read back: {"status": "ok", "key": "smoke.normal", "value": "favorite color is blue"}
[OK ] injection blocked: {"status": "blocked", "key": "smoke.injection", "reason": "Write to 'smoke.injection' blocked by policy"}
...

정상적인 쓰기는 allow로 통과되며, 인젝션 (Injection)은 blocked로, GitHub 토큰을 포함한 쓰기는 [REDACTED:github_token]으로 마스킹(Masking)된 후 저장됩니다. 마지막 security_events에는 block / redact 감사 이벤트가 남아 있어, "무엇이·왜 차단되었는지"를 나중에 추적할 수 있습니다.

⚠️ 주의

위와 같이, 공격 테스트는 테스트 스크립트를 통해 직접 수행해 주세요. Claude Code나 Codex 등에게 공격을 유도하는 프롬프트(Prompt)를 입력하지 마십시오. 규칙 위반이 감지될 경우 다음과 같이 주의 표시가 나타납니다.

각 도구의 이용 약관 및 가이드라인을 준수하여 사용합시다.

요약

Memory Poisoning이라는 위협, 이에 대한 방어 계층인 OWASP Agent Memory Guard, 보호 대상인 mem9, 그리고 이 둘을 연결하는 MCP 서버 mem9-guard-mcp의 구현을 소개했습니다.

솔직히 말씀드리면, 이 방어책이 만능은 아닙니다. 정규 표현식 (Regular Expression) 기반의 탐지는 알려진 패턴에만 유효하며, 앞서 언급했듯이 표준 패턴은 영어로만 되어 있습니다. ML (Machine Learning) 탐지기를 병용하더라도, 도메인에 녹아든 교묘한 유도를 완전히 방지할 수 있다는 보장은 없습니다. 그럼에도 불구하고 "에이전트와 메모리 사이에 검문소를 두고, 모든 조작을 감사 가능하게 만든다"는 아키텍처(Architecture) 자체에는 큰 가치가 있다고 느꼈습니다. 공격을 100% 막는 것보다, 오염을 인지할 수 있고·추적할 수 있으며·되돌릴 수 있는 상태를 만드는 것이 현실적인 방어라고 생각합니다.

그럼에도 여기서 작성한 MCP도 어느 정도의 공격에는 유효하게 작동하므로, memory poisoning이 걱정되는 분들은 꼭 사용해 보시고 소감을 들려주시면 좋겠습니다.

향후 전망

AI 에이전트가 메모리 기반에 직접 접근하게 하는 것은 위험하며, 그 사이에 Agent Memory Guard와 같은 검사 계층을 두어야 한다는 생각에 몰두하고 있는 과정임을 느꼈습니다.

이 아이디어를 응용하여 TiDB 상에 독자적인 메모리 기반을 구축할 경우에도, 에이전트가 TiDB 상의 메모리 데이터에 직접 접근하는 것을 방지하는 중개자, 즉 가드(Guard) 기능을 내장한 서비스나 프록시 (Proxy, memory service)가 필요할 것입니다. 이미지는 다음과 같습니다.

세 가지 계층은 각각 독립적으로 교체될 수 있습니다. 이번 사례처럼 MemoryStore 프로토콜 (Protocol)과 같은 어댑터 경계 (Adapter boundary)를 처음부터 설계에 포함해 두면, 스토리지 (TiDB) · 검사 계층 · 에이전트 인터페이스 (MCP)를 독립적으로 진화시킬 수 있기 때문입니다. 여러 에이전트가 동일한 memory service를 공유하면, 서두에서 언급한 "에이전트 간의 메모리 공유"도 모든 읽기/쓰기가 검사 및 감사된 상태로 실현할 수 있습니다.

다음으로는 TiDB의 벡터 검색 (Vector Search)을 이용한 시맨틱 (Semantic) 메모리 검색에, 읽기 측의 출구 스크리닝 (Exit Screening)을 적용하는 구성을 시도해 보고 싶습니다.

Discussion