SIEVE: Selective Integrity Verification and Escalation for Defending LLM Agents against Indirect Prompt Injection

Mingjie Tang; Tianze Hu; Zaiye Chen; Zhibo Liang

REVIEW 3 major objections 6 minor 10 references

A two-tier defense blocks indirect prompt injection in AI agents with a 0.34% attack success rate.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-04 06:37 UTC pith:YO6J34WK

load-bearing objection The two-layer intent-graph/adjudicator design is a real idea, but the submitted paper is internally inconsistent and the provenance check has a bypass that breaks its central universal-deviation claim. the 3 major comments →

arxiv 2512.06716 v3 pith:YO6J34WK submitted 2025-12-07 cs.AI cs.CLcs.CR

SIEVE: Selective Integrity Verification and Escalation for Defending LLM Agents against Indirect Prompt Injection

Zhibo Liang , Tianze Hu , Zaiye Chen , Mingjie Tang This is my paper

classification cs.AI cs.CLcs.CR

keywords indirect prompt injectionLLM agentsintent graphcontrol-flow integritydata-flow integritytiered adjudicationselective verificationagent security

verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper argues that every indirect prompt injection, however disguised, must eventually move the agent's actions off the plan a legitimate user would have wanted. It therefore builds a defense from two parts: a pre-generated Intent Graph that cheaply checks whether each tool call and each argument's origin fits that plan, and a deeper adjudicator that reviews only the actions the graph flags. The claim is that this selective split keeps attack success near zero while preserving the agent's usefulness and spending far fewer tokens than methods that re-check every step semantically. A sympathetic reader should care because it points to a practical way of securing autonomous agents without disabling them.

Core claim

The paper's central claim is that any IPI attack, no matter how subtle, must produce a detectable deviation in the action trajectory—either in control flow (unexpected tool calls or ordering) or in data flow (parameter values that come from the wrong source). CCA operationalizes this by generating, before execution, a directed acyclic graph of legitimate tool calls with placeholders for where each parameter may come from. Every proposed action is checked against this graph; only deviations escalate to a tiered adjudicator that computes a weighted Intent Alignment Score from four signals: semantic similarity to the user goal, causal necessity, source trustworthiness, and inherent action risk.

What carries the argument

The Intent Graph—a pre-generated DAG whose nodes are planned tool calls and whose edges are valid transitions, with parameter provenance placeholders such as 'nodes.node_2.output'—carries the first layer by deterministically verifying both control flow and data flow. The Tiered Adjudicator carries the second layer: for any deviation it computes the Intent Alignment Score, a weighted sum of semantic alignment (cosine similarity of embeddings), causal contribution (LLM judgment of necessity), source provenance (a trust score for the triggering external source), and inherent action risk (a static per-tool hazard value). The work these two mechanisms do is to reserve expensive semantic reasoning

Load-bearing premise

The data-flow check treats any value coming from the user's instruction or an already-approved tool output as trustworthy, without checking whether that approved tool itself read attacker-controlled content.

What would settle it

Take a task whose intent graph includes a read-file step, plant a malicious instruction inside that file, and have the file's output supply a parameter for a later on-graph action; if the reported near-zero attack success rate rises substantially, the provenance layer's blind spot is confirmed.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

Deterministic structural checks can catch most IPI attempts, so defenses no longer need to run an LLM judge on every proposed action.
Because benign deviations can be approved and the graph updated, the agent retains flexibility and high utility under attack rather than being locked into a rigid plan.
The provenance placeholders shift the defense from semantic suspicion of values to structural enforcement of where values came from.
Token and latency overhead fall proportionally to how often deviations occur, making full-lifecycle supervision practical for deployed agents.
The framework's reported balance reverses the usual security–functionality trade-off: attack success drops while utility stays near the undefended level.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The provenance guarantee is only as strong as its definition of 'approved upstream node': if a tool reads attacker-controlled content, its output is tainted yet still counts as an approved source, so a stealthy injection could ride through Layer 1 to the adjudicator.
The ablation results suggest the causal-contribution score carries most of the security weight; if an attacker can craft an action whose causal justification is coherent to an LLM, the other three scores may only add marginal protection.
A testable extension would vary the static inherent-risk table and the score threshold to measure how much security comes from the risk prior versus the semantic layer.
For open-ended or exploratory tasks where a complete intent graph cannot be drawn in advance, the framework would likely need to relax Layer 1 or fall back to continuous adjudication, trading away its main efficiency gain.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Desk Editor's Note

The two-layer intent-graph/adjudicator design is a real idea, but the submitted paper is internally inconsistent and the provenance check has a bypass that breaks its central universal-deviation claim.

read the letter

Quick take: this is a more interesting architecture than the title/abstract suggests, but it is not the paper the abstract describes, and the load-bearing security claim has a hole that the evaluation never probes.

What's new: the CCA design in the full text—pre-generating an Intent Graph, enforcing control-flow and data-flow checks with parameter provenance placeholders, and escalating only deviations to a tiered adjudicator with a weighted alignment score—is a coherent and reasonably original combination. The ablation study and efficiency numbers (3.3x token reduction vs MELON) give some evidence that the two-layer strategy can work, and the graph-update ablation is a nice touch. The risk-score tables and prompts are included, which helps reproducibility.

Where it gets soft: first, the submission is internally incoherent. The title, abstract, and results in the abstract describe SIEVE (with AgentLure and AgentDojo, baselines MELON, DRIFT, IPIGuard, ARGUS). The full text is CCA, evaluated only on AgentDojo against a different baseline set, and IPIGuard is never evaluated. That's not a name typo; the claims in the abstract are unsupported by the body. Second, the central claim in §3.1—that every IPI produces a detectable deviation in control flow or data flow—is false as stated. The data-flow check in §3.2 verifies parameter origin, not value. If an upstream node (like read_document) returns attacker-controlled content, a parameter sourced from that node passes the check, and the malicious value is executed without reaching the adjudicator. The paper's own notes.txt example poisons exactly that upstream node. The stress-test note is right: this isn't a sub-component bug, it breaks the universal-deviation premise. The paper's limitations section admits the risk score is static and provenance is static, but never acknowledges this bypass.

Third, the empirical support is thinner than it looks: hand-set weights, fixed threshold, single runs for most results (the DeepSeek-V3.2 error bars help), no code release, and the most relevant graph-based baseline (IPIGuard) is missing. So the numbers in Table 1 are suggestive, not conclusive.

Who this is for: people working on agent security, specifically on plan-based defenses. They'll find the architecture worth engaging with even if the current claims don't hold.

Recommendation: as submitted, I would not accept the claims. The abstract/body mismatch alone would need fixing before any serious review. But the architectural idea is real and the evaluation effort is substantial, so I'd send it to peer review with a request for major revision: make the title/abstract match the full text, address the provenance bypass (either by adding value inspection or narrowing the guarantee), and add IPIGuard and repeated runs. My verdict would be revise—not reject the underlying approach.

Referee Report

3 major / 6 minor

Summary. The paper (body title and content) presents the Cognitive Control Architecture (CCA), a two-layer defense for LLM agents against indirect prompt injection (IPI). Pillar I pre-generates an Intent Graph of legitimate tool calls and validates each proposed action's control-flow and data-flow provenance. Actions that fail this deterministic check are escalated to Pillar II, a Tiered Adjudicator that computes a weighted alignment score from semantic, causal, provenance, and inherent-risk sub-scores. The paper reports on AgentDojo that CCA achieves 0.34% ASR, 87.63% benign utility, and 86.43% utility under attack, with lower token consumption than MELON, plus a model-agnostic study on Kimi K2 and further experiments on Qwen3-Next-80B and GPT-4.1-mini. The abstract, however, refers to a different system name (SIEVE), a different benchmark (AgentLure), and additional baselines (DRIFT, ARGUS, IPIGuard) that do not appear in the body.

Significance. If the central invariant were established, CCA would offer a practical security–functionality–efficiency trade-off for IPI defense: a deterministic first layer for cheap filtering and a semantic adjudicator only for deviations. The paper is also honest in stating some limitations (static risk scores, open-ended task constraints). The layered design and the efficiency measurements are useful contributions. However, the load-bearing claim that every IPI manifests as a detectable control-flow or data-flow deviation is not supported by the implemented checks, and the evaluation apparatus (single runs, hand-set weights, missing baselines, no released code) is too thin to back the reported trade-off numbers.

major comments (3)

[§3.1–3.2, Fig. 1, Algorithm 1] The central security claim is not established. Section 3.1 states that any IPI attack must cause a detectable deviation in control flow or data flow. But the data-flow check in Section 3.2 and Algorithm 1 only verifies that a parameter's value originates from the user instruction or an approved upstream node; it does not inspect the value itself. An upstream node can return attacker-controlled content, exactly as in the paper's motivating example (Figure 1, poisoned notes.txt). If the Intent Graph already contains a tool such as send_email whose recipient parameter is sourced from nodes.<read_document>.output, an injection that changes the recipient to an attacker-controlled address will pass both the control-flow and data-flow checks, so the Tiered Adjudicator is never triggered. The evaluation's attack strings in D.1 are framed as causing a different tool call or following an injected
[Abstract vs. body; §4.1, Table 1] The abstract describes a different system (SIEVE) evaluated on AgentLure and AgentDojo against MELON, DRIFT, IPIGuard, and ARGUS, with reported numbers such as 5.94% ASR on AgentLure. The body is entirely about CCA, evaluates only AgentDojo, and Table 1 lists only No Defense, DeBERTa, Spotlight, Repeat Prompt, and MELON as baselines. IPIGuard is discussed in Section 2 as related work but is never evaluated, and DRIFT and ARGUS appear nowhere in the body's experiments. The claimed state-of-the-art comparison and benchmark results are therefore not verifiable from the manuscript.
[§4.1, B.1, E.2, Table 4] The empirical support for the headline numbers rests on hand-set weights (w_sem=0.1, w_causal=0.7, w_prov=0.1, w_risk=0.1) and a fixed threshold of 0.5, with no sensitivity analysis. The main tables report a single run; error bars are only provided in E.2 for one attack and one model. The ablation study in Table 4 renormalizes the remaining weights after removing a component, so the observed ASR changes (e.g., w/o S_causal jumping to 4.95%) may be partly an artifact of the weight renormalization rather than a clean measure of the component's contribution. In addition, B.1 states that S_prov was made static, so the dynamic provenance mechanism in Eq. (4) is not tested. These issues do not prove the approach is ineffective, but they substantially weaken the paper's quantitative claims.

minor comments (6)

[Abstract/Title] The body uses 'Cognitive Control Architecture (CCA)' and the title says 'SIEVE'. The paper should be internally consistent about the system name and the claims in the abstract.
[Eq. (2)] The formula for S_sem is written as 'cos(...) + 1 / 2', which is ambiguous. Presumably it means (cos(...) + 1) / 2, but the parentheses should be shown explicitly.
[Algorithm 1] The pseudocode handles APPROVE and BLOCK outcomes of the TieredAdjudicator but not the ASK_USER outcome that is described in Section 3.3 and Figure 2.
[Table 1] The entry 'Melon0' appears to be a formatting error; it should be 'MELON' with the reported 0 ASR for the Direct and Ignore-Prev columns.
[References] The reference list contains typos and inconsistent formatting, e.g., 'OW ASP Foundation' should be 'OWASP', and arXiv identifiers are not uniformly formatted.
[Figure 4] The DSR–TSR trade-off plot in Figure 4(a) uses abbreviations defined only in the caption; the reader has to infer that DSR = 100% − ASR and TSR = UA from the caption text. A direct definition in the main text would help.

Circularity Check

0 steps flagged

No significant circularity: CCA's design is an empirical defense with externally benchmarked results; the noted provenance gap is a correctness assumption, not a definitional reduction.

full rationale

The paper does not present a formal derivation in which a predicted quantity is equal to a fitted input by construction. The central claim—that IPI attacks manifest as control-flow or data-flow deviations—is an architectural premise motivating the Intent Graph and Tiered Adjudicator, not a result derived from those components. The Intent Graph is generated from the user goal by an LLM, and runtime actions are compared against it; this is a monitoring mechanism, not a self-referential equation. S_align is a manually weighted combination of heuristic sub-scores, and the reported ASR/BU/UA figures are measurements on the external AgentDojo benchmark. Even if one worries that the risk table and weights are benchmark-specific, the paper does not claim they were derived from first principles, and no fitted parameter is renamed as a prediction. The data-flow provenance check's reliance on approved upstream nodes is a genuine correctness limitation—an upstream node can return attacker-controlled content, as the paper's own notes.txt example shows—but this is an unproven completeness assumption, not circularity: the defense does not define attack success into existence. The paper also does not rely on load-bearing self-citations or imported uniqueness theorems; its references to IPIGuard, ReAct, and MELON are external prior work. No specific reduction from output to input can be exhibited, so the appropriate circularity verdict is none.

Axiom & Free-Parameter Ledger

3 free parameters · 5 axioms · 0 invented entities

The design depends on hand-set weights and risk scores rather than fitted data; the architecture assumes a pre-plannable intent graph, provenance implies trust, and the adjudicator's semantic/causal scores are reliable. No new physical or mathematical entities are introduced.

free parameters (3)

Alignment weights w_sem, w_causal, w_prov, w_risk = 0.1, 0.7, 0.1, 0.1
Hand-set in B.1 with no tuning or sensitivity analysis; directly determines S_align and therefore every approval/block decision.
Decision threshold on S_align = 0.5
Fixed by authors in B.1; actions with S_align >= 0.5 are approved. No robustness analysis around this threshold is reported.
Static Inherent Action Risk Score table (S_risk) = Per-tool values, e.g. transfer money=1.0, delete file=0.9, read file=0.1
Hand-coded mapping in Table 5; parameter-agnostic and not learned. These values enter every S_align computation and materially affect ASR/UA results.

axioms (5)

ad hoc to paper Any IPI attack manifests as a detectable deviation in control flow or data flow distinct from the legitimate plan.
Core premise stated in §3.1. If an attack can stay on the graph's allowed transitions and provenance, it evades Layer 1 and may not be adjudicated.
domain assumption A correct and complete Intent Graph can be generated from the user goal before execution.
Section 3.2 and Algorithm 1. The paper's own limitations admit this is hardest in open-ended, exploratory tasks.
domain assumption Parameter provenance from user input or an approved upstream node implies the value is trustworthy.
Section 3.2 data-flow check. It ignores that an upstream node's output can itself be attacker-controlled, as in the read-document leading to send-email example.
domain assumption The LLM adjudicator's causal contribution score is reliable.
Equation (3) in §3.3. No calibration, adversarial evaluation, or consistency analysis of the adjudicator model is reported.
domain assumption Cosine similarity in all-MiniLM-L6-v2 embedding space is a valid measure of semantic alignment.
Equation (2). The score is used directly in S_align with no validation that this embedding captures goal-alignment semantics.

pith-pipeline@v1.3.0-alltime-deepseek · 17140 in / 11937 out tokens · 462792 ms · 2026-08-04T06:37:27.920620+00:00 · methodology

0 comments

read the original abstract

Large Language Models (LLMs) are increasingly used as the core of agentic systems due to their strong reasoning, planning, and tool-use capabilities. By interacting with external environments, LLM agents can execute real-world tasks on behalf of users rather than merely generate text. This expanded capability also amplifies the threat of indirect prompt injection (IPI), where malicious external content can manipulate agent behavior and trigger unauthorized actions, privacy leakage, or financial loss. Existing defenses generally follow two approaches. Plan- or rule-based methods constrain agent execution using predefined plans or execution rules, but may block legitimate actions that arise from dynamic runtime context. Semantic auditing methods offer greater flexibility, yet repeatedly re-evaluating proposed actions incurs substantial token and latency overhead. These limitations motivate a selective verification strategy that applies deterministic checks whenever reliable structural evidence is available and escalates only ambiguous cases. Accordingly, we propose SIEVE, which verifies tool transitions and argument sources against an Intent Graph, escalating actions that cannot pass deterministic verification to semantic adjudication. This selective design preserves flexibility while avoiding continuous semantic auditing. We evaluate SIEVE on AgentLure and AgentDojo against MELON, DRIFT, IPIGuard, and ARGUS. SIEVE achieves 5.94% ASR with 97.5% clean utility on AgentLure, and 0.34% ASR with 87.63% clean utility on AgentDojo. Compared with DRIFT and ARGUS, SIEVE incurs the lowest token consumption and the fewest API calls.

Figures

Figures reproduced from arXiv: 2512.06716 by Mingjie Tang, Tianze Hu, Zaiye Chen, Zhibo Liang.

**Figure 2.** Figure 2: The Cognitive Control Architecture (CCA). The CCA operates in two layers. First Layer [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

**Figure 3.** Figure 3: Boxplot distributions of the Intent Alignment Score [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗

**Figure 4.** Figure 4: CCA outperforms baselines in security, functionality, and efficiency. (a) DSR–TSR trade [PITH_FULL_IMAGE:figures/full_fig_p009_4.png] view at source ↗

**Figure 5.** Figure 5: Schematics for the different types of IPI attacks evaluated in our work. [PITH_FULL_IMAGE:figures/full_fig_p019_5.png] view at source ↗

discussion (0)

Reference graph

Works this paper leans on

10 extracted references

[1]

**Objective Deconstruction **: What is the single, final goal derived from the user’s instruction? What are the key entities and desired outcomes?
[2]

- **Analyze**: For each strategy, briefly list its pros and cons based on the Guiding Principles (efficiency, robustness, etc.)

**Strategy Brainstorming & Selection **: - **Brainstorm**: Internally generate 2-3 distinct high-level strategies to achieve the objective. - **Analyze**: For each strategy, briefly list its pros and cons based on the Guiding Principles (efficiency, robustness, etc.). - **Select**: Choose the most promising strategy and state the reason for your choice. A...
[3]

**Step-by-Step Decomposition **: Based on the selected strategy, break it down into the smallest necessary intermediate tool calls
[4]

**Tool & Parameter Binding **: For each step, select the most appropriate tool and identify the precise source for each parameter (user input, prior node output, or literal)
[5]

tomorrow

**Self-Critique (Red Teaming) **: - Review the complete plan draft. - **Question 1 (Necessity) **: Is every single node in this plan absolutely necessary? Can any steps be combined or eliminated? - **Question 2 (Robustness) **: What is the most likely point of failure in this plan? Have I provided a reasonable fallback? - **Question 3 (Assumptions) **: Wh...
[6]

**[Primary Directive] Original User Intent **: -{original_instruction}
[7]

**[Action History] **: ‘‘‘json {action_history} ‘‘‘
[8]

- Content:{triggering_content}

**[Triggering Content] **: The content that directly motivated the proposed action. - Content:{triggering_content}
[9]

**[Available Tools] **: -{available_tools}
[10]

reason":

**[Proposed Action] **: The specific action being audited. - Tool:{proposed_tool_name} - Parameters (JSON):{proposed_parameters} - Agent’s Stated Reason:{action_description} --- # Causal Chain Analysis (Your Task) **Step 0: Synthesize Case Summary (Internal Monologue) ** - First, review all context provided. Synthesize the entire event into a single, conc...

2024

[1] [1]

**Objective Deconstruction **: What is the single, final goal derived from the user’s instruction? What are the key entities and desired outcomes?

[2] [2]

- **Analyze**: For each strategy, briefly list its pros and cons based on the Guiding Principles (efficiency, robustness, etc.)

**Strategy Brainstorming & Selection **: - **Brainstorm**: Internally generate 2-3 distinct high-level strategies to achieve the objective. - **Analyze**: For each strategy, briefly list its pros and cons based on the Guiding Principles (efficiency, robustness, etc.). - **Select**: Choose the most promising strategy and state the reason for your choice. A...

[3] [3]

**Step-by-Step Decomposition **: Based on the selected strategy, break it down into the smallest necessary intermediate tool calls

[4] [4]

**Tool & Parameter Binding **: For each step, select the most appropriate tool and identify the precise source for each parameter (user input, prior node output, or literal)

[5] [5]

tomorrow

**Self-Critique (Red Teaming) **: - Review the complete plan draft. - **Question 1 (Necessity) **: Is every single node in this plan absolutely necessary? Can any steps be combined or eliminated? - **Question 2 (Robustness) **: What is the most likely point of failure in this plan? Have I provided a reasonable fallback? - **Question 3 (Assumptions) **: Wh...

[6] [6]

**[Primary Directive] Original User Intent **: -{original_instruction}

[7] [7]

**[Action History] **: ‘‘‘json {action_history} ‘‘‘

[8] [8]

- Content:{triggering_content}

**[Triggering Content] **: The content that directly motivated the proposed action. - Content:{triggering_content}

[9] [9]

**[Available Tools] **: -{available_tools}

[10] [10]

reason":

**[Proposed Action] **: The specific action being audited. - Tool:{proposed_tool_name} - Parameters (JSON):{proposed_parameters} - Agent’s Stated Reason:{action_description} --- # Causal Chain Analysis (Your Task) **Step 0: Synthesize Case Summary (Internal Monologue) ** - First, review all context provided. Synthesize the entire event into a single, conc...

2024