【6/12】 CaMeL 읽기

방어 3종 중 마지막. 훈련을 전혀 사용하지 않는 입장.

arXiv: 2503.18813 (SaTML 2026)

이 논문이 답하고 있는 질문

"기반이 되는 모델이 공격에 취약하다는 것을 전제로 한 상태에서, 시스템 설계 (Design)를 통해 프롬프트 인젝션 (Prompt Injection)에 의한 유해한 동작을 결정론적으로 방지하는 시스템 레이어를 구축할 수 있는가?"

출발점: 왜 모델을 신뢰하지 않는 설계로 했는가

IH・StruQ의 전제는 무엇이었나: 모델을 훈련하거나 (Training), 프롬프트를 개선함으로써 보안 정책 (Security Policy)을 모델 스스로 준수하게 할 수 있다는 전제.

CaMeL은 그 전제를 어떻게 다루고 있는가: 이러한 휴리스틱 (Heuristic)한 방어에는 안전성 보장이 없으며, 미지의 공격에 취약하다고 지적한다. 따라서, 모델의 거동 수정에는 일절 의존하지 않고, 모델의 외부에 보호층을 만드는 접근 방식을 취하고 있다.

OS의 비유로 말하자면, 무엇을 도입했는가: 제어 흐름 무결성 (CFI, Control Flow Integrity), 액세스 제어 (Access Control), 그리고 **정보 흐름 제어 (IFC, Information Flow Control)**와 같은 전통적인 소프트웨어 보안 개념.

전체 구성

2개 LLM의 역할 분담:
Privileged LLM (P-LLM): 사용자 쿼리만을 참조하여 태스크 실행을 위한 실행 계획 (Python 코드)을 작성하는 '플래너 (Planner)' 역할.
Quarantined LLM (Q-LLM): 신뢰할 수 없는 외부 데이터를 구조화된 데이터 (Structured Data)로 변환하는 역할. 도구 (Tool)에 대한 액세스 권한은 전혀 없다.

왜 2개로 나누는가: 신뢰할 수 없는 데이터가 시스템의 제어 흐름 (Control Flow, 프로그램의 실행 순서)에 영향을 주는 것을 방지하기 위해 (격리).
인터프리터 (Interpreter)는 무엇을 하고 있는가: P-LLM이 생성한 코드를 실행하며, 변수 간의 의 dependence (Data Flow, 데이터 흐름)를 추적하면서, 도구 호출 직전에 보안 정책을 강제 적용한다.

• P-LLM = 특권을 가진 프로세스 (계획을 세우지만, 위험한 조작은 직접 하지 않음)
• 인터프리터 = 커널 (Kernel) (실제 조작을 중개하며 권한 체크를 수행)
• Q-LLM = 비특권 프로세스 (데이터를 읽기만 할 뿐, 시스템 콜 (System Call)을 호출할 수 없음)

provenance (이력) 추적

데이터 하나하나에 무엇을 붙이는가: Capability (케이파빌리티). 해당 데이터의 '출처 (Source)'와 '허가된 열람자 (Readers)'를 기술한 메타데이터.

붙인 라벨을 사용하여 무엇을 차단하는가: 예를 들어 '기밀 파일에서 추출된 데이터'를 '신뢰할 수 없는 외부 이메일 주소'로 전송하는 것과 같은, 허가되지 않은 데이터 흐름을 동반하는 액션을 차단한다.

IH의 '우선순위' · StruQ의 '영역'과의 대응:

• IH (명령 계층)에서는 시스템 프롬프트의 '우선순위'로 보호하지만, CaMeL은 'P-LLM (특권층)'과 'Q-LLM (격리층)'이라는 물리적인 분리로 보호한다.
• StruQ가 입력 내의 '영역'을 구별하는 것에 반해, CaMeL은 '제어 흐름 (Control Flow, 프로그램의 구조)'과 '데이터 흐름 (Data Flow, 변수의 값)'을 엄격하게 구별한다.

무엇을 희생하고 있는가

유용성 저하: 특정 벤치마크 (AgentDojo)에서 방어 미적용 시 84%에서 77%로 태스크 성공률이 저하됨.

구현 비용: 전용 Python 인터프리터 구축이 필요할 뿐만 아니라, 시스템 내의 모든 도구에 대해 상세한 보안 정책을 수동으로 정의하고 유지하는 비용이 발생한다.

전제 조건: **'사용자 쿼리 (첫 번째 지시)는 신뢰할 수 있다'**는 전제가 필요하다. 또한, 외부 데이터의 내용을 확인한 후에야 다음 계획을 세울 수 있는 태스크 (Data requires action)는 원리적으로 해결할 수 없다.

위협 모델: 공격자는 무엇을 가지고 있는가

쓸 수 있는 곳: 이메일, 웹 페이지, 파일 등 에이전트가 도구를 통해 가져오는 신뢰할 수 없는 데이터 소스.

관측할 수 있는 것: 채팅 UI를 통해 사용자에게 표시되는 내용.

건드릴 수 없는 것: P-LLM에 의한 계획 수립 프로세스, 그리고 에이전트가 가진 각종 도구의 실행 권한 (Q-LLM은 도구를 가지지 않기 때문).

방어 3종 비교표 (완성 예정)

3가지 방어 기제 복기

• 공통된 목표는 무엇이었나:

"신뢰할 수 없는 외부 데이터(User/Third-party data)에 포함된 악의적인 지시가 시스템 본래의 정당한 지시(System/Developer instruction)를 덮어쓰거나 탈취(Override)하는 것을 방지하는 것".

• 가장 강력한 방어는 무엇이라고 생각하는가, 그 이유는:

CaMeL. 이유는 다른 두 방식은 모델의 학습이나 확률적인 거동에 의존하는 "확률적(Stochastic)"인 방어인 반면, CaMeL은 시스템 구조를 통해 안전성을 담보하는 "결정론적(Provable)"인 방어이며, 기반 모델(Foundation Model)이 아무리 취약하더라도 방어가 성립하기 때문.

의문이 남는 지점

• "데이터가 제어 흐름(Control Flow)으로 변하는" 공격(Section 6.4)에서, 이메일 내의 지시를 순차적으로 실행하는 루프 구조를 사용자가 구성했을 경우, Capability를 통한 이력 추적(Provenance tracking)만으로 정말 모든 악의적인 조작을 포괄할 수 있는가?
• 사이드 채널 공격(Side-channel attack, 예외 발생이나 실행 시간 차이를 이용한 정보 유출)은 실용성을 유지하면서 완전히 봉쇄하는 것이 가능한가? - 만약 P-LLM이 공격받는 2단계 공격(Two-stage attack) 형태라면 방어할 수 없는 것 아닌가? P-LLM 역시 자연어를 코드로 변환할 뿐이니까.
• 허가되지 않은 데이터 흐름(Data flow)을 동반하는 액션이라고 되어 있는데, 허가된 액션을 악용하는 것은 가능한가? (이것은 의문이라기보다 단순한 궁금증) CaMeL이 보호하는 것은 데이터 흐름(Data flow)이지, 그 흐름이 의미론적으로 올바른지는 CaMeL과 상관없기 때문.

CaMeL이 보호하는 것은 "경로"이지 "의미"가 아니다.

• 누가 무엇을 만질 수 있는가 $\rightarrow$ 보호함
• 그 데이터가 올바른가 $\rightarrow$ 보호하지 않음
• 올바른 데이터로 올바른 조작을 하더라도, 결과가 유해한가 $\rightarrow$ 보호하지 않음

Discussion