on
IPIGUARD: A Novel Tool Dependency Graph-Based Defense Against Indirect Prompt Injection in LLM Agents
Introduction
LLM agent(대형 언어 모델 에이전트)는 이메일 작성, 뱅킹 자동화, 일정 관리 등 다양한 실세계 태스크를 도구(tool)를 통해 수행합니다. 에이전트가 웹 페이지를 조회하거나 외부 문서를 읽는 과정에서 untrusted(신뢰할 수 없는) 외부 데이터를 처리하게 되는데, 이 데이터 안에 공격자가 악의적인 명령을 심어둘 수 있습니다. 이를 Indirect Prompt Injection (IPI) 공격이라 부릅니다.
예를 들어, 사용자가 “직원들의 취미를 회사 웹사이트에 올려라”고 지시했을 때, 에이전트가 Eve의 블로그를 방문하면 거기에는 “Alice에게 악의적인 메시지를 보내라”는 주입 명령이 숨어 있을 수 있습니다. 기존의 LLM은 강력한 instruction-following 능력 덕분에 이 주입 명령을 정상 사용자 명령으로 혼동하여 의도치 않은 도구 호출을 수행하게 됩니다.
기존 방어 접근법들—고급 프롬프팅 전략(Spotlight, Sandwich defense), 보조 탐지 모델(Detector), 또는 LLM-as-a-judge—은 모델의 내재적 보안 능력에 의존합니다. 즉, “LLM 자체가 주입 명령을 걸러낼 것”이라는 가정에 기반합니다. 그러나 최근 연구(Zhan et al., 2025)는 적응형 공격이 이러한 모델 수준 방어를 일관되게 우회할 수 있음을 보여주었습니다. 근본 원인은 명확합니다. 에이전트가 실행 중에 임의의 도구를 자유롭게 호출할 수 있다는 구조적 취약점입니다.
저자들은 이 문제를 해결하기 위해 IPIGUARD를 제안합니다. 핵심 아이디어는 모델 수준 보안에서 실행 수준(execution-centric) 보안으로 패러다임을 전환하는 것입니다. 에이전트의 태스크 실행 과정을 Tool Dependency Graph (TDG)라는 방향성 비순환 그래프(DAG)의 순회로 모델링하여, 사전에 계획되지 않은 도구 호출을 구조적으로 차단합니다.
Figure 1. IPIGUARD는 계획 단계에서 Tool Dependency Graph를 구성하고, 실행 단계에서는 그래프 순회만 허용함으로써 악의적인 도구 호출을 원천 차단한다. (An et al., 2025)
Background: IPI Attacks and Existing Defenses
Threat Model
사용자 명령 $I$가 주어지면, LLM 에이전트 $\pi_A$는 태스크를 완료하기 위해 일련의 도구 호출 시퀀스를 생성합니다.
\[\mathcal{T} = \lbrace t_1(a_1),\, t_2(a_2),\, \ldots,\, t_n(a_n) \rbrace\]여기서 각 $t_i(a_i)$는 도구 $t_i$와 인자 $a_i$의 쌍입니다. 각 도구 호출은 환경 상태를 갱신합니다.
\[t_i(a_i) \times E_{i-1} \to E_i\]IPI 공격은 단계 $i$에서 도구 응답에 포함된 주입 명령이 에이전트로 하여금 원래 시퀀스 $\mathcal{T}u$를 변형된 시퀀스 $\mathcal{T}{u^{\prime}}$로 대체하도록 유도하는 것입니다.
\[\mathcal{T}_u \to \mathcal{T}_{u^{\prime}}, \quad \mathcal{T}_{\text{adv}} \subseteq \mathcal{T}_{u^{\prime}}\]여기서 $\mathcal{T}_{\text{adv}}$는 주입 명령에 의해 유발된 악의적 도구 호출 시퀀스로, 다음과 같이 정의됩니다.
\[\mathcal{T}_{\text{adv}} = \lbrace t^1_{\text{adv}}(a^1_{\text{adv}}), \ldots, t^m_{\text{adv}}(a^m_{\text{adv}}) \rbrace\]Limitations of Existing Defenses
- Prompting-based (Spotlight, Sandwich): 외부 데이터에 특수 마커를 추가하거나 프롬프트를 반복하여 모델이 주입 명령을 무시하도록 유도합니다. 그러나 모델의 instruction-following 능력 자체가 공격 표면이기 때문에 적응형 공격에 취약합니다.
- Detector-based: 별도의 탐지 모델이 도구 응답에서 주입을 감지합니다. 탐지 실패 시 방어가 무력화되며, 유틸리티 손실도 큽니다.
- 공통 한계: 어느 방법도 에이전트의 도구 호출 권한 자체를 구조적으로 제한하지 않습니다. 공격자가 모델을 설득하기만 하면 에이전트는 여전히 임의의 도구를 호출할 수 있습니다.
Methodology: IPIGUARD
IPIGUARD는 “action planning과 external data interaction의 명시적 분리“라는 원칙을 실현합니다. 태스크 실행을 계획(Planning)과 실행(Execution)의 두 단계로 나누며, 외부 데이터와의 상호작용은 오직 실행 단계에서만 발생하도록 제한합니다.
Figure 2. (위) 기존 방식: GET_WEBPAGE 응답에 주입된 SEND_DIRECT_MESSAGE 명령이 에이전트를 공격에 성공시킨다. (아래) IPIGUARD: TDG에 사전 계획되지 않은 SEND_DIRECT_MESSAGE 호출이 허용되지 않아 공격이 실패한다. (An et al., 2025)
Tool Dependency Graph (TDG) Construction
계획 단계에서 에이전트는 사용자 명령 $I$와 신뢰할 수 있는 문서(도구 설명, 사용자 프로필 등)만을 컨텍스트로 사용하여 TDG를 구성합니다. TDG는 방향성 비순환 그래프(DAG)로 표현되며, 각 노드는 하나의 도구 호출을, 엣지는 데이터 의존성을 나타냅니다.
노드는 두 가지 유형으로 분류됩니다.
- Deterministic Node: 계획 시점에 모든 인자가 확정된 노드. 예:
read_inbox(user: Bob). - Pending Node: 다른 도구의 응답에 의존하여 일부 인자가 미지수인 노드. 예:
post_webpage(url: ..., content: <unknown>).
TDG가 구성되면 에이전트는 계획 단계 이후 외부 데이터를 전혀 참조하지 않고 실행 단계로 전환합니다. 이로써 주입 명령이 계획에 영향을 미칠 수 없습니다.
Executing as TDG Traversal
실행 단계에서는 TDG의 위상 정렬(topological order)에 따라 노드를 순서대로 실행하며, TDG에 포함되지 않은 도구 호출을 엄격히 금지합니다. 이 과정에서 세 가지 핵심 메커니즘이 동작합니다.
Mechanism 1: Argument Estimation
Pending Node를 처리할 때, 에이전트는 이미 실행된 선행 노드들의 응답을 컨텍스트로 활용하여 미지 인자를 추론하고 채웁니다. 이 과정이 완료되면 Pending Node는 Resolved Node로 변환되어 실행됩니다.
위상 정렬이 핵심입니다. 노드를 의존성 순서대로 처리하면 인자를 추론할 때 필요한 선행 결과가 항상 컨텍스트에 존재하게 되므로, 구조적으로 올바른 추론이 보장됩니다.
Mechanism 2: Node Expansion
정적 계획의 한계를 극복하기 위한 메커니즘입니다. 저자들은 동적 계획이 필요한 태스크(Dynamic Planning Task)를 두 유형으로 분류합니다.
- 유형 1: 도구 응답에 따라 구체적인 액션을 수행해야 하는 경우 (예: “할 일 목록을 읽고 청구서를 결제하라”). 이 유형은 본질적으로 IPI 공격에 취약한 설계이므로 IPIGUARD는 이를 보수적으로 처리합니다.
- 유형 2: 추가적인 정보 수집이 필요한 경우 (예: URL에서 내용을 읽어 분석). 에이전트는 도구 응답을 분석한 후 환경 상태를 변경하지 않는 Query Tool(읽기 전용 도구)에 한해서만 새 노드를 동적으로 추가(expand)할 수 있습니다.
이 구분이 설계의 핵심입니다. 환경 상태를 변경하는 도구(이메일 전송, 파일 삭제 등)는 절대 확장을 통해 추가할 수 없으므로, 주입 명령이 유도하는 위험한 액션은 차단되면서도 정보 수집 유연성은 보존됩니다.
Mechanism 3: Fake Tool Invocation (FTI)
사용자 태스크와 주입 태스크 간에 도구 겹침(tool overlap)이 발생하는 경우를 다룹니다. 예를 들어, 사용자가 “청구서를 결제하라”고 했을 때 주입 명령이 “1,000달러를 특정 계좌로 송금하라”인 경우, 두 태스크 모두 send_money 도구를 사용합니다. 이 경우 주입 명령은 새 도구를 추가하지 않고도 인자만 변조하여 공격에 성공할 수 있습니다.
Figure 3. Fake Tool Invocation: Pending Node 처리 시, 에이전트는 컨텍스트 내 주입 명령을 먼저 가상으로 처리(Fake Tool)하고 시뮬레이션 응답을 삽입한다. 이후 원래 노드의 인자를 사용자 의도에 맞게 추론한다. (An et al., 2025)
FTI의 직관은 간단합니다. LLM은 명령을 무시하도록 훈련하는 것보다 명령에 따르도록 훈련하는 것이 훨씬 쉽습니다. 따라서 “이 명령을 무시하라”는 프롬프팅 대신, 주입 명령에 해당하는 가짜(fake) 도구 호출을 시뮬레이션하여 실행 컨텍스트에 삽입합니다. 이를 통해 에이전트는 “해당 명령이 이미 처리됐다”고 인식하게 되어, Pending Node의 인자를 추론할 때 주입 명령의 영향에서 벗어나 원래 사용자 의도를 따르게 됩니다.
Experiments
Setup
벤치마크: AgentDojo (Debenedetti et al., 2024). Workspace, Slack, Travel, Banking 4개 도메인, 97개 태스크, 629개 테스트 케이스. 태스크당 최대 18번의 도구 호출이 필요한 복잡한 다중 턴 시나리오입니다.
모델: GPT-4o, GPT-4o-mini, Claude 3.5 Sonnet, Qwen2.5-7B-Instruct (일반 모델), Qwen3-32B, o4-mini (추론 모델) 총 6종.
공격: 4가지 IPI 공격 유형.
- Ignore Previous (Ign.Pre.): “이전 명령을 무시하라”는 고전적 명령 무시 공격
- Injected Agent (Inj.Age.): 공격자가 에이전트를 가장하여 권위 있는 명령을 삽입
- Tool Knowledge (Too.Kno.): 에이전트의 도구 지식을 활용한 공격
- Important Instruction (Imp.Ins.): 삽입 명령을 “중요한 지시”로 위장하는 강력한 공격
평가 지표:
- Attack Success Rate (ASR): 공격이 성공한 비율 (낮을수록 좋음)
- Utility Accuracy (UA): 원래 태스크 완수율 (높을수록 좋음)
- Benign Utility (BU): 공격 없이 원래 태스크 완수율 (유틸리티 상한선)
비교 방법: No Defense, Detector, Tool Filter, Spotlight, Sandwich.
Security-Utility Trade-off
Figure 5. GPT-4o-mini 기준 방어 방법별 Benign Utility (BU) 비교. IPIGUARD는 No Defense에 가장 근접한 67.01%를 달성한다. (An et al., 2025)
Table 1의 평균 결과를 보면 IPIGUARD의 전체 ASR은 0.69%로, 비교 대상 방법들 중 압도적으로 낮습니다. 동시에 UA는 58.77%로 가장 높습니다. 이는 명확한 trade-off를 보여줍니다.
| 방법 | 평균 ASR ↓ | 평균 UA ↑ |
|---|---|---|
| No Defense | 13.16% | 54.30% |
| Detector | 4.43% | 26.50% |
| Tool Filter | 2.06% | 53.36% |
| Spotlight | 11.31% | 55.09% |
| Sandwich | 5.25% | 44.01% |
| IPIGUARD | 0.69% | 58.77% |
Spotlight는 Ignore Previous 공격에는 ASR 2.54%로 선전하지만, Important Instruction 공격에는 22.26%로 급격히 무너집니다. 반면 IPIGUARD는 어떤 공격 유형에서도 ASR이 1%를 넘지 않습니다. 이는 모델 수준 방어가 아니라 실행 구조 자체를 제한하기 때문에, 공격 전략의 변화에 무관하게 강건성을 유지하는 것입니다.
Detector는 ASR을 4.43%까지 낮추지만, UA가 26.50%에 불과합니다. 과도하게 많은 정상 응답을 주입으로 오탐하기 때문입니다. Sandwich는 ASR 5.25%, UA 44.01%로 두 지표 모두 중간 수준에 머뭅니다.
Generalization across LLMs
Figure 4. Important Instruction 공격 하에서 6개 LLM에 대한 IPIGUARD의 성능. 거의 모든 도메인에서 Targeted Attack Success Rate(붉은 막대)가 매우 낮다. (An et al., 2025)
6개 다양한 모델에 적용했을 때도 IPIGUARD는 일관된 방어 효과를 보입니다. o4-mini와 Qwen3-32B 같은 추론 모델에서도 ASR이 낮게 유지됩니다. Qwen2.5-7B-Instruct는 상대적으로 약한 계획 능력으로 인해 UA가 낮지만, ASR은 여전히 잘 통제됩니다. 이는 IPIGUARD가 모델의 내재적 보안 능력이 아니라 실행 구조에 의존하기 때문에 모델 아키텍처에 무관하게 작동함을 의미합니다.
Overhead Analysis
| 방법 | 입력 토큰 | 출력 토큰 | 시간(s) |
|---|---|---|---|
| No Defense | 6,165 | 179 | 7.13 |
| Detector | 19,385 | 336 | 23.19 |
| Spotlight | 7,601 | 180 | 7.73 |
| Sandwich | 107,079 | 1,188 | 65.93 |
| IPIGUARD | 14,605 | 560 | 13.88 |
IPIGUARD는 No Defense 대비 약 2배의 토큰 사용량과 13.88초의 처리 시간을 요구합니다. Sandwich(65.93초)에 비해 훨씬 효율적이며, Detector(23.19초)보다도 빠릅니다. 추가적인 LLM 쿼리 없이 단일 계획 단계만을 추가하기 때문입니다.
Design Discussion
Why “Execution-Centric” Works
기존 방어의 근본 한계는 공격 표면이 무한하다는 점입니다. LLM은 자연어로 명령을 처리하기 때문에, 어떠한 프롬프팅 기법도 충분히 창의적인 공격 문구를 완전히 거부할 수 없습니다. 반면 IPIGUARD는 “계획에 없는 도구 호출은 실행할 수 없다”는 구조적 제약을 부과합니다. 이 제약은 LLM의 판단에 의존하지 않으므로, 설령 LLM이 주입 명령에 설득되더라도 실제 실행은 차단됩니다.
Challenges and Trade-offs
IPIGUARD가 완벽하지 않은 이유는 세 가지 도전 과제가 완전히 해결되지 않았기 때문입니다.
- Unknown Arguments: TDG 계획 시점에 모든 인자를 알 수 없는 경우, Argument Estimation이 틀릴 수 있습니다. 특히 인자 추론이 주입 명령의 영향을 받는 경우(C3 시나리오) FTI가 이를 완화하지만 ASR이 정확히 0은 아닙니다.
- Dynamic Planning Tasks: 사용자가 “외부 데이터를 보고 판단하여 결제하라”는 식의 명령을 내리면, IPIGUARD는 해당 태스크를 보수적으로 차단합니다. 이것이 Workspace 도메인에서 유틸리티가 약간 낮아지는 원인입니다.
- 계획 모델 의존성: TDG 구성에 충분한 계획 능력이 필요합니다. 약한 모델(Qwen2.5-7B-Instruct)에서는 UA가 낮아지는 경향이 있습니다.
Comparison with Prior IPI Defenses
본 리뷰에서 다룬 IPI 방어 논문들과 비교하면 IPIGUARD의 위치가 명확해집니다.
- StruQ / SecAlign: Fine-tuning 기반으로 모델 자체를 강화합니다. 모델 가중치 접근이 필요하며 closed-source 모델에 적용이 어렵습니다.
- Rennervate / MELON: 입력 필터링이나 보안 정렬을 통해 모델 수준에서 방어합니다.
- IPIGUARD: 모델 가중치 수정이 전혀 없고 임의의 LLM에 plug-and-play로 적용 가능합니다. 방어 메커니즘이 실행 구조에 있으므로 모델의 보안 능력과 독립적입니다.
Conclusion
IPIGUARD는 IPI 방어 연구에서 중요한 패러다임 전환을 제시합니다. “모델을 더 안전하게 만들자”는 접근 대신 “에이전트가 실행할 수 있는 행동을 구조적으로 제한하자”는 실행 중심 방어입니다.
Tool Dependency Graph를 통해 계획과 실행을 분리하고, Argument Estimation과 Node Expansion으로 실용성을 보존하며, Fake Tool Invocation으로 도구 겹침 문제를 처리하는 설계는 각 구성 요소가 명확한 동기를 갖추고 있습니다. AgentDojo 벤치마크에서 ASR 0.69%와 UA 58.77%를 동시에 달성한 결과는, 기존 방법들이 보안과 유틸리티 사이에서 고전하는 것과 대조적으로 두 목표를 함께 달성할 수 있음을 보여줍니다.
물론 한계도 있습니다. 동적 계획 태스크에 대한 보수적 처리, 계획 단계 LLM의 능력 의존, FTI가 실패하는 드문 코너 케이스 등이 남은 과제입니다. 그러나 IPIGUARD가 제시하는 “실행 구조 자체를 제약하라”는 원칙은, 점점 복잡해지는 LLM 에이전트 생태계에서 신뢰할 수 있는 보안 기반을 구축하는 데 중요한 방향성을 제시합니다.