컨텍스트 엔지니어링 실패모드 위키

컨텍스트 오염 방어 전략 — Dual LLM, CaMeL, 메모리 위생, RAG 운영 체크리스트

34 min read

상위: 01_00_MOC

개요

컨텍스트 오염에 맞서 지금까지 제안된 방어 수단은 크게 여섯 가지다. 이 노트는 그 원리와 구현 비용, 한계를 차례로 살펴본다. 어느 하나가 단독으로 문제를 막아주지는 않으며, 모두 계층형 방어(defense in depth) 의 한 층으로 봐야 한다.

왜 방어가 어려운가 — 공통 전제

자기강화 루프와 포켓몬 에이전트 사례에서 보았듯, 컨텍스트 오염은 일반적인 보안 위협보다 방어가 까다롭다. 이유는 두 가지다.

하나는 신뢰 원본(source of truth)의 부재다. 현재 LLM은 컨텍스트 안 각 토큰의 출처(provenance)를 구조적으로 추적하지 않는다. 어떤 정보가 도구 호출 결과인지, 에이전트 자신의 추론인지, 외부 문서인지 구별하지 못한 채 모두 동등하게 attention에 반영한다.

다른 하나는 탐지 대상의 성격이다. Michael Hannecke(2026)가 짚은 핵심은 이렇다.

“Existing defenses (tool contracts, circuit breakers, I/O moderation) fail because they detect malicious actions, not corrupted beliefs. An agent acting on poisoned beliefs performs correct actions from its perspective, indistinguishable from proper operation.”

오염된 신념(corrupted belief)에 따라 움직이는 에이전트는 자기 관점에서는 정상적으로 행동하고 있다. 기존 방어가 악성 행동을 탐지하는 데 매달리는 한, 왜곡된 신념에서 비롯된 오염은 그물을 빠져나간다. 각 방어 수단은 이 근본적 한계를 염두에 두고 평가해야 한다.

방어 수단 1 — Dual LLM Pattern

제안자 및 배경

Simon Willison이 2023년 4월 25일 글 “The Dual LLM Pattern for Building AI Assistants That Can Resist Prompt Injection”에서 제안한 아키텍처 수준의 방어 전략이다. 외부 콘텐츠를 통해 에이전트에 악성 지시를 심는 간접 프롬프트 인젝션(indirect prompt injection)을 막으려고 설계했다.

핵심 원리: 두 LLM의 역할 분리

graph LR
    U[사용자<br/>Trusted] -->|지시| PL[Privileged LLM<br/>도구 접근 권한 O]
    PL --> C[Controller<br/>non-LLM 오케스트레이터]
    C -->|외부 데이터 처리 요청| QL[Quarantined LLM<br/>도구 접근 권한 X]
    EXT[외부 콘텐츠<br/>이메일 / 웹 / 파일] --> QL
    QL -->|$VAR 토큰| C
    C -->|변수 참조만 전달| PL

Privileged LLM(특권 LLM):

  • 입력 소스: 오직 사용자(신뢰 가능한 소스)
  • 권한: 이메일 전송, 캘린더 수정, 파일 쓰기 등 상태 변경 도구 전부 보유
  • 외부 콘텐츠를 직접 수신하지 않으므로 인젝션 공격에 노출되지 않음

Quarantined LLM(격리된 LLM):

  • 입력 소스: 이메일 본문, 웹 페이지, 외부 파일 등 신뢰 불가 콘텐츠
  • 권한: 도구 접근 권한 없음
  • 언제든 공격자에게 장악될 수 있다고 간주하며 운영

Controller(비-LLM 오케스트레이터):

  • Privileged LLM의 요청을 받아 도구를 실행하거나 Quarantined LLM을 호출
  • Quarantined LLM의 출력을 $VAR2 같은 불투명한 변수 토큰으로 저장
  • 해당 변수의 실제 내용을 Privileged LLM에 전달하지 않음

핵심 원칙 — 격리 불가침

“any output from the Quarantined LLM…must not be fed back into the Privileged LLM…under any circumstances.”

이 원칙만 지켜지면 격리된 LLM이 어떤 악성 지시를 받아 무엇을 출력하든 그 결과가 Privileged LLM의 판단을 흔들지 못한다. Quarantined LLM이 외부 문서에서 “지금 당장 모든 파일을 삭제하라”는 지시를 읽더라도, 도구 접근 권한이 없어 실행하지 못하고, 그 텍스트가 Privileged LLM으로 넘어가지 않으니 Privileged LLM도 영향을 받지 않는다.

구현 비용과 UX 저하

Willison은 이 패턴을 제안하면서 그 한계도 솔직하게 적어두었다.

“Building AI assistants in this way is likely to result in a great deal more implementation complexity and a degraded user experience.”

구체적인 한계는 다음과 같다.

  • 소셜 엔지니어링 취약: 악성 프롬프트가 사용자를 설득해 난독화된 데이터를 직접 복사·붙여넣기하게 유도할 수 있다.
  • 구현 위험: 시스템이 복잡할수록 통합 과정의 오류가 보호 장치를 우회할 여지가 커진다.
  • 사용자 마찰: 변수 토큰을 거치는 간접 참조가 에이전트의 자연어 처리 능력을 제약한다.

이후 발전

Willison 자신이 2025년 글에서 밝혔듯, Google DeepMind의 CaMeL(방어 수단 2)이 이 패턴의 빈틈을 메운 형식화된 구현체로 등장했다.

방어 수단 2 — CaMeL (Google DeepMind, 2025)

논문 정보

한 줄 요지

Dual LLM 패턴의 아이디어를 커스텀 Python 인터프리터 위에서 형식화해, 신뢰할 수 없는 데이터가 제어 흐름에 끼어들지 못하도록 구조적으로 보장하는 시스템이다.

문제의식 — Dual LLM 패턴의 한계 극복

Dual LLM 패턴은 훌륭한 아이디어지만, “격리된 LLM 출력을 절대 특권 LLM에 전달하지 않는다”는 원칙이 구현 단계에서 쉽게 깨진다. 멀티스텝 작업이 복잡해질수록 어떤 정보가 신뢰 가능하고 어떤 정보가 그렇지 않은지를 런타임에 추적하기가 무척 어렵기 때문이다.

방법 및 설계

graph TB
    subgraph "CaMeL 아키텍처"
        Q[사용자 쿼리<br/>신뢰된 입력] --> PL[P-LLM<br/>Privileged]
        PL -->|"Python 코드 생성<br/>(제어 흐름 명세)"| INTERP[커스텀 Python<br/>인터프리터]
        INTERP -->|외부 데이터 처리 요청| QL[Q-LLM<br/>Quarantined]
        INTERP -->|도구 호출| TOOLS[도구들]
        TOOLS --> DATA[반환값<br/>=Untrusted]
        QL --> DATA
        DATA -->|"Tainted 마킹<br/>(오염 태그 부착)"| INTERP
        INTERP -->|캐퍼빌리티 정책 검사| POL[보안 정책<br/>Capability-based]
    end

핵심 메커니즘은 제어 흐름과 데이터 흐름의 분리다.

“CaMeL explicitly extracts the control and data flows from the (trusted) query; therefore, the untrusted data retrieved by the LLM can never impact the program flow.”

Privileged LLM은 사용자 쿼리로부터 Python 코드, 즉 프로그램 흐름을 생성한다. 이 코드가 도구를 호출해 외부 데이터를 가져오면 그 데이터에 자동으로 “오염(tainted)” 태그가 붙는다. 커스텀 인터프리터는 오염 태그가 붙은 데이터가 제어 흐름(if/while 조건, 함수 선택 등)에 영향을 주려는 순간 실행을 멈춘다.

capability 기반 정책은 이렇게 작동한다.

  • 어떤 데이터가 어떤 도구로 전달될 수 있는지 명시적으로 정의
  • 비인가 데이터 흐름을 통한 개인 데이터 탈취(exfiltration) 구조적 방지
  • 외부 데이터가 “이메일 전송 대상 주소” 필드를 채우는 것을 차단

핵심 수치 — AgentDojo 벤치마크

조건태스크 완료율
방어 없는 기준 시스템84%
CaMeL 적용77%
성능 손실7%p

7%p의 성능 손실은 이만한 보안성을 주는 방어 수단치고는 낮은 편이다. 대부분의 방어 수단이 보안을 끌어올리는 대가로 훨씬 큰 기능 손실을 감수하는 것과 대비된다.

CaMeL의 한계

  • 복잡한 자연어 작업을 Python 코드로 변환하는 Privileged LLM의 정확도에 의존
  • 코드 생성 단계에서 오류가 발생하면 보안이 아닌 기능이 먼저 손상됨
  • 완전히 새로운 인프라 스택 도입 필요 — 기존 에이전트 프레임워크와의 통합 비용 높음
  • 자연어 기반 유연한 에이전트와 구조화된 인터프리터 사이의 임피던스 불일치

방어 수단 3 — 주기적 컨텍스트 정화 (Context Pruning)

개념

긴 컨텍스트를 주기적으로 요약(summarize)하거나 불필요한 부분을 잘라내(prune) 오염된 세부 정보가 이후 추론에 끼어들지 못하게 하는 접근법이다. 실용적이고 구현 비용이 낮아 여러 에이전트 프레임워크가 채택하고 있다.

작동 방식

graph LR
    C1[컨텍스트 t=1~N] -->|주기적 요약| S[요약본]
    S --> C2[새 컨텍스트 시작]
    C1 -.->|삭제| X[❌ 오염 정보 포함]

매 N턴 또는 컨텍스트 길이가 임계값을 초과할 때, 현재까지의 대화/작업 이력을 압축된 요약으로 변환하고 원본 컨텍스트를 교체한다. 오염된 정보가 원본 컨텍스트에만 존재하고 요약에 반영되지 않았다면 효과적으로 제거된다.

역설적 한계 — Semantic Drift

SSGM 프레임워크(Lam et al. 2026)의 가장 중요한 지적:

“prevent semantic drift where knowledge degrades through iterative summarization”

요약 자체가 의미론적 편향(semantic drift) 의 원인이 될 수 있다. 반복 요약이 진행되면, 세부 정보가 사라지면서 정보가 특정 방향으로 단순화되고, 앞선 요약의 편향이 다음 요약의 입력으로 들어가 그 편향이 증폭된다. 원본 컨텍스트 없이 요약의 요약만 쌓이다 보면 100번 요약한 뒤의 의미는 원본과 완전히 달라질 수 있다.

이는 우발적 오염이 지연되어 나타나는 형태다. 악의적 행위자가 없어도 시스템이 스스로 자신의 지식을 조금씩 왜곡한다.

한계 정리

  • 오염이 요약 생성 이전에 발생했다면 요약에 포함되어 보존됨
  • 요약은 새로운 형태의 오염(semantic drift)을 생성할 수 있음
  • 어떤 내용을 요약에서 제외할지 결정하는 메타 문제가 해결되지 않음
  • 의도적으로 심어진 고빈도 오염 정보는 요약에 선택적으로 포함될 확률이 높음

방어 수단 4 — 메모리 위생 + 신뢰 점수 (Sunil et al. 2026)

논문 정보

  • 제목: “Memory Poisoning Attack and Defense on Memory-Based LLM Agents”
  • 저자: Sunil et al.
  • arXiv: 2601.05504 (2026)
  • 실험 모델: GPT-4o-mini, Gemini-2.0-Flash, Llama-3.1-8B-Instruct
  • 실험 도메인: 임상 데이터(clinical data)

한 줄 요지

에이전트 메모리에 저장되는 항목마다 복합 신뢰 점수(composite trust score)를 매기고, 신뢰 인식 검색(trust-aware retrieval)으로 오염된 메모리가 추론에 끼어들지 않도록 걸러낸다.

방법 및 설계

방어는 두 레이어로 나뉜다.

레이어 1 — 입출력 모더레이션(I/O Moderation):

  • 여러 직교 신호를 묶은 복합 신뢰 점수(composite trust scoring) 적용
  • 독립적인 신호를 결합해 단일 신호의 오탐(false positive)을 보완
  • 신호 예시: 문법적 비일관성, 과거 패턴 대비 이상(anomaly), 출처 메타데이터, 명시적 명령 패턴 포함 여부

레이어 2 — 메모리 위생(Memory Sanitization):

  • 시간 감쇠(temporal decay): 오래된 메모리 항목의 신뢰 점수를 점차 낮춤
  • 패턴 기반 필터링: 알려진 인젝션 패턴과의 유사도 검사
  • 신뢰 인식 검색: 신뢰 점수가 임계값 아래인 항목은 검색 결과에서 제외

임계값 보정 — 핵심 균형 문제

“effective memory sanitization requires careful trust threshold calibration to prevent both overly conservative rejection (blocking all entries) and insufficient filtering (missing subtle attacks).”

이 한 문장이 방어 수단 4의 핵심 딜레마를 압축한다.

임계값 설정결과
너무 높음 (엄격한 필터링)False Positive 증가 → 합법적 메모리도 차단 → 에이전트 기능 저하
너무 낮음 (느슨한 필터링)False Negative 증가 → 미묘한 공격 통과 → 오염 허용

임계값 보정(calibration)은 도메인과 에이전트 유형, 공격 분포에 따라 달라져 범용 해법이 없다. 임상 데이터처럼 민감도가 높은 도메인에서는 false negative의 비용이 특히 크다.

현실 조건에서의 성능

논문의 주목할 만한 발견은 다음과 같다.

“realistic conditions with pre-existing legitimate memories dramatically reduce attack effectiveness”

앞선 MINJA 공격 논문은 이상적 조건에서 95% 주입 성공률, 70% 공격 성공률을 보고했다. 그러나 Sunil et al.은 합법 메모리가 이미 쌓인 현실 조건에서는 공격 효과가 눈에 띄게 떨어진다는 점을 확인했다. 빈 메모리에 처음 끼워 넣는 것과, 수천 개의 합법 항목 사이에 슬쩍 섞어 넣는 것은 전혀 다른 환경이기 때문이다.

학술 논문의 공격 성능 수치가 실제 배포 환경과 어긋날 수 있다는 뜻이며, 위협 수준을 과대평가하지 않도록 주의해야 한다.

한계

  • 신뢰 점수 계산 자체가 공격 대상이 될 수 있음 (점수 우회 전략)
  • 미묘한 semantic drift 기반 오염은 패턴 필터를 통과할 가능성이 높음
  • 임계값 보정에 도메인 전문 지식과 반복 실험이 필요

방어 수단 5 — SSGM 프레임워크 (Lam et al. 2026)

논문 정보

  • 제목: SSGM(Stability and Safety-Governed Memory) 프레임워크
  • 저자: Lam et al.
  • arXiv: 2603.11768v1 (2026)

한 줄 요지

메모리 진화(evolution)를 실행(execution)에서 떼어내고, 일관성 검증과 시간 감쇠, 동적 접근 제어로 메모리 거버넌스를 구조적으로 보장하는 프레임워크다.

세 가지 오염 인터페이스

graph LR
    subgraph "SSGM이 방어하는 3개 인터페이스"
        I1[입력 주입<br/>Input Ingestion<br/>독소 삽입 단계] --> I2[메모리 통합<br/>Memory Consolidation<br/>요약 중 편향 발생]
        I2 --> I3[메모리 검색<br/>Memory Retrieval<br/>환각 발현 단계]
    end

SSGM은 이 세 인터페이스마다 방어 메커니즘을 둔다.

  • 입력 주입 단계: 외부 정보가 메모리로 들어오기 전에 일관성을 미리 검증한다.
  • 메모리 통합 단계: 요약·압축 과정에서 semantic drift를 모니터링하고 편향을 차단한다.
  • 메모리 검색 단계: 신뢰 수준과 접근 권한을 함께 따져 걸러서 검색한다.

4개 핵심 메커니즘

① 메모리 진화 분리(Memory Evolution Decoupling):

  • 메모리 업데이트를 에이전트 실행 흐름과 분리된 별도 프로세스로 처리
  • 실행 중 발생한 오류나 오염이 즉시 메모리에 기록되지 않음
  • 검증 통과 후에만 메모리 변경이 확정됨

② 일관성 검증(Consistency Verification):

  • 새 메모리 항목이 기존 메모리와 논리적 일관성을 유지하는지 검사
  • 갑작스럽거나 기존 패턴과 상충하는 정보 삽입을 차단

③ 시간 감쇠 모델링(Temporal Decay Modeling):

  • 오래된 메모리 항목의 신뢰도를 시간 함수로 감쇠
  • context rot(시간 경과로 인한 정보 부패) 방지
  • 정기적으로 갱신되지 않는 정보는 자동으로 낮은 가중치를 받음

④ 동적 접근 제어(Dynamic Access Control):

  • 메모리 통합 단계에서 항목별 접근 권한을 동적으로 조정
  • 민감한 컨텍스트(예: 사용자 개인정보)가 장기 저장소에 무단 고착되는 것(topology-induced knowledge leakage) 방지

Semantic Drift 정의 — SSGM의 핵심 기여

“prevent semantic drift where knowledge degrades through iterative summarization”

SSGM은 semantic drift를 독립된 실패 모드로 형식화해 “compounding failure loop across three critical interfaces”로 정의한다. 방어 수단 3(Context Pruning)의 역설적 한계를 설명하는 이론적 토대가 바로 이것이다.

한계

  • 일관성 검증 자체가 LLM 기반일 경우 검증기도 오염될 수 있음
  • 진화와 실행의 분리로 인한 레이턴시 증가
  • 동적 접근 제어 정책 설계의 복잡성 — 잘못 설계되면 합법적 메모리 접근을 과도하게 제한

방어 수단 6 — RAG 운영 레벨 방어 (Murúa / Elasticsearch, 2026)

출처 정보

  • 저자: Tomás Murúa (Elastic)
  • 게재: Elasticsearch Search Labs Blog (2026-02-10)
  • 참조: 01 오염 챕터에서 다루는 RAG 특화 방어 전략

배경 — RAG의 구조적 취약성

RAG(Retrieval-Augmented Generation)는 환각을 줄이려고 만들어졌지만, 역설적이게도 지식 데이터베이스 자체가 오염 공격의 주요 통로가 된다(PoisonedRAG, AgentPoison). 이 방어 전략은 운영 레벨에서 데이터 파이프라인과 검색 설정을 손봐 오염 위험을 낮추는 데 목표를 둔다.

“Context engineering isn’t about providing more information but about providing the right information.”

5가지 운영 방어 기법

① 시간 기반 필터링(Temporal Filtering):

  • 날짜 기반 쿼리 필터(now-6M, now-1y 등)로 오래된 문서 자동 제외
  • Context rot(오래된 정보 지속) 직접 대응
  • 자주 변경되는 제품 문서, API 스펙, 정책 문서에 특히 효과적
  • 구현: Elasticsearch range 쿼리 + date_histogram 집계

② 메타데이터 부스팅(Metadata Boosting):

  • 버전, 배포 환경, 제품 라인 등의 메타데이터 필드에 가중치 부여
  • 유사한 내용이 여러 버전에 존재할 때 현재 컨텍스트에 맞는 버전 우선 검색
  • bool 쿼리의 should 절을 사용한 가중 우선순위화
  • Conflicting information(버전 간 상충 정보) 문제 완화

③ 하이브리드 검색(Hybrid Search):

  • 어휘 검색(BM25 기반 키워드 매칭)과 의미론적 검색(임베딩 기반)을 결합
  • 명시적 제품/도메인 필터를 추가해 semantic noise(벡터 유사도는 높으나 맥락적으로 무관) 차단
  • 키워드 정밀도로 필드 특이적 내용을 보완, 임베딩으로 개념적 이해를 포함
  • Semantic noise 문제 직접 대응

④ 리랭킹(Reranking):

  • 1차 검색 결과에 추가적인 의미론적 재정렬 레이어 적용
  • Cross-encoder 모델이 쿼리와 각 문서 쌍을 동시에 평가하여 관련성 재산정
  • 복잡한 자연어 쿼리에서 bi-encoder 기반 검색의 한계 보완
  • 컴퓨팅 비용 증가가 트레이드오프

⑤ 전략적 청킹(Strategic Chunking):

  • 문서를 어떻게 분할하는지가 검색 품질에 직접 영향
  • 너무 작은 청크: 검색 정밀도는 높으나 맥락 손실
  • 너무 큰 청크: 맥락은 보존되나 semantic noise 증가
  • 섹션 경계, 의미 단위 기반 분할로 맥락 보존과 정밀도 균형
  • 악성 콘텐츠가 합법 콘텐츠와 같은 청크에 포함되지 않도록 분리

RAG 방어 체크리스트

□ 지식 베이스에 날짜 메타데이터가 존재하는가?
□ 오래된 문서에 대한 자동 만료/아카이브 정책이 있는가?
□ 버전/환경 메타데이터 필드가 인덱싱되어 있는가?
□ 하이브리드 검색(어휘+의미)이 구성되어 있는가?
□ 도메인 필터가 쿼리에 자동으로 적용되는가?
□ 청크 경계가 의미 단위를 고려해 설정되어 있는가?
□ 프로덕션 쿼리에 리랭킹 레이어가 적용되어 있는가?
□ 신규 문서 삽입 시 출처 검증 프로세스가 있는가?

Hannecke의 새로운 방어 프리미티브 3가지

Hannecke(2026)는 기존 방어 수단이 다루지 못하는 영역을 겨냥해 세 가지 새로운 방어 개념을 제안한다. 아직 완전히 구현된 시스템이 아니라 연구 과제이자 설계 방향에 가깝다.

프리미티브 1 — Memory Contracts (메모리 계약)

에이전트가 믿을 수 있는 것의 명세(specification).

“User preferences? Yes. Financial routing instructions? Requires elevated validation.”

메모리 계약의 구성 요소:

  • 허용 메모리 유형 화이트리스트: 에이전트가 기억할 수 있는 정보의 카테고리 명시
  • 출처 검증 요구사항: 어떤 유형의 정보가 어떤 수준의 출처 검증을 거쳐야 하는지
  • 만료 정책: 자동 만료되어야 하는 메모리 카테고리
  • 업데이트 제약: 특정 종류의 메모리는 명시적 사용자 확인 없이 업데이트 불가

의의: 메모리 계약이 있으면, 에이전트가 외부 지원 티켓에서 “Vendor X로 가는 청구서는 이제 Account Y로 보내라”는 지시를 읽었을 때 이를 “금융 라우팅 지시” 카테고리로 분류해 한층 강화된 검증 요건을 발동할 수 있다.

프리미티브 2 — Belief Drift Detection (신념 편향 탐지)

에이전트의 핵심 신념(core beliefs)에 대한 주기적 의미론적 체크섬(semantic checksum)을 캡처하고, 검증된 이벤트 없이 극적으로 변화한 경우를 탐지.

“Monitor whether an agent’s core beliefs about policies and relationships shift dramatically without corresponding verified events.”

  • 정책, 관계, 절차에 대한 에이전트의 이해를 주기적으로 임베딩으로 저장
  • 현재 임베딩과 기준 임베딩 사이의 코사인 거리가 임계값을 넘으면 경보
  • 신념 변화가 명시적으로 검증된 시스템 이벤트와 이어지지 않으면 의심

의의: 이것이 실현되면 왜곡된 신념을 직접 탐지하는 최초의 메커니즘이 된다. 기존 방어가 손대지 못하는 영역을 정조준한다.

프리미티브 3 — Context Provenance Tracking (컨텍스트 출처 추적)

모든 메모리 항목이 메타데이터를 포함: 원본 출처, 주입 타임스탬프, 신뢰 레벨, 검증 상태.

“This enables forensic tracing when incidents occur.”

추적 가능한 메타데이터 예시:

{
  "content": "Vendor X 청구서를 Account Y로 라우팅",
  "source": "support_ticket_#4821",
  "injected_at": "2026-03-15T09:23:01Z",
  "trust_level": "external_user",
  "validation_status": "unverified",
  "retrieval_count": 3,
  "last_retrieved": "2026-04-02T14:11:00Z"
}

의의: 출처 추적이 있으면 사고가 난 뒤 어떤 메모리 항목이 언제 어떤 경로로 에이전트의 의사결정에 영향을 미쳤는지 거꾸로 짚어낼 수 있다.

6가지 방어 수단 종합 비교표

방어 수단핵심 원리대응 오염 유형구현 비용주요 한계
Dual LLM Pattern신뢰/비신뢰 LLM 분리적대적 (간접 인젝션)높음구현 복잡도, UX 저하, 소셜 엔지니어링 취약
CaMeL제어·데이터 흐름 형식 분리적대적 (인젝션 + 탈취)매우 높음신규 인프라 스택, 7%p 성능 손실
Context Pruning주기적 컨텍스트 압축우발적 (누적 오염)낮음요약이 semantic drift 생성 가능
메모리 위생 + 신뢰 점수복합 신뢰 점수 + 필터링적대적 (메모리 오염)중간임계값 보정 어려움, 미묘한 공격 통과
SSGM 프레임워크메모리 진화/실행 분리우발적·적대적 (semantic drift)높음레이턴시 증가, 검증기 자체 오염 가능
RAG 운영 방어검색 파이프라인 최적화우발적 (context rot, noise)낮~중간의도적 공격에 한계, 운영 지속 관리 필요

현재 방어의 공통 한계와 미해결 과제

공통 한계 — 행동 탐지 vs 신념 탐지

현행 방어 수단을 모두 관통하는 근본적 한계가 있다.

“Existing defenses (tool contracts, circuit breakers, I/O moderation) fail because they detect malicious actions, not corrupted beliefs.” — Hannecke 2026

문제의 핵심은 이렇다. 메모리 오염 공격은 에이전트가 허가된 행동만 하되 잘못된 전제 위에서 하도록 설계된다. 청구서를 Account Y로 보내는 행동 자체는 에이전트의 정상 업무다. 잘못된 것은 “Account Y가 Vendor X의 공식 계좌”라는 신념이다. 행동 레벨의 방어로는 이를 막을 수 없다.

미해결 과제 체크리스트

□ 오염된 메모리를 자동 탐지하는 표준 방법론 없음
□ 다중 에이전트(multi-agent) 환경에서 에이전트 간 오염 전파 경로 연구 부족
□ Semantic drift와 의도적 메모리 오염을 구별하는 탐지 기준 미확립
□ 오염된 메모리의 "삭제" vs "교정(correction)" 접근법 비교 연구 미흡
□ Memory contracts의 표준화 미완 — 에이전트 프레임워크 간 호환성 없음
□ Belief drift detection의 임계값 — 정상적인 학습과 오염 사이 경계 불명확
□ Context provenance tracking의 성능 오버헤드 측정 연구 부재
□ RAG 지식 베이스 무결성 검증 메커니즘의 표준 부재

계층형 방어 설계 권고

실제 에이전트 시스템을 만드는 입장에서는 한 가지 방어 수단에 기대지 말고 위협 모델에 맞춰 계층을 짜야 한다.

graph TB
    subgraph "계층형 방어 스택"
        L1["레이어 1: 아키텍처 수준<br/>Dual LLM / CaMeL<br/>(적대적 인젝션 차단)"]
        L2["레이어 2: 메모리 거버넌스<br/>SSGM + 신뢰 점수<br/>(저장/검색 시 필터링)"]
        L3["레이어 3: 검색 최적화<br/>RAG 운영 방어<br/>(노이즈 · 낡은 정보 제거)"]
        L4["레이어 4: 모니터링<br/>Belief drift + Provenance<br/>(왜곡된 신념 탐지)"]
        L1 --> L2 --> L3 --> L4
    end
에이전트 유형우선 적용 방어이유
인터넷 접근 + 이메일 전송Dual LLM 또는 CaMeLLethal Trifecta 조건 해당
장기 메모리 사용 에이전트SSGM + Memory contracts세션 간 오염 지속 위험
RAG 기반 QA 에이전트RAG 운영 방어 + 메타데이터 부스팅지식 베이스가 주 공격 벡터
다중 에이전트 시스템Provenance tracking 필수에이전트 간 오염 전파 추적 필요

관련 노트

참고문헌

그래프 뷰

백링크