# Defense via Tool Result Parsing Research Analysis

**Paper:** Defense Against Indirect Prompt Injection via Tool Result Parsing  
**Authors:** Qiang Yu, Xinran Cheng, Chuanyi Liu (Harbin Institute of Technology)  
**Date:** January 2025  
**arXiv:** 2601.04795v1  
**Source PDF:** `docs/research/papers/2601.04795v1.pdf`

## LLMTrace Application Notes

- Required signals/features: tool outputs, tool schemas, expected output formats, and agent intent (what fields are needed).
- Runtime characteristics: medium latency (parsing/sanitization can be LLM-assisted); streaming compatible for structured outputs if chunked.
- Integration surface (proxy): sanitize tool responses before they are injected back into prompts; log sanitizer outputs for auditability.
- Productizable vs research-only: structured parsing and sanitization are productizable; LLM-based parsing quality evaluation is research-heavy.

## Paper Summary

This paper introduces a novel defense mechanism against Indirect Prompt Injection (IPI) attacks that focuses on **parsing and sanitizing tool outputs** before feeding them back to LLM agents, rather than just detecting malicious content.

### Core Innovation: Tool Result Parsing

The key insight is that tool results often contain **more data than the LLM agent actually needs**, and injected malicious instructions are typically embedded in this excess content. The approach:

**ParseData Module:**: Uses the LLM itself to extract only essential data from tool results based on:

   - Expected data format constraints 
   - Logical value validation
   - Minimal data requirements for the next reasoning step

**CheckTool Module:**: For scenarios requiring large text chunks (e.g., email summarization), detects if content triggers tool calls and sanitizes by removing trigger segments.


### Attack Types Tested

The paper evaluated against three primary attack vectors:

**"TODO" attacks:**: Direct malicious instructions prefixed with "TODO"  


**"Ignore previous" attacks:**: Classic prompt override patterns


**"Important messages" attacks:**: High-success-rate attacks using "Important Messages" headers


### DeBERTa vs. Parsing Comparison

The paper directly compares their parsing approach against **DeBERTa Detector** (the same model used by LLMTrace):

| Method | Avg UA | Avg ASR | Avg Risk |
|--------|--------|---------|----------|
| DeBERTa Detector | 34.08 | 1.19 | 3.70 |
| Tool Result Parsing | 51.84 | 0.19 | 0.35 |

**Key Results:**
- DeBERTa achieves lower utility (34.08% vs 51.84%) 
- Parsing achieves **10x lower Attack Success Rate** (0.19% vs 1.19%)
- Parsing has **10x lower risk** (0.35% vs 3.70% attacks per 100 successful tasks)

### Effectiveness Summary

The parsing approach significantly outperforms existing defenses:

**Lowest ASR to date**: (<1% across all models vs >5% for other methods)


**Competitive utility**: while maintaining superior security


**Model-agnostic approach**: that scales with LLM capabilities


**No training required**: uses prompt engineering instead


## Feature Delta with LLMTrace

### Current LLMTrace Approach

LLMTrace implements **classification-based detection**:

**DeBERTa v3**: model for prompt injection detection (`protectai/deberta-v3-base-prompt-injection-v2`)


**Regex patterns**: for known injection techniques  


**Post-hoc analysis**: detects threats after they reach the LLM


**Binary classification**: injection detected or not


### Paper's Parsing Approach

The paper proposes **proactive sanitization**:

**Parse and filter**: tool results before LLM processing


**Extract minimal required data**: based on format/logic constraints  


**Remove excess content**: where injections typically hide


**Preventive approach**: stops malicious content from reaching the LLM


### Architectural Comparison

| Approach | Paper | LLMTrace | Gap |
|----------|--------|----------|-----|
| **Detection Method** | Parsing + format validation | DeBERTa classification + regex | We classify but don't parse |
| **Intervention Point** | Pre-processing tool results | Post-detection alerting | We detect after exposure |
| **Data Handling** | Extract minimal required data | Analyse full content | We process everything |
| **Format Constraints** | Enforce strict format/logic rules | Pattern matching only | No format validation |
| **Tool Integration** | Built into tool execution pipeline | External security analysis | Not integrated with tools |
| **Attack Prevention** | Prevents malicious content reaching LLM | Detects after content processed | Reactive vs proactive |

### Critical Differences

**LLMTrace classifies**: full tool results for threats


**Paper parses**: tool results to extract only safe, required data  


**LLMTrace detects**: threats post-exposure


**Paper prevents**: threats from reaching the LLM


**LLMTrace**: has no tool result sanitization capability


## Actionable Recommendations

### Add Tool Result Parsing Capability

**Priority: High**

Implement a parsing layer in the tool execution pipeline:
- Parse tool outputs before feeding to LLM agents
- Extract only data required for next reasoning step  
- Apply format validation and logical constraints
- Filter out excess content where injections hide

**Benefits:** 10x reduction in ASR compared to classification alone

### Hybrid Detection + Parsing Approach

**Priority: Medium**

Combine existing DeBERTa detection with parsing:

**Classification for detection/alerting**: keep current capability


**Parsing for prevention**: add proactive sanitization  


**Layered defense**: detection as backup when parsing allows threats through


**Justification:** Parsing is more robust for tool result attacks, but classification provides broader coverage for other injection vectors.

### Tool Integration Requirements

**Priority: Medium**

**Intercept tool execution pipeline**: insert parsing before LLM receives results


**Pre-define data schemas**: for each tool (format, constraints, required fields)


**LLM-based parsing prompts**: leverage model capabilities for intelligent extraction


**Fallback mechanisms**: when parsing fails, apply detection + manual review


### Research Validation

**Priority: Low**

**Benchmark against AgentDojo**: validate effectiveness using same test suite


**Measure performance impact**: parsing adds latency to tool execution


**Test across attack types**: verify coverage beyond the three tested attack vectors


### Implementation Strategy

**Phase 1:**: Prototype parsing for high-risk tools (web scraping, file reading, email access)


**Phase 2:**: Integrate with existing detection pipeline as hybrid defense


**Phase 3:**: Expand parsing to all tool types with standardised data schemas


**Phase 4:**: Optimise performance and add advanced format validation


## Conclusion
The paper demonstrates that **proactive parsing outperforms reactive classification** for tool result injection defense. LLMTrace's current DeBERTa approach, while effective, operates too late in the pipeline and processes too much potentially malicious content.

**Key insight:** Instead of asking "Is this malicious?", ask "What data do I actually need from this result?" - then extract only that data, filtering out injection vectors by design.

Adding parsing capability alongside existing detection would provide **defense in depth** and significantly improve security posture against tool-based indirect prompt injection attacks.
