Defeating Prompt Injections by Design 요약 설명

이번 글에서는 Defeating Prompt Injections by Design 논문의 핵심 포인트만 간단히 정리한다.

• 2025년 3월 24일(Arxiv)
• Debenedetti, Edoardo, Shumailov, Ilia, Fan, Tianqi, Hayes, Jamie, Carlini, Nicholas, Fabian, Daniel, Kern, Christoph, Shi, Chongyang, Terzis, Andreas, Tramèr, Florian.
• Google, Google DeepMind, ETH Zurich
• 논문 링크
• Github

영문판 보기

요약

• 언어 모델로 도구를 사용하는 대규모 언어 모델(LLM) 에이전트는 검색한 이메일, 문서, 도구 결과에 숨겨진 악성 지시를 따를 수 있다. 도구 사용 에이전트의 유용성과 보안을 평가하는 AgentDojo에서 o3 High를 사용하는 CaMeL의 정상 과제 성공률은 77.3%이며, 같은 모델의 기본 도구 호출 인터페이스를 사용하면 84.5%다. 이 구성에 보안 정책을 적용했을 때 평가한 공격 집합에서 성공한 공격은 0건이다.
• CaMeL은 CApabilities for MachinE Learning의 약자로, 신뢰하는 계획 수립과 신뢰하지 않는 데이터 처리를 분리하고 전용 Python 인터프리터로 보안 정책을 집행한다. 보안 정책은 허용되는 도구 호출을 규정한 규칙이다. 각 값의 출처와 허용된 읽기 주체를 기록하는 메타데이터인 capability를 사용해 제어 흐름과 데이터 흐름을 추적한다. 제어 흐름은 프로그램이 실행하는 동작을, 데이터 흐름은 동작 사이에서 값이 전달되는 과정을 뜻한다.
• 이 설계에는 모델에 따라 달라지는 유용성 저하, 추가 토큰 사용량, 정책 유지보수 비용이 따른다. 보안 보장은 정책의 적용 범위와 정확한 의존성 추적에 달려 있다. 오해를 유발하는 텍스트 출력과 일부 부채널은 보호 범위에 포함되지 않는다. 부채널은 실행 종료 여부나 요청 횟수처럼 관찰 가능한 동작을 통해 정보가 유출되는 경로다. 구현이 보안 요구사항을 충족함을 증명하는 정형 검증은 향후 과제로 남아 있다.

1. Introduction

프롬프트 인젝션은 외부 콘텐츠에 포함된 지시가 에이전트를 데이터 탈취나 원치 않는 동작으로 유도할 때 발생한다. CaMeL은 모델 외부에 소프트웨어 보안 통제를 적용한다. 모델 가중치를 변경할 필요가 없으며, 인터프리터가 정책 집행을 담당한다.

• 공개된 구현은 https://github.com/google-research/camel-prompt-injection 에서 확인할 수 있다.

2. Defeating Prompt Injections by Design

논문의 예시 과제는 회의록을 찾고, Bob의 이메일 주소와 요청된 문서 이름을 추출한 뒤, 해당 문서를 가져와 전송하는 작업이다. 신뢰하는 계획 수립 모델과 도구 접근 권한 없이 외부 콘텐츠를 처리하는 모델을 분리하는 Dual LLM 패턴은 계획 수립을 보호한다. 그러나 공격자는 여전히 추출되는 수신자나 파일명을 조작할 수 있다.

• CaMeL은 각 값에 데이터 출처 기록과 읽기 권한 검사를 추가한다. 따라서 동작 순서가 그대로여도 기밀 자료를 공격자가 지정한 수신자에게 자유롭게 전송할 수는 없다.
• 신뢰하지 않는 메모에서 추출한 정당한 수신자라도 해당 문서에 대한 기존 접근 권한이 없다면 승인이 필요할 수 있다.

문서 공유 작업 흐름은 동작 순서와 동작 사이에 전달되는 값을 구분한다. 공격자는 계획된 동작이나 그 인자를 바꿔 작업 흐름을 다른 방향으로 유도할 수 있다.

3. Threat Model

주요 공격자는 이메일, 문서, 스프레드시트처럼 에이전트가 가져오는 데이터를 통제하고, 이를 통해 승인되지 않은 동작을 유도한다. 위협 모델은 사용자 프롬프트를 신뢰하며, 사용자가 신뢰하지 않는 지시를 해당 프롬프트에 붙여 넣는 경우는 제외한다. 에이전트 메모리도 침해되지 않았다고 가정한다.

도구 호출 순서는 알아볼 수 있는 형태로 유지되지만, 문서 이름과 수신자는 공격자가 선택한 값으로 바뀐다. 따라서 계획 수립 모델만 보호하면 기밀 데이터가 권한 없는 수신자에게 전달되는 경로가 남는다.

3.1. Explicit non-goals of CaMeL

CaMeL은 금지된 정보 흐름을 일으키지 않으면서 요약이나 추천을 바꾸는 텍스트 간 공격을 막지 않는다. 사용자에게 피싱 메시지를 보여 주는 경우도 여기에 포함된다. 완전한 자율성도 보장하지 않는다. 요청이 모호하거나 결과가 불확실하거나 정책상 제약이 있으면 사람이 요청을 명확히 하거나 승인해야 할 수 있다.

• 출처 주석은 인터페이스가 표시된 콘텐츠의 출처를 식별하는 데 도움이 될 수 있지만, 콘텐츠가 사실이거나 무해함을 보장하지는 않는다.

4. The Prompt Injection Security Game

논문의 프롬프트 인젝션 보안 게임인 PI-SEC은 공격자가 도구로 접근할 수 있는 초기 상태를 선택해 안전하지 않은 실행을 유도하는 상황을 모델링한다. 에이전트는 각 도구 호출, 인자, 실행 당시 상태를 기록한 (tool, args, mem_step) 튜플의 Trace를 생성한다. 사용자 프롬프트가 허용하는 동작 집합인 Ω_prompt를 벗어나는 동작이 발생하면 공격자가 승리한다.

• Ω_prompt는 보안을 개념적으로 정의하며, CaMeL이 실행 중에 이 집합을 열거하지는 않는다.

검증기는 기록된 도구 동작이 허용 집합에 속하는지 검사한다. 이는 보안 목표를 정의하지만, 허용되는 모든 동작을 실용적으로 열거하는 방법을 제공하지는 않는다.

5. CaMeL Design

CaMeL은 2가지 모델 역할, 도구, 보안 정책, 값별 capability, 생성된 코드를 실행하면서 의존성을 전파하는 인터프리터로 구성된다. 인터프리터는 도구를 호출하기 전에 제안된 동작과 입력이 설정된 정책을 충족하는지 검사한다. 보안 게임의 설명에서는 검사에 실패하면 실행을 중단한다.

5.1. The Privileged and Quarantined LLMs

실행 계획을 작성하는 Privileged LLM(P-LLM)은 신뢰하는 요청과 도구 명세를 받지만, 도구가 반환한 값이나 파싱된 외부 콘텐츠는 보지 않는다. 도구 접근 권한 없이 신뢰하지 않는 데이터를 파싱하는 Quarantined LLM(Q-LLM)은 미리 정의된 스키마에 맞는 구조화된 출력을 반환한다. 스키마는 출력 필드와 타입을 지정한다.

• 추가 불리언 필드인 have_enough_information은 NotEnoughInformationError를 발생시킬 수 있다. Q-LLM은 어떤 정보가 부족한지 계획 수립 모델에 설명할 수 없다. 그 설명에 인젝션이 포함될 수 있기 때문이다.
• 2가지 역할에는 서로 다른 기반 모델을 사용할 수 있다. 데이터 처리 역할을 로컬에서 실행하는 방안은 개인정보 보호에 도움이 될 가능성으로 논의되며, 배포 실험으로 평가한 결과는 아니다.

계획 수립과 외부 콘텐츠 파싱은 별도의 모델 역할이 담당하며, 인터프리터는 의존성을 유지하고 정책을 검사한다. 악성 콘텐츠가 파싱 모델의 출력에 영향을 주더라도 보안 판단은 실행 시스템이 내린다.

5.2. Security Policies

보안 정책은 도구 이름과 인자를 검사하고 사유와 함께 Allowed 또는 Denied를 반환하는 Python 함수다. 캘린더 예시에서는 참가자 정보가 신뢰하는 출처에서 왔다면 공유를 허용한다. 그렇지 않으면 참가자들이 이벤트의 title, description, location, start_time, end_time을 읽을 수 있는지 검사한다.

• 구현에서는 CaMeL 엔진을 통해 정책을 제공한다. 사용자 정의 정책, 제공자 정의 정책, 자동으로 도출한 정책은 확장 방안으로 제안한다.
• 정책 언어는 임의의 Python 로직을 허용하므로, 정책의 정확성을 확보하고 충돌을 해결하는 일도 보안상 과제다.

5.3. Capabilities

Capability는 파생된 값을 포함한 개별 값에 출처와 허용된 읽기 주체 정보를 부여한다. 읽기 주체는 Public 또는 사용자 집합으로 표현한다. 출처는 User 리터럴, CaMeL 변환, 특정 도구를 구분하며, 선택적으로 이메일 발신자 같은 내부 출처도 기록한다.

• 이처럼 세밀하게 구분하면 예약 도구에 정당하게 필요한 이름, 전화번호와 해당 도구에 전달하면 안 되는 여권번호를 구별할 수 있다.

5.4. CaMeL Interpreter

전용 인터프리터는 Python의 ast 라이브러리로 프로그램 구조를 파싱한 표현인 추상 구문 트리를 순회하며 제한된 Python 부분집합을 실행한다. 값의 의존성을 추적하고 도구 실행 전에 정책을 검사한다. 또한 인터프리터 상태를 유지하면서 계획 수립 모델이 실행 오류를 수정하도록 최대 10회의 시도를 허용한다.

• 신뢰하지 않는 값에 의존하는 예외 텍스트는 P-LLM에 전달하기 전에 가린다.
• STRICT 모드는 조건식과 반복 대상의 의존성을 해당 블록 내부로 전파한다. NORMAL 모드는 값이 연산의 실행 여부에 영향을 미칠 때 생기는 암묵적 의존성을 더 적게 추적한다.
• 구현은 일련의 동작을 나눌 수 없는 단위로 완료하는 원자적 실행을 지원하지 않으며, 이미 부수 효과가 발생한 동작을 되돌리는 롤백도 제공하지 않는다.

발신 이메일은 이메일 내용뿐 아니라 Q-LLM의 조건부 판단에도 의존한다. 이메일 전송 여부 자체가 정보를 공개할 수 있으므로 이 암묵적 의존성을 기록해야 한다.

6. Evaluation

평가에는 AgentDojo의 Workspace, Banking, Travel, Slack 환경을 사용한다. 유용성은 사용자 과제를 성공적으로 완료했는지를 측정하고, 보안은 공격자가 공격 목표를 달성했는지를 측정한다.

• 기본 도구 호출 인터페이스, 격리만 적용한 CaMeL, 정책을 적용한 CaMeL, 기존 AgentDojo 방어 기법을 비교한다.
• 주요 보안 비교에는 공격 949건을 사용한다. 이 실험은 벤치마크에서의 동작을 측정하며, 구현을 정형 검증하지는 않는다.

6.1. Utility evaluation

유용성은 기반 모델에 따라 크게 달라진다. o3 High는 84.5%에서 77.3%로, o4 Mini High는 79.4%에서 76.3%로, Gemini 2.5 Pro는 73.2%에서 41.2%로 낮아진다. 평가한 Gemini 모델 2개 모두 CaMeL을 적용한 정상 Travel 과제 유용성이 0.0%인 반면, Claude 4 Sonnet은 75.0%를 기록한다. Claude 4 Sonnet을 P-LLM으로 사용하면서 Q-LLM에 Claude 3.5 Haiku를 사용하면 유용성은 약 1% 낮아지고, 과제 비용 중앙값은 추정치로 12% 줄어든다.

• 6.1.1. CaMeL has a (small) Impact on Utility의 상세 결과는 일부 모델이 실용적인 성능을 유지함을 보여 주지만, 유용성 저하가 모든 모델에서 작지는 않다.
• 6.1.2. How does CaMeL impact utility?에서는 필요한 동작이 외부 데이터에만 명시되어 있거나, 도구 반환 형식이 문서화되지 않았거나, 계획 수립 모델이 Q-LLM에 충분한 맥락을 제공하지 않을 때 실패가 발생한다고 설명한다. Table 1은 Claude 3.5 Sonnet의 실패 13건을 문서화되지 않은 Travel 인터페이스 탓으로 분류한다.
• 6.1.3. Cheaper Q-LLM Models Have Little Impact on Utility에서는 GPT 4.1 Nano를 Q-LLM으로, o4 Mini High를 P-LLM으로 사용했을 때도 유용성이 비슷하게 감소했다고 보고한다.

과제군별 막대는 모델과 환경에 따라 유용성 저하가 고르지 않음을 보여 준다. 2개 Gemini 모델의 Travel 유용성은 0으로 떨어지는 반면, o3 High와 o4 Mini High의 일부 Banking 및 Travel 결과는 개선된다.

표에서 문서화되지 않은 인터페이스에 따른 Travel 실패 수는 13이며, 데이터에 따라 추가 동작이 필요한 사례와 Q-LLM 맥락이 부족한 사례는 각각 5건이다. 질의 오해 행의 합계는 1이지만, 캡션은 이를 ‘2 instances’로 설명한다.

전체 정상 조건 유용성 결과는 o3 High에서 CaMeL의 77.3%와 기본 인터페이스의 84.5%라는 비교를 뒷받침한다. 유용성 저하는 모델에 따라 크게 다르다. Gemini 2.5 Pro의 전체 유용성은 32.0%p 낮아진다.

6.2. Security evaluation

격리만 적용해도 벤치마크 공격 성공이 크게 줄어들며, 정책을 추가하면 도구 인자와 정보 공유를 더 제한한다. Table 4에서 정책을 적용한 Gemini 2.5 Pro와 o3 High의 성공한 공격은 모두 0건이다. 그러나 Claude 4 Sonnet의 각 구성에서는 11건, Gemini 2.5 Flash에서는 1건, o4 Mini High에서는 1건이 남는다.

• 6.2.1. Case study: without any Security Policies에서 남아 있는 벤치마크상 공격 성공 사례에는 문서의 지시에 따른 결제와 삽입된 호텔 리뷰 표시가 포함된다. 저자들은 특히 리뷰를 출력하기만 해도 평가 조건을 충족하는 경우를 비롯해, 이런 사례와 보호 대상 위협 모델을 구분한다.
• 6.2.2. Case study: with Security Policies에서 Workspace는 읽기 주체를 더 정확히 주석으로 지정할 수 있어 대체로 Slack이나 Banking보다 정책 개입이 적다. Figure 10의 정책 발동률은 성공적으로 해결한 과제만을 대상으로 계산한다. 이 비율은 잠재적인 승인 부담을 나타내며, 사람의 실제 승인 행동을 측정한 결과는 아니다.
• 본문과 Figure 9는 Gemini 2.5 Pro의 기본 인터페이스에서 공격 성공 300건을 보고하지만, Table 4는 163 ± 140.1건을 보고한다. CaMeL에서는 모두 0건으로 보고하며, 기본 인터페이스의 수치는 논문 내부에서 일치하지 않는다.

격리를 적용하면 공격 성공 횟수가 크게 줄고, 정책은 인자와 정보 공유에 제약을 더한다. 남아 있는 벤치마크상 공격 성공은 위협 모델에 비추어 해석해야 한다. 그래프의 Gemini 2.5 Pro 기본 인터페이스 수치는 Table 4와 다르다.

정책 발동률은 과제군과 모델에 따라 다르며, 이는 사용 가능한 신원 정보와 읽기 주체 주석의 차이를 반영한다. 분모에는 성공적으로 해결한 과제만 포함된다. 이 비율은 잠재적인 개입 부담을 나타내며, 관찰된 사용자 승인 비율은 아니다.

표는 여러 모델 구성에서 CaMeL의 공격 성공 횟수가 0이 아님을 보여 주므로, 모든 구성에서 공격 성공이 0건이라고 주장할 수는 없다. Gemini 2.5 Pro 기본 인터페이스의 163 ± 140.1건이라는 수치는 본문의 값과 일치하지 않는다.

6.3. Baseline comparisons

비교 기준에는 도구 출력 뒤에 원래 과제를 반복하는 Prompt Sandwiching, 신뢰하지 않는 콘텐츠를 표시하는 Spotlighting, 사용 가능한 도구를 제한하는 Tool Filter가 포함된다. Claude 3.5 Sonnet을 사용한 Table 7에서 성공한 공격은 정책을 적용한 CaMeL이 0건, 정책이 없는 CaMeL이 1건, Prompt Sandwiching이 24건, Spotlighting이 5건, Tool Filter가 8건, 방어가 없는 모델이 44건이다. Table 5의 정상 과제 유용성은 CaMeL이 63.92%, 방어가 없는 모델이 90.72%다.

• 본문은 Tool Filter를 차선의 방어 기법으로 소개하지만, Table 7에서는 Spotlighting의 공격 성공이 5건으로 Tool Filter의 8건보다 적다.
• 논문은 GPT-4o Mini의 기본 인터페이스에서 성공한 공격이 276건인 반면 CaMeL에서는 성공한 공격이 없었다고도 보고한다. 이는 이 평가에서 모델이 학습한 지시 우선순위만으로는 동등한 보호를 제공하지 못함을 보여 준다.

함께 제시된 패널은 Claude 3.5 Sonnet에서 보안과 유용성 사이의 절충을 보여 준다. 정책을 적용한 CaMeL에서는 성공한 공격이 없지만, 여러 과제군에서 과제 유용성은 프롬프팅 방어 기법보다 낮다.

기준 방어 기법과의 비교 수치는 Claude 3.5 Sonnet에 정책을 적용한 CaMeL의 공격 성공이 0건임을 보여 준다. Spotlighting의 공격 성공은 5건으로 Tool Filter의 8건보다 적으며, 이는 차선의 방어 기법에 대한 본문의 순위와 다르다.

6.4. Case study: when data flow becomes control flow

고정된 프로그램에서도 외부 데이터가 사용 가능한 도구를 선택하게 할 수 있으며, 이 경우 데이터 흐름이 사실상 제어 흐름으로 바뀐다. 사례 연구는 모델이 생성한 계획이 이메일 지시를 동작과 인자로 파싱하는 과정을 살펴보며, 모델 격리에 더해 해당 값을 통제하는 정책이 필요한 이유를 보여 준다.

• 저자들은 그림의 공격이 원래 모델 출력을 그대로 옮긴 것이 아니라, 생성된 해법을 단순화해 공격에 활용한 것이라고 설명한다.
• 악성 동작을 개별적으로는 무해한 단계로 나누면, 과제의 일부만 처리하는 모델이 전체 의도를 파악하기 어려워질 수 있다.

파싱한 이메일 지시에 따라 도구를 호출하는 프로그램은 외부 값이 이후 동작을 결정하도록 허용한다. 따라서 프로그램 구조가 미리 정해져 있어도 신뢰하지 않는 데이터가 동작을 통제할 수 있다.

6.5. Overheads

본문은 Claude 3.5 Sonnet의 토큰 사용 배수 중앙값을 입력 2.82×, 출력 2.73×로 보고하며, 추가 사용량의 상당 부분이 코드 생성과 수정에서 비롯된다고 설명한다. 토큰 수는 토큰화 라이브러리인 tiktoken을 통해 GPT-4o 토크나이저로 계산한다. 도구 문서 토큰은 제외하고 CaMeL의 언어 명세 프롬프트는 포함한다.

• 수치 보고는 일관되지 않다. Table 10의 정상 조건 중앙값은 입력 2.73×, 출력 2.82×이며, Table 13의 공격 조건 중앙값은 입력 2.02×, 출력 2.64×다.
• 논문은 인터프리터 처리 시간이 모델 실행 시간에 비해 작다고 설명하지만, 정량적인 오버헤드 결과는 토큰에 관한 것이며 전체 배포 지연시간을 측정한 벤치마크는 아니다.

분포는 토큰 오버헤드가 과제마다 크게 다름을 보여 준다. 캡션의 입력 2.82×, 출력 2.73×라는 수치는 Table 13에 보고된 공격 조건 중앙값과 일치하지 않는다.

7. Side Channels Can Be a Problem

논문은 요청 횟수, 실행 종료 여부, 실행 시간을 통한 부채널을 살펴본다. STRICT 모드는 반복문 안의 각 연산이 비공개 반복 횟수에 의존하도록 만들어 예시의 요청 횟수 유출을 차단할 수 있다.

• 시간 측정 예시는 비공개 값을 관찰 가능한 경과 시간으로 변환한다. 구현에서는 time 모듈을 제외하므로 이 예시를 실행할 수 없지만, 다른 시간 부채널까지 배제하지는 않는다.

Exception Handling – Inferring private variable based on halted execution

공격자는 Q-LLM 출력이 비공개 값에 따라 예외를 발생시키도록 만든 뒤, 이후 이메일이나 네트워크 요청이 발생하는지 관찰해 1비트를 알아낼 수 있다. STRICT 모드는 이후 모든 문장이 Q-LLM 호출의 입력에 의존하도록 만들어 이 경로를 완화한다.

• 이 완화책은 Q-LLM이 유발한 예외와 그에 의존하는 연산을 다루지만, 도구로 접근할 수 있는 데이터를 조작해 발생시키는 예외는 여전히 가능한 경로로 남는다.
• 저자들은 성공과 실패를 값으로 표현하는 명시적 결과 기반 오류 처리를 대안으로 제안한다. 이 방식은 의존성을 더 직접적으로 드러낼 수 있다.

예시 모두 종료 여부가 비공개 값에 의존하게 만들어 이후 관찰 가능한 동작을 통해 1비트를 공개한다. 이 경로에 대해 제안된 STRICT 모드 완화책은 Q-LLM 호출 이후까지 의존성을 확장한다.

8. Secondary attack scenarios that CaMeL can help with

논문은 설치된 스파이 도구가 내부 데이터를 받지 못하도록 막는 방안과, 악의적인 사용자가 기밀 문서를 조직 외부로 보내지 못하도록 막는 방안이라는 2가지 추가 응용을 논의한다. 이 시나리오에는 개별 사용자 요청보다 상위의 권한을 가진 정책이 필요하며, AgentDojo에서 명시적으로 평가하지는 않는다.

9. Discussion

논의에서는 capability 통합에 필요한 작업, 사용자 승인 부담, 남아 있는 공격 경로를 검토한다. 보안 논거는 모델 격리뿐 아니라 주변 소프트웨어와 정책 시스템에도 의존한다.

9.1. Past problems with adoption of capabilities

Capability 기반 시스템은 상당한 구현 작업과 기존 도구 및 인프라의 수정을 요구할 수 있다. 통제된 작업 공간은 다양한 외부 서비스가 혼재한 환경보다 다루기 쉽다. 다만 저자들은 경우에 따라 에이전트가 capability를 중앙에서 관리할 수 있다고 제안한다.

9.2. De-classification and user fatigue

De-classification은 원래 금지된 정보 공개를 허용하도록 제한을 완화하는 것으로, 사용성과 보안 사이의 절충이 필요하다. 반복적이거나 모호한 승인 요청은 사용자의 경계심을 낮춰 악성 동작을 승인하게 할 수 있다. 따라서 실질적인 보호는 정책의 정밀도와 승인 인터페이스에 달려 있다.

9.3. So, Are Prompt Injections Solved Now?

저자들은 프롬프트 인젝션과 AgentDojo가 완전히 해결되지 않았다고 명시한다. 정책은 명세와 유지보수가 필요하고, 부채널도 여전히 가능하며, 개별적으로 허용된 동작을 조합해 유해한 행동을 만들 수도 있다.

• 허용된 코드 조각을 연결해 공격을 구성하는 return-oriented programming과의 비유는 가능한 실패 양상을 제시한다. CaMeL을 일반적으로 우회하는 방법을 입증한 것은 아니다.

10. Future work

향후 과제에는 오류와 입출력을 더 명시적으로 처리하는 프로그래밍 언어, 인터프리터와 정책 집행의 정형 검증, 맥락을 반영한 자동 정책 생성이 포함된다. 이는 제안된 연구 방향이며, 논문은 현재 구현에 결함이 없음을 증명하지 않는다.

11. Conclusion

결론은 CaMeL을 격리와 집행 가능한 정책으로 취약한 모델 동작의 영향을 제한하는 시스템 설계 접근법으로 제시한다. 기반 모델을 개선하는 학습 또는 프롬프팅 방어와 결합할 수 있으며, 논문에서 살펴본 정책, 구현, 부채널의 제약이 적용된다.

Contributions

Ilia Shumailov가 아이디어와 기술 설계안을 처음 제안했고, Edoardo Debenedetti가 기술 개발을 주도했으며, 이 2명이 CaMeL 설계를 공동으로 이끌었다. Tianqi Fan은 인턴십 제안을 준비하고 프로젝트 조정을 도왔다. 나머지 저자들은 기술 피드백, 검토, 원고 작성에 기여했다.

부록

• A. Extended Related Work와 A.1. Background: Software Security Concepts는 CaMeL의 바탕이 되는 보안 용어를 설명한다. A.1.1. Computer security nomenclature는 정책, 제어 흐름, 데이터 흐름, capability를 정의한다. A.1.2. Access and Information Flow Controls는 설계를 프로그램의 의도된 동작 보존, 접근 제한, 무단 공개를 방지하기 위한 정보 추적과 연결한다. A.1.3. Tool-calling LLM Agents는 도구 출력이 모델에 돌아가 이후 호출에 영향을 주는 기존 반복 구조를 설명한다.
• A.2. Prompt Injection Defenses는 구분자, 원래 과제를 반복해서 알려 주는 방식, 학습, 탐지, 모델 내부 표현 모니터링, 아키텍처 분리를 검토한다. Willison의 Dual LLM 패턴을 설계의 기반으로 설명하며, CaMeL의 명시적 의존성 추적과 세밀한 주석을 분류기나 신뢰 수준을 덜 세밀하게 구분한 레이블을 사용하는 접근법과 구분한다.
• B. Full results tables는 모델과 과제군별 정상 조건 유용성, 공격 조건 유용성, 공격 횟수를 제공한다. C. Baseline results는 Claude 3.5 Sonnet의 방어 기법 비교를 제공한다. 공격 조건에서 CaMeL의 유용성은 66.70%, 방어가 없는 모델은 86.83%이며, 성공한 공격은 각각 0건과 44건이다. 표는 공격자의 목표 달성을 막는 것과 정당한 과제를 완료하는 것을 구분한다.
• D. NORMAL vs. STRICT modes는 더 넓은 의존성 추적에 따르는 추가 정책 개입을 정량화한다. 전체 정책 발동률은 공격이 없을 때 33.87%에서 53.23%로, 공격을 받을 때 26.54%에서 45.34%로 증가한다. 함께 제시된 NORMAL 모드 의존성 그래프에서는 send_email이 Q-LLM의 조건부 판단에 의존하는 관계가 빠져 있다.
• E. Security Policy evaluation은 결제, 비밀번호 변경, 메시지, 웹 요청, 캘린더 작업, 파일 작업에 대한 도메인별 정책을 나열한다. 예시 정책은 민감한 변경에 신뢰하는 출처를 요구하고, 공개할 콘텐츠를 해당 읽기 주체가 읽을 수 있는지 확인한다. 정확한 정책 코드는 https://github.com/google-research/camel-prompt-injection/tree/45b656a0aaf688626955b12823ec0bd6af9f7df7/src/camel/pipeline_elements/security_policies 에서 확인할 수 있다.
• F. Extended overheads results는 정상 조건과 공격 조건의 토큰 총량 및 과제별 배수 분포를 제공한다. 평균과 중앙값의 차이는 과제별 편차가 상당함을 보여 준다. Table 13에서 공격 조건의 CaMeL 입력 배수는 평균 6.17, 중앙값 2.02이고, 출력 배수는 평균 5.43, 중앙값 2.64다. 이 표들의 수치는 본문의 입력 및 출력 수치와 일관되게 일치하지 않는다.
• G. Breakdown for individual failure modes for Claude 3.5 Sonnet v2는 실패를 개별 과제에 대응시킨다. H. Implementation details와 H.1. System prompt는 Built-in types, Built-in functions, Built-in methods, Imported classes, Tools functions, Available types를 문서화해 계획 수립 모델이 사용할 수 있는 프로그래밍 환경을 정의한다. Important notes on the code와 Information on the language는 구조화된 파싱, 상태 유지, 제약을 설명한다. 제약에는 import, eval, exec, while 반복문, generator, break, continue, 새 함수 정의를 허용하지 않는다는 내용이 포함된다.
• H.2. Exceptions prompt는 오류 기반 코드 수정과 신뢰하지 않는 예외 내용의 가림 처리를 문서화한다. H.3. Case-study: when control flow turns into data flow from Claude and o3-mini는 이메일에서 동작 이름과 인자를 추출하고 이에 따라 도구를 호출하는 생성 예시를 제공한다. 이 예시들은 격리된 계획 수립 모델도 외부 데이터가 동작을 선택하는 프로그램을 만들 수 있다는 본문의 경고를 뒷받침한다.
• H.4. Examples of failed tasks에는 모델이 시간 기준을 잘못 적용한 H.4.1. Workspace 11: Query misunderstanding, 필요한 연락처 정보가 방문하지 않은 웹사이트에 있는 H.4.2. Slack 11: Data Requires action, H.4.3. Workspace 18: Wrong assumptions from P-LLM이 포함된다. 마지막 사례의 도입부는 하이킹 시간을 임의로 가정한 상황을 언급하지만, 표시된 대화 기록은 점심 예시를 반복한다. H.4.4. Banking 2: Not enough context for Q-LLM은 임대료 안내문에 없는 결제 계좌 정보를 요구한다. H.4.5. Workspace 36: Q-LLM overdoes it/Strict eval은 기대한 내용을 재현하는 대신 준비물 목록을 확장한다.
• H.4.6. Banking 14: Ambiguous task는 의심스러운 거래에 대한 불확실한 판단을 보여 주며, 도입부의 연도는 표시된 거래 날짜와 다르다. H.4.7. Travel 19: Underdocumented API는 응용 프로그래밍 인터페이스(API)와 관련해 파싱과 수정이 반복해서 실패하는 사례를 보여 준다. H.4.8. Travel 19: AgentDojo Bug는 응답이 운영 시간을 제공했는데 평가기는 요일을 기대하는 상황을 설명한다. I. More sophisticated side-channel은 예외에 따라 완료 여부가 달라지는 특성을 이용해 비공개 캘린더에 Bob과의 회의가 있는지 알아낼 수 있는 회의 요약 시나리오를 제시한다. 이 과정은 최대 10회의 수정 시도에 걸쳐 이루어질 수 있다.

짧은 생각

CaMeL의 주요 기여는 보안 집행을 언어 모델 외부에 두는 구체적인 아키텍처다. 문서 공유와 데이터 기반 도구 호출 예시는 계획 수립 격리와 값별 검사가 모두 필요한 이유를 설명한다. 배포를 검토할 때는 벤치마크 결과와 함께 모델별 유용성 저하, 실제 정책 적용 범위, 도구 주석, 잠재적인 승인 부담, 암묵적 정보 흐름을 평가해야 한다. 수치 불일치와 구현에 대한 정형 검증의 부재로 인해 더 강한 주장을 뒷받침하기는 어렵다.