상위: 01_00_MOC

한 줄 정의

CaMeL(arXiv:2503.18813, “Defeating Prompt Injections by Design”)은 모델을 더 똑똑하게 훈련시켜 막는 것이 아니라 LLM 바깥에 보호 계층(protective system layer)을 설계로 두어 프롬프트 인젝션을 막는 방어 체계다. 신뢰된 사용자 쿼리에서 제어 흐름(control flow)과 데이터 흐름(data flow)을 명시적으로 분리해 추출하고, 외부에서 가져온 신뢰 불가 데이터에는 capability/taint 메타데이터를 붙인다. 이렇게 해서 그 데이터가 프로그램의 분기나 도구 호출 인자를 좌우하지 못하도록 커스텀 Python 인터프리터 수준에서 강제한다(Google 연구진, 2025).

제목·이름 구분

이 논문의 공식 제목은 “Defeating Prompt Injections by Design”이다. “CaMeL”은 논문이 제안하는 시스템(방어 기법)의 이름이지 논문 제목이 아니다. “CaMeL: …” 류의 변형 제목으로 잘못 인용되는 경우가 있으니, 인용할 때는 제목은 위 영문 그대로, 시스템명은 CaMeL로 적는다.

왜 중요한가

01장은 컨텍스트 오염(poisoning)을 다루며, 그중 적대적 경로의 핵심이 프롬프트 인젝션이다(01_08-적대적-오염-위협지형). 인젝션을 막는 처방은 크게 두 갈래다. 하나는 모델이 악성 지시를 덜 따르도록 훈련하거나 필터링하는 확률적 방어이고, 다른 하나는 악성 입력이 들어와도 구조적으로 위험한 행동을 못 하게 하는 설계적 방어다. CaMeL은 후자의 대표 사례이자, Simon Willison의 Dual LLM 패턴(01_09-처방-방어전략)을 실제로 형식화해 구현한 첫 시스템이다.

설계적 방어가 중요한 이유는 확률적 방어의 근본 한계에 있다. Willison이 반복해 강조하듯, 보안에서 “95% 차단”은 낙제점이다. 공격자는 5%만 뚫으면 되기 때문이다(01_08-적대적-오염-위협지형의 가드레일 비판 참조). CaMeL은 특정 작업 부류에 대해 증명 가능한(provable) 보안을 주장한다는 점에서, 확률적 95%와는 질적으로 다른 종류의 약속을 한다. AX 컨설턴트 관점에서 보면, 에이전트가 신뢰 불가 데이터(이메일 본문, 웹페이지, 문서)를 읽고 도구를 호출하는 모든 워크플로가 이 방어의 적용 대상이며, 07 거버넌스 장의 데이터 출처(provenance) 및 taint 추적 요구사항과 곧바로 이어진다.

1. 문제의식 — 왜 Dual LLM만으로는 부족한가

프롬프트 인젝션의 본질은 LLM이 지시의 의미(semantics)만 처리할 뿐, 그 지시의 출처(provenance)를 구조적으로 구분하지 못한다는 데 있다(01_08-적대적-오염-위협지형). 그래서 “신뢰된 시스템 지시”와 “이메일 본문에 숨은 악성 지시”가 같은 컨텍스트 윈도우에 섞이면 모델은 둘을 동등하게 취급할 수 있다.

Willison의 Dual LLM 패턴(2023)은 이를 두 LLM 분리로 완화한다.

  • 특권 LLM(Privileged LLM, P-LLM): 도구 실행 권한 보유, 신뢰된 입력만 처리
  • 격리 LLM(Quarantined LLM, Q-LLM): 신뢰 불가 외부 콘텐츠를 처리하되 도구 실행 권한 없음

원칙은 “격리 LLM의 출력은 절대 특권 LLM으로 그대로 넘기지 않는다”였다. 그러나 CaMeL 저자와 Willison 본인이 지적하는 약점은, 격리 LLM이 추출한 데이터가 이후 어떤 도구의 어떤 인자로 흘러가는지를 런타임에서 추적하고 통제할 형식적 장치가 없다는 점이다. 예컨대 Q-LLM이 추출한 “수신자 주소”가 그대로 send_email의 인자로 들어가면, 그 주소를 공격자가 조작했을 때 데이터 탈취가 일어난다. Dual LLM은 분리는 했지만 흐름 추적은 하지 않은 셈이다.

2. 방법 — CaMeL의 작동 방식

CaMeL은 Dual LLM의 두 LLM 분리를 유지하되, 그 사이에 커스텀 Python 인터프리터라는 형식적 실행 계층을 끼워 넣는다.

이 인터프리터가 제어 흐름과 데이터 흐름을 분리해 실행하면서, 신뢰 불가 데이터의 흐름을 추적한다.

flowchart TD
    U["신뢰된 사용자 쿼리"] --> P["P-LLM (특권)<br/>쿼리→제한된 Python 코드 생성<br/>= 제어 흐름 확정"]
    P --> I["커스텀 Python 인터프리터<br/>제어/데이터 흐름 분리 실행"]
    I -->|"신뢰 불가 텍스트 파싱 요청"| Q["Q-LLM (격리)<br/>외부 콘텐츠→구조화 데이터<br/>도구 권한 없음"]
    Q -->|"결과에 taint/capability 태그 부착"| I
    I -->|"도구 호출 직전 정책 검사"| POL["보안 정책<br/>(capability 기반)"]
    POL -->|"허용"| T["도구 실행"]
    POL -->|"위반"| B["차단 / 사용자 승인 요구"]

단계별 메커니즘은 이렇다.

  1. 제어 흐름 고정: P-LLM은 신뢰된 사용자 쿼리만 보고 작업 전체를 제한된 Python 코드로 변환한다. 무엇을 어떤 순서로 호출할지(제어 흐름)가 신뢰된 입력만으로 결정되며, 이후 어떤 외부 데이터도 이 분기 구조를 바꿀 수 없다.
  2. 격리된 파싱: 신뢰 불가 콘텐츠(이메일 본문 등)에서 값을 뽑아야 할 때는 Q-LLM을 순수 함수처럼 호출한다(query_quarantined_llm(...)). Q-LLM은 도구를 호출할 수 없다.
  3. taint 전파: Q-LLM이 반환한 값과 외부에서 온 모든 데이터에는 인터프리터가 “오염(tainted)” 표시와 출처·권한(capability) 메타데이터를 붙여 변수에 저장한다. 이 메타데이터는 변수가 가공되거나 전달되어도 자료 출처를 따라 전파(propagate)된다.
  4. 정책 강제: 도구 호출 시점에 인터프리터가 보안 정책(security policy)을 검사한다. 신뢰 불가 출처의 값이 민감한 인자(수신자 주소, 파일 경로 등)로 흘러가면 차단하거나 사용자 승인을 요구한다.

Willison의 예시가 핵심을 압축한다. address = query_quarantined_llm("Find Bob's email...")로 만든 변수는 신뢰 불가이므로, send_email(recipient=address)는 그 주소가 알려진 신뢰 연락처와 일치하지 않으면 승인 프롬프트를 띄운다.

핵심 직접 인용

“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.” — 논문 초록, 2025

“CaMeL uses a notion of a capability to prevent the exfiltration of private data over unauthorized data flows by enforcing security policies when tools are called.” — 논문 초록, 2025

“CaMeL is a practical defense to prompt injection achieving security not through model training techniques but through principled system design around language models.” — Simon Willison, 2025

3. 수치 — AgentDojo 평가

CaMeL은 프롬프트 인젝션 에이전트 보안 벤치마크 AgentDojo에서 평가됐다.

구성작업 해결률비고
방어 없는(undefended) 시스템84%보안 보장 없음
CaMeL 적용77%증명 가능한 보안(provable security) 하에서

“We demonstrate effectiveness of CaMeL by solving 77% of tasks with provable security (compared to 84% with an undefended system) in AgentDojo.” — 논문 초록, 2025

해석 포인트:

  • 7%p 손실(84%→77%)이 보안의 대가다. 핵심은 그 손실이 “확률적으로 95% 막음”이 아니라 해당 작업 부류에 대해 증명 가능한 보안과 맞바꿔졌다는 점이다. 질적으로 더 강한 약속인 셈이다.
  • 손실의 상당 부분은 정책이 차단하거나 사용자 승인을 요구해 자동 완료가 막힌 경우에서 온다. 즉 “실패”가 아니라 “안전 측으로 보류”한 경우가 섞여 있다.

4. 한계 — 저자와 Willison이 인정하는 것

CaMeL은 인젝션 방어의 만능열쇠가 아니다. 논문과 Willison 해설이 함께 짚는 한계:

  1. 정책 작성·유지 부담: 보안을 사용자가 직접 정책으로 명문화하고 관리해야 한다. Willison은 AWS IAM조차 보안 전문가도 어려워한다는 점을 들어, 일반 사용자에게 정책 설계를 떠넘기는 모델의 현실성에 깊은 회의를 표한다.

    “CaMeL suffers from users needing to codify and specify security policies and maintain them.” — 논문(Willison 인용)

  2. 사용자 피로(user fatigue): 승인 프롬프트가 잦으면 사용자가 반사적으로 모두 “허용”을 눌러 방어가 무력화된다. 보안 UX의 고전적 실패다. Willison은 더 나은 기본값(defaults)과 UI 설계가 관건이라고 본다.

  3. 부수 채널(side channel): taint 추적이 명시적 데이터 흐름은 막아도, 모델 출력에 정보가 미묘하게 새어 나오는 부수 채널까지 완전히 봉쇄하지는 못한다.

  4. 신규 인프라 비용: 커스텀 Python 인터프리터와 정책 엔진이라는 새로운 스택을 도입하고 운영해야 한다. 기존 에이전트 프레임워크에 그대로 얹기 어렵다.

  5. 적용 범위: 모든 인젝션을 막는 것이 아니라, 제어 흐름을 신뢰된 쿼리로 표현할 수 있는 작업 부류에 한해 보장을 준다. 작업이 본질적으로 신뢰 불가 데이터에 따라 분기해야 하면 보장이 약해진다.

Willison의 종합 평가는 “promising but incomplete”다. 방향은 옳지만 기본값과 UI가 더 성숙해야 실전 배포가 가능하다는 것이다.

5. 시사점 — 강사·컨설턴트용

  • “설계로 막는다”의 의미: 인젝션 방어를 모델 능력(확률)에 맡기지 말고 시스템 경계(결정론)로 옮긴다는 뜻이다. 이것이 가드레일 회의론(01_08-적대적-오염-위협지형)에 대한 건설적 답이다.
  • Dual LLM에서 CaMeL로 이어지는 계보: 강의에서 방어를 가르칠 때 분리(Dual LLM)와 흐름 추적(CaMeL)을 한 쌍으로 묶는 편이 좋다. 분리만으로는 데이터가 도구 인자로 새는 경로를 막지 못한다는 점이 핵심 학습 포인트다.
  • 07 거버넌스 연결: capability/taint는 보안의 출처 추적(provenance, data lineage) 개념과 같은 구조다. 에이전트 거버넌스를 설계할 때 어떤 데이터가 어떤 도구의 어떤 인자로 흐르는지를 정책으로 명문화하는 출발점이 된다.
  • 컨설팅 시 현실 점검: 도입할 때 정책 작성 주체와 승인 UX(피로 방지)를 반드시 함께 설계해야 한다. 기술만 들이고 정책과 UX를 빼면 실패한다.

요약·체크리스트

  • 제목과 이름 구분: 논문 제목은 “Defeating Prompt Injections by Design”, 시스템명은 CaMeL. 위조 제목 인용 금지.
  • CaMeL = Dual LLM 분리 + 커스텀 Python 인터프리터로 제어/데이터 흐름 분리 + capability/taint 추적.
  • P-LLM(특권)은 신뢰된 쿼리를 코드로 바꿔 제어 흐름을 확정하고, Q-LLM(격리)은 신뢰 불가 콘텐츠를 파싱한다(도구 권한 없음).
  • 신뢰 불가 데이터는 taint 태그가 붙어 전파되고, 도구 호출 직전 보안 정책이 차단하거나 승인을 요구한다.
  • AgentDojo: 77%(증명 가능 보안) vs 84%(무방어). 7%p 손실로 강한 보안 보장을 얻는다.
  • 한계: 정책 작성·유지 부담, 사용자 피로, 부수 채널, 신규 인프라 비용.
  • 형제 노트 01_09-처방-방어전략(처방 종합), 01_08-적대적-오염-위협지형(위협 지형)와 함께 읽을 것.

참고문헌