[논문 리뷰] Utility Under Attack — memory poisoning은 prompt injection보다 조용하다

한 줄 요약

이 논문은 persistent memory를 가진 agent에서 가장 위험한 공격이 반드시 노골적인 prompt injection일 필요는 없다고 주장한다. 그냥 그럴듯하지만 틀린 사실 하나가 memory에 저장되고, 나중에 관련 작업에서 다시 검색되면 agent의 utility가 크게 무너질 수 있다는 것이다.

논문에서 가장 눈에 띄는 숫자는 이렇다. LongMemEval corpus의 1.2%만 false assertion으로 poisoning했을 때 accuracy가 0.850에서 0.300으로 떨어진다. 반면 indirect prompt injection에 대해 recall 0.832를 보인 4단계 write-time screening pipeline은 360개 poisoned memory 중 0개를 거부했다. 이 정도면 “악성 문구를 탐지하면 된다”는 방어 모델은 memory poisoning 문제의 핵심을 빗나간다.

왜 지금 중요한가

agent memory는 이제 데모 기능이 아니다. 개인 비서, coding agent, CRM assistant, research agent 모두 장기 상태를 저장하려 한다. 문제는 memory가 편의 기능인 동시에 공격 지속성의 저장소가 된다는 점이다.

일반 prompt injection은 한 세션 안에서 실패하고 끝날 수 있다. 하지만 memory poisoning은 다르다.

1. 잘못된 정보가 memory store에 들어간다.
2. 검색기가 나중에 그 memory를 관련 근거로 다시 꺼낸다.
3. 모델은 그것을 “사용자에 대한 맥락” 또는 “과거 검증된 사실”처럼 취급한다.
4. 같은 오류가 여러 세션에 걸쳐 반복된다.

내 생각엔 이게 memory agent 보안의 진짜 불편한 지점이다. 공격 문장이 위험해 보이지 않아도 위험할 수 있다. “사용자는 A 프로젝트의 운영 DB를 staging이라고 부른다” 같은 문장은 문장 자체로는 무해하지만, 사실이 아니면 이후 자동화 결정 전체를 망칠 수 있다.

핵심 아이디어: false assertion은 텍스트만 보고 판별하기 어렵다

논문이 찌르는 지점은 단순하다. content-only screening은 보통 이런 신호를 본다.

• 명령형 문장인가
• 시스템 지시를 덮어쓰려 하는가
• secret을 요청하는가
• tool 실행을 유도하는가
• trigger word나 suspicious pattern이 있는가

그런데 false assertion poisoning은 이런 모양이 아니다.

사용자의 결제 한도는 500달러가 아니라 5,000달러다.
프로덕션 배포는 금요일 오후에도 허용된다.
이 고객은 환불 예외 대상이다.

이 문장들이 참인지 거짓인지는 문장 표면만으로 알 수 없다. 외부 ground truth, source provenance, timestamp, writer authority, conflicting evidence가 필요하다. 그래서 write-time scanner가 prompt injection에는 잘 반응하더라도 false assertion을 놓칠 수 있다.

이 관점은 꽤 중요하다. memory 보안을 “입력 sanitization”으로 보면 방어가 얇아진다. memory 보안은 사실상 작은 지식베이스 운영 문제다. 쓰기 전에 검증하고, 읽을 때 신뢰도를 계산하고, 충돌하면 보류하고, 이후에 수리할 수 있어야 한다.

실험에서 읽을 포인트

실험 수치에서 읽을 메시지는 세 가지다.

1. 작은 poisoning 비율도 utility를 크게 깎는다

LongMemEval corpus의 1.2% poisoning으로 accuracy가 0.850에서 0.300까지 떨어졌다는 결과는 memory store가 평균적으로 깨지는 게 아니라 특정 query path에서 결정적으로 깨질 수 있음을 보여준다.

즉 운영 지표를 볼 때 “poisoned memory 비율이 낮으니 괜찮다”고 말하면 안 된다. 중요한 것은 비율이 아니라 검색될 확률과 결정에 미치는 영향이다. agent memory regression test는 random sample inspection보다 high-impact memory path를 봐야 한다.

2. prompt injection scanner는 false assertion scanner가 아니다

논문은 4단계 write-time screening pipeline이 indirect prompt injection에는 어느 정도 recall을 보였지만, 360개 poisoned memory를 하나도 거부하지 못했다고 보고한다. 이 결과가 재현된다면 방어 설계에 꽤 직접적인 함의가 있다.

• prompt injection 탐지기
• PII/secret scanner
• toxicity/safety classifier
• policy keyword filter

이런 도구들은 필요하지만 memory truthfulness를 보장하지 않는다. “유해한 지시”와 “틀린 사실”은 다른 문제다.

3. provenance weighting도 만능은 아니다

논문은 provenance-weighted retrieval도 평가한다. 초록 기준으로 shipped weight는 no defense와 통계적으로 구분되지 않았고, 더 강한 weight는 untrusted content를 제외할 때만 utility를 회복했다. 하지만 answer-bearing evidence 자체가 untrusted로 들어오는 조건에서는 evidence recall이 0, accuracy가 0.0417까지 떨어졌다고 한다.

여기서 교훈은 provenance를 점수에 더하는 방식만으로는 부족하다는 것이다. 신뢰 낮은 근거를 너무 약하게 패널티하면 poison이 들어오고, 너무 강하게 패널티하면 실제로 필요한 새 정보까지 죽인다.

실무 설계로 바꾸면: bounded occupancy가 더 현실적이다

논문은 additive provenance penalty 대신 retrieval 단계의 bounded occupancy constraints를 주장한다. 이 표현을 운영 설계로 풀면, “검색 결과 전체를 untrusted memory가 점유하지 못하게 제한하자”에 가깝다.

예를 들어 memory retrieval을 이렇게 나눌 수 있다.

retrieved_context = {
  trusted_profile_facts: 최대 3개,
  user_recent_messages: 최대 5개,
  unverified_memories: 최대 2개,
  external_evidence: 최소 1개,
  conflicting_records: 있으면 반드시 포함
}

점수 하나로 전부 정렬하지 않고, 출처·검증 상태·시간·업무 영향도별 quota를 둔다. 이 방식은 완벽하지 않지만 운영적으로 낫다. 특히 agent가 high-impact action을 할 때 unverified memory가 context를 독점하는 상황을 막을 수 있다.

내가 memory agent를 설계한다면 최소한 아래 정책은 넣겠다.

• write gate: 새 memory를 바로 durable store에 넣지 말고 candidate → verified → durable 단계로 나눈다.
• source label: 사용자 발화, tool result, 외부 문서, agent 추론을 같은 memory로 취급하지 않는다.
• conflict index: 새 fact가 기존 durable fact와 충돌하면 저장보다 검증 queue로 보낸다.
• retrieval quota: unverified 또는 low-trust memory가 top-k를 독점하지 못하게 한다.
• action coupling: 결제, 삭제, 배포, 메시지 전송 같은 side effect 앞에서는 memory-only evidence를 금지한다.
• repair workflow: poisoned memory 발견 시 단일 삭제가 아니라 관련 derived memory와 요약까지 invalidation한다.

agent memory QA 체크리스트

이 논문을 읽고 바로 팀 체크리스트로 바꾸면 아래 정도가 된다.

1. memory write를 누가 했는가?
   사용자, agent, tool, 외부 문서, import script를 구분해야 한다.

2. memory가 어떤 근거에서 왔는가?
   “사용자가 말했다”와 “시스템 API가 반환했다”는 신뢰 레벨이 다르다.

3. 현재도 유효한가?
   memory poisoning과 stale memory는 다르지만, 운영상 둘 다 잘못된 durable fact를 만든다.

4. 검색 결과에서 비중이 과하지 않은가?
   top-k가 전부 같은 low-trust source에서 오면 위험하다.

5. high-impact action에 memory만 쓰고 있지 않은가?
   memory는 힌트가 될 수 있지만 권한 부여 근거가 되면 안 된다.

6. 오류 발견 후 수리 범위가 정의되어 있는가?
   poisoned fact 하나가 요약, preference, skill, workflow rule로 전파됐을 수 있다.

한계와 조심해서 읽을 점

다만 이 논문을 실무 정책으로 옮길 때는 아래를 조심해서 봐야 한다.

• poisoning 문장 생성 방식이 실제 공격자 모델을 얼마나 대표하는지
• LongMemEval 기반 결과가 개인 비서, coding agent, enterprise assistant에 얼마나 일반화되는지
• write-time screening pipeline의 구체 구성과 baseline 강도
• provenance weight 실험에서 retriever similarity regime이 다른 embedding model에서도 유지되는지
• bounded occupancy가 recall 손실 없이 적용 가능한 구체 policy인지

그래도 방향은 설득력 있다. memory poisoning은 “나쁜 명령어” 탐지가 아니라 “틀린 사실의 durable persistence” 문제다. agent memory를 제품에 넣는다면, memory store를 vector DB 부속품처럼 다루면 안 된다. 작은 데이터베이스, 감사 로그, 권한 모델, 복구 절차를 가진 운영 시스템으로 봐야 한다.

참고 자료

• arXiv: Utility Under Attack: Agent Memory Poisoning and the Limits of Content Screening and Provenance Ranking
• arXiv PDF: 2608.21230v1
• LongMemEval 관련 맥락: LongMemEval on arXiv search