IPIGuard++: Effect Authorization and Witness-Carrying Argument Checks for Tool-Using Agents

Abstract

Tool-using language agents complete tasks by interpreting external records and issuing calls that can change application state. Because these operations can depend on adversarial evidence delivered through indirect prompt injections, preserving the user’s authority requires control over both the permitted operations and their sensitive arguments. Existing defenses separate privileged instructions from data, assess task alignment or constrain execution through structured plans. IPIGuard++ addresses these linked decisions through asymmetric graph elasticity and witness-carrying argument checks within the IPIGuard execution path. Plan voting and trusted-intent recovery establish effect authorization before tool data arrive, while bounded read repair supplies missing information without expanding the authorized effect scope. Paired raw and quarantined evidence supports non-executing comparison, and deterministic witnesses match proposed values to explicit computations. Catalog closure and constraint-filter-then-rank certificates extend this design to supported selection tasks that depend on multiple candidates and attributes. Across the AgentDojo evaluation, IPIGuard++ improved mean utility over IPIGuard in all four reported seeds and achieved higher overall utility on clean tasks, with no observed targeted attack successes in the repeated attack experiments. These results support IPIGuard++ as an effective execution-layer defense that improves task completion while preserving security across the tested settings. Overall, IPIGuard++ connects action authority, information acquisition, and argument resolution within one execution policy for agents processing untrusted content, including adversarial evidence.

1. Introduction

Large language model (LLM) agents use software tools to turn requests into actions, including retrieving documents, arranging meetings and making payments. For example, completing a scheduling request can require an agent to read a message, identify participants and update a calendar. Because these operations depend on external content, the agent must interpret information whose author may differ from the person who authorized the task. External records can carry embedded instructions that redirect subsequent tool calls, a threat known as indirect prompt injection. Consequently, the security boundary concerns both the actions an agent may perform and the data that determine their parameters. This combination makes tool-using agents a useful setting for studying how an application can preserve user authority while processing untrusted evidence [1,2].

Protecting this boundary has motivated defenses at several points in the agent’s execution. At the instruction level, structured input separation and preference-based training teach models to distinguish privileged requests from external data [3,4]. At the action level, Task Shield assesses whether instructions and tool calls serve the user’s objective, whereas GuardAgent converts safety requirements into executable checks [5,6]. Execution architectures restrict permitted operations or information flows [7,8]. Within this family, IPIGuard constructs a tool dependency graph (TDG) before retrieving untrusted data and traverses that graph to complete the task [2]. Its argument estimation, query-node expansion and Fake Tool Invocation mechanisms illustrate why an effective execution policy must accommodate information that becomes available only after planning.

The need for later information creates a specific tension between action authority and task completion. An authorized calendar update may rely on an initial plan that omits the read needed to determine an event’s duration. In this case, an additional read can complete the evidence required for the update, although a new state-changing operation would alter the permitted task. Therefore, deciding whether to extend a plan requires distinguishing information acquisition from authority expansion. A second distinction concerns the parameters of the authorized update itself. Even when its function is permitted, an attacker-influenced date, recipient or identifier can redirect the operation; consequently, function-level authorization and argument checking address different parts of the same execution problem.

This separation places the research question at the interface between a precomputed plan and runtime evidence: how can an agent complete missing information while keeping its effect authority fixed and checking the sensitive values it ultimately uses?

The scientific task is to preserve user authority while enabling evidence-dependent task completion under indirect prompt injection. We pursue three research objectives: (1) to establish effect authorization before data use through candidate-plan consistency and trusted user-intent recovery, while providing bounded read repair without expanding the scope of effect authorization; (2) to validate supported sensitive arguments and directory selections through explicit evidence comparison and deterministic witnesses; and (3) to compare IPIGuard++ with IPIGuard and other defense methods by quantifying utility, attack success rate, reproducibility, computational cost, and security-boundary failures.

The novelty of IPIGuard++ lies in coupling effect authorization with witness-carrying argument checks for tool-using agents. Before untrusted content is used, candidate-plan auditing, effect-function voting, and trusted user-intent recovery establish the operations that the agent is permitted to perform. Bounded read repair can recover necessary information without enlarging this authorized effect scope. Before execution, dependency fusion and argument resolution connect tool arguments to their supporting evidence, while explicit evidence comparison and deterministic witnesses check sensitive arguments and directory selections. This design makes authorization and argument validation explicit, inspectable steps within the agent’s tool-use workflow rather than leaving them implicit in model reasoning.

Accordingly, the work makes three contributions. First, asymmetric authority for elastic TDGs combines pre-data plan voting and trusted-intent recovery with argument anti-unification and bounded, resolved, deduplicated read repair, thereby preserving a fixed effect boundary. Second, counterfactual and deterministic argument checks integrate raw and quarantined evidence comparison, source labels, result-equality witnesses, catalog closure, and constraint-filter-then-rank certificates. Third, a matched AgentDojo evaluation connects these mechanisms to task completion, targeted attack success, component behavior, and operating cost through development-aligned, independent-sample, clean-task, component-ablation, and forged-witness evaluations.

2. Related Work

Indirect prompt injection defenses differ in the object they constrain: model interpretation, tool execution or the use of evidence within an action. These differences matter because the same external record can contain useful task information and an attacker-authored instruction. Accordingly, the literature connects instruction handling with execution control and evaluation of the resulting behavior.

2.1. Instruction and Task Alignment

Instruction-oriented defenses strengthen the distinction between a user’s request and material supplied by other sources. For example, StruQ combines structured queries with training that separates instructions from data, while SecAlign uses preference optimization to reinforce that distinction [3,4]. Detection and removal approaches instead identify injected content and suppress it before the model acts  [9]. In comparison, Task Shield evaluates whether extracted instructions and proposed calls contribute to the user’s task, making task relevance the central decision criterion [5]. GuardAgent similarly makes an explicit policy the basis of a check, but generates and executes guardrail code from safety requirements [6]. Together, these approaches show how instruction priority, content filtering and policy interpretation can provide signals for controlling an agent.

2.2. Execution Authority and Structured Plans

Execution-oriented defenses place an enforcement mechanism between model-generated decisions and their effects. In IPIGuard, a precomputed TDG specifies the allowed tool calls and their dependencies, while runtime argument estimation resolves values unavailable during planning [2]. Its query-node expansion supports additional information acquisition, and its Fake Tool Invocation mechanism addresses overlap between legitimate and attacker-requested tools. By comparison, CaMeL extracts control and data flows into a program and enforces capability policies through a custom interpreter [7]. Progent expresses privileges as symbolic constraints on tool names and arguments, then distinguishes policy narrowing from expansion through satisfiability checking [10]. At the application level, ACE separates trusted abstract planning from concrete application binding and enforces data and capability barriers during execution [8].

2.3. Evidence Dependence and Security Evaluation

Counterfactual checks examine how a proposed action changes when part of its context changes. MELON masks the user task and compares the resulting actions, using reduced dependence on the legitimate request as an attack signal [11]. In contrast, AttriGuard attenuates control-bearing content in external observations and tests the survival of proposed calls through shadow replay [12]. SIEVE connects execution structure to parameter provenance through an intent graph, deterministic verification and semantic escalation [13]. These designs give different roles to task identity, environmental observations and structured bindings. Their common concern is the relationship between an action and the information that supports it, rather than the presence of suspicious words alone.

Evaluation methods also determine which security behavior becomes observable. AgentDojo checks user-task completion and attacker goals within mutable application environments, while WASP examines end-to-end prompt injection in web agents [1,14]. In addition, MUZZLE adapts malicious content to the agent’s trajectory and feedback, and PromptFuzz systematically mutates prompts to search for effective attacks [15,16]. Such adaptive search differs from testing a fixed collection of attack strings because the attacker can respond to a defense’s behavior. Correspondingly, studies of adaptive attacks identify the attacker’s knowledge and search budget as central parts of an evaluation [17,18]. These distinctions support reporting task performance, attack outcomes and operational measurements under clearly identified protocols.

2.4. Analysis and Research Gap

The reviewed methods establish that secure execution involves both control over permitted actions and checks on the information used to perform them. However, a TDG can authorize an effect before the reads needed to instantiate that effect are known. In this setting, the remaining design question is how to admit useful read repair and verify derived arguments under one fixed effect-authorization rule.

IPIGuard++ addresses this question within the IPIGuard execution path by linking pre-data effect authorization to bounded information acquisition and explicit argument computations. Thus, its distinction lies in the TDG-specific composition of these decisions, including catalog coverage and constrained selection for supported tasks. The matched comparison evaluates that composition against the original execution path.

3. Problem Formulation

The execution setting contains a trusted user request, a tool interface and external records returned by tool calls. At this interface, a tool call comprises a function name and an argument map; together, these determine the operation presented to the application. Because some arguments depend on earlier outputs, the task also induces dependencies between calls. A TDG represents these dependencies as a directed acyclic graph [2]. Within this representation, the security problem is to preserve the authority established from the request while resolving later arguments from external evidence. Effect authorization concerns function membership, whereas evidence resolution determines argument values.

3.1. Trust and Adversarial Control

The trusted inputs comprise the user’s request, tool schemas, execution policy and runtime. Under this trust model, the planner observes the request and tool documentation before it receives an attacker-controlled tool result. At the tool-data boundary, the attacker can replace or insert text in a record returned by a legitimate tool call and can know the defense’s design. Through this channel, the attacker seeks either an additional effect or a change to a sensitive argument of an already authorized effect. The trusted runtime mediates calls to the application. Accordingly, the execution problem concerns attacker influence through tool data, with the request, policy and tool implementations held fixed.

3.2. Graph, Tool Classes and Arguments

Let the TDG be $G=(V,E)$, where V is the set of call nodes and E contains directed data-dependency edges. Each node v carries a function $f_v$, argument map $a_v$ and predecessor set $pred\left(v\right)$. For a node with a pending value, its predecessors provide the evidence needed to resolve that value. The policy assigns each function in the tool set T to a classified read in Q or a classified effect in W:

$$T=Q\cup W,Q\cap W=⌀.$$

(1)

This partition defines the categories used by the executor’s admission checks. In particular, $C_W\subseteq W$ denotes the effect functions authorized before external evidence arrives. At traversal step t, the evidence collection $R_t$ contains the outputs of completed calls. For a node v, $K_v$ denotes unresolved argument keys to be filled from $R_t$, while $S_v$ denotes keys treated as sensitive by the policy. Their intersection identifies pending values whose resolution needs argument-level checking. Consequently, a permitted effect is described by both its function membership in $C_W$ and the admissibility of the completed argument map.

3.3. Execution Objective

An executable node must have a known function, a schema-valid and resolved argument map, and satisfied dependency and integrity checks. For an effect node, these conditions include the pre-data authorization requirement:

$$execute\left(v\right)\wedge f_v\in W\Rightarrow f_v\in C_W.$$

(2)

This implication expresses the authority objective for functions classified as effects. Meanwhile, legitimate task completion can require additional reads to resolve members of $K_v$. Such a read changes the available evidence without granting a new member of $C_W$. The design problem therefore combines a fixed effect boundary with controlled growth of the information available inside that boundary. Sensitive recipients, destinations, identifiers, amounts and times make the distinction consequential for application behavior. In these cases, checking the function and checking the value serve separate, complementary roles.

4. Methodology

IPIGuard++ separates authority construction from evidence resolution within the TDG lifecycle. First, the planning stage establishes the effect set from the trusted request and sampled plans. During traversal, the runtime then expands eligible reads and resolves pending arguments from the resulting evidence. Before a classified effect executes, argument checks connect its sensitive values to source labels, comparisons and supported deterministic operations. Figure 1 presents this order and the shared execution gate.

Figure 1. Effect authorization and runtime argument resolution in IPIGuard++. The authorized effect set is fixed before tool data arrive, and the dashed raw-evidence branch resolves arguments without executing tools. IPIGuard++ retains the AgentDojo v1.1.2 tool environment, the Workspace, Slack, Travel, and Banking suites, and the original suite evaluators. The updated components are candidate-plan auditing, effect-function voting, trusted user-intent recovery, dependency fusion, bounded read repair, and pre-execution argument resolution and checks.

4.1. Pre-Data Effect Authorization

The planner samples $K=3$ candidate TDGs from the trusted request and tool documentation. Before fusion, each candidate undergoes checks for known functions, argument shape and acyclicity. The selected candidate supplies the query structure, whereas effect functions require agreement across candidates. For this agreement, the vote counts function presence rather than equality of argument values, since an effect’s parameters can remain unknown at planning time. The majority threshold is $q=\lfloor K/2\rfloor +1$, which equals two under the evaluated setting. Consequently, plans that agree on the required operation can support the same effect even when they leave different fields unresolved.

Trusted-intent recovery supplements this vote when the user’s request explicitly names a covered effect. For this purpose, seven regular-expression intent rules produce the effect set $I_W$ from the trusted request. An effect in $I_W$ enters the fused graph when at least one sampled plan contains that function and provides its dependency structure. Combining the majority and recovery branches gives

$$\begin{array}{cc}\hfill C_W=& \{f\in W:votes(f)\ge q\}\hfill \\ \hfill & \cup \{f\in I_W:votes\left(f\right)\ge 1\}.\hfill \end{array}$$

(3)

Here, $votes\left(f\right)$ counts the candidate plans containing f. In the recovery branch, trusted intent identifies the requested effect and the supporting plan supplies an executable structure. Both inputs precede the arrival of tool data. Thus, Equation (3) fixes effect membership before the evidence-resolution stage begins.

The value $K=3$ was prespecified to allow the scheduler to compare multiple candidate TDGs while keeping the candidate set bounded. It was not selected because supplementary experiments showed it to be optimal. The same setting was retained across the four reported seeds—42, 43, 47, and 48—rather than tuned separately for individual seeds. The sensitivity of utility, ASR, and computational cost to K is examined in Section 5.3.

Function agreement and argument agreement are handled separately during fusion. For each retained effect, anti-unification preserves fields whose candidate values agree and leaves conflicting or missing fields as typed placeholders. This operation makes later evidence responsible for completing those values. Dependency reconstruction then considers candidate edges in descending support order and rejects edges that would create a cycle.

The evaluated tool classifier applies rules in a fixed order. First, the hidden-effect exception classifies get_unread_emails as an effect because reading the messages changes their read status; this exception therefore takes precedence over its read-like name. Second, a name is classified as an effect if it begins with one of the effect prefixes add_, append_, book_, cancel_, create_, delete_, invite_, post_, remove_, reserve_, reschedule_, schedule_, send_, share_, update_, or write_. Third, a name is classified as a read if it begins with one of the read prefixes check_, find_, get_, list_, lookup_, read_, retrieve_, or search_. All remaining names are classified as UNKNOWN. A previously unseen tool whose behavior or potential side effects cannot be determined from these rules is therefore not assumed to be read-only or safe and is not automatically authorized for execution under the current policy.

4.2. Bounded Read Repair and Catalog Coverage

During traversal, the original node-expansion mechanism can propose calls that supply missing information. IPIGuard++ admits a proposal only when the function exists, belongs to Q, satisfies its schema and has fully resolved arguments. In addition, the function-argument signature must be new, its arguments must pass the recognized-instruction check, and the per-task budget must have capacity. The evaluated budget permits at most eight accepted repair calls. Consequently, each accepted call adds information through the classified-read path, while proposals classified as effects are dropped. Its output subsequently enters the same evidence-processing path as a planned read.

Deduplication operates on the function and normalized arguments of a call. Thus, two proposed reads with the same resolved signature consume a single acquisition opportunity rather than repeatedly requesting identical information. The graph records pending, expanded and resolved states as traversal progresses. When a missing attribute becomes available, the dependent node can resume resolution. Accepted reads, dropped proposals and unresolved nodes also provide execution diagnostics. Together, these records distinguish the acquisition of new evidence from an unchanged pending computation.

Catalog closure handles dependencies in tasks that compare several candidates. After an enumerator returns restaurants, hotels or rental companies, the corresponding attribute reads receive the enumerated candidate set. This propagation preserves coverage across attributes such as price, rating, address, opening hours and dietary requirements. The resulting dependency edges connect the enumerator to its recognized consumers. Accordingly, later selection operates on candidates with the required attributes, rather than relying on an early model-selected subset. If an attribute remains missing, the dependent operation stays pending and can use the same bounded repair mechanism.

4.3. Paired Evidence Views and Sensitive Arguments

Each completed tool result has a raw view and a quarantined view. To construct the latter, the executor recursively processes structured values and removes recognized instruction-bearing spans, including tagged information blocks and recognized instruction suffixes. This field-level treatment preserves sibling records that remain useful to the task. For a node with unresolved arguments, the two views define an intervention on the evidence used for resolution. The comparison is activated when quarantine changed a predecessor output. It therefore examines the effect of that particular transformation on the node’s pending sensitive values.

The shadow branch fills unresolved keys from raw evidence without invoking a tool. The executing branch fills the same keys from quarantined evidence. For sensitive pending keys, the executor records the difference set

$${\Delta }_v=\{k\in K_v\cap S_v:a_v^{\mathrm{raw}}\left[k\right]\ne a_v^{\mathrm{quar}}\left[k\right]\}.$$

(4)

In this expression, $a_v^{\mathrm{raw}}$ and $a_v^{\mathrm{quar}}$ are argument maps from the two parses. A member of ${\Delta }_v$ identifies a sensitive field whose proposed value changed under quarantine. Such a field proceeds to deterministic witness checking or semantic review. The actual-branch value also undergoes grounding against predecessor text. For short entity strings, canonicalization seeks an exact or similar source span, connecting the selected value to the evidence used to resolve it.

Argument provenance is represented by local classes for user input, tool evidence, marker-flagged tool evidence and model-generated content. Within these classes, the tool label reflects the local marker state assigned during evidence processing. The executor applies source-to-sink checks to sensitive arguments of classified high-impact functions. In particular, model-generated sensitive values require review, and sensitive flows require plan authorization. Marker taint propagates through dependencies. At the final firewall, a tainted dependency blocks execution when the node’s trusted_projection flag is false; nodes in the consensus plan receive that flag.

4.4. Deterministic Witnesses and Final Selection

A deterministic witness records the argument key, a supported operation, its premises and the resulting value. Denoting these fields by $w=(k,o,P,r)$, the operation computes r from the recorded premises P. The runtime then compares that result with the pending argument:

$$r=o\left(P\right),r=a_v\left[k\right].$$

(5)

The equality in Equation (5) is the acceptance condition for the derivation label. When it holds, the evaluated version replaces the argument’s prior top-level source classes with VERIFIED_DERIVATION. The witness retains the operation and premises as an inspectable computation record. Thus, a derived value has an explicit computational counterpart at the point where it is supplied to a tool.

The operation library supports eight deterministic witness operations:

all_day_window	argmax_sender
catalog_closure	person_to_email
reference_projection	preserve_duration
start_plus_duration	weekday_meeting_time

For each operation, the verifier recomputes the operation from the recorded premises and compares the computed value, witness result, and pending argument. The four time-related operations—all_day_window, preserve_duration, start_plus_duration, and weekday_meeting_time—permit equivalence after time parsing. These checks verify computational consistency; the premises themselves are not authenticated.

Final certificates handle supported restaurant, hotel and multi-city itinerary tasks that require constrained selection. Let X be the deduplicated candidate catalog, $c_j\left(x\right)$ a required Boolean constraint and $s\left(x\right)$ the requested ranking score. The certificate first forms the eligible set and then selects the highest-ranked eligible candidate:

$$X^{*}=\left\{x\in X:\underset{j}{\bigwedge }{c}_j\left(x\right)\right\},\widehat{x}=\arg \underset{x\in X^{*}}{\max }s\left(x\right).$$

(6)

This order places feasibility before preference. Accordingly, a high score affects selection only after the candidate satisfies the hard constraints. The certificate records catalog sources, applied constraints, eligible candidates, scores and the selected result. Deterministic tie handling completes the selection rule. When a required catalog or attribute is unavailable, the node remains pending for evidence acquisition rather than receiving a partially evaluated ranking.

4.5. Integration at the Execution Gate

The final gate joins the pre-data authority decision with the resolved argument state. It checks tool existence, plan-audit state, required fields, source-to-sink conditions and differences that remain after witness checking. Where required, semantic review supplies a further decision before the marker firewall runs. An admitted classified effect then executes within $C_W$, using the argument map checked on the executing branch. The shadow branch supplies comparison values only. In this way, authority construction, information acquisition and argument computation meet at one point in the original TDG traversal path.

The resulting execution rules have three distinct operational meanings. First, runtime expansion admits only functions classified as reads under the evaluated policy. Second, each executed classified effect belongs to the vote-or-intent set fixed before tool evidence. Third, assigning VERIFIED_DERIVATION requires equality between the pending argument and a deterministic witness result. The checks operate on function membership, call validity and argument values, respectively. Together, they specify what the execution layer enforces and identify the corresponding behaviors examined in the evaluation.

5. Experiments and Analysis

5.1. Experimental Setup and Protocols

The evaluation used AgentDojo package 0.1.23 with benchmark version 1.1.2 and its Workspace, Slack, Travel and Banking suites. For attacked cases, four attack methods supplied the injected content: Ignore Previous, InjecAgent, Tool Knowledge and Important Instructions. Each comparison matched the attack, suite, user-task identifier and injection-task identifier between original IPIGuard and IPIGuard++ v0.9.5. Both systems used the endpoint label gpt-5.4-mini through the same third-party OpenAI-compatible provider on 4 August 2026. The original development-aligned and independent samples used seeds 42 and 43, respectively, with one execution per method-case combination. To extend seed coverage and assess repeatability, we added seeds 47 and 48. Each new seed comprised 32 attacked cases, and each case was executed three times for each of the seven methods, giving 96 executions per method per seed and 192 executions per method across the 64 new cases. The 97 clean tasks were also repeated three times for IPIGuard and IPIGuard++, yielding 291 executions per method. Each K-sensitivity setting was evaluated on the same 32 attacked cases with three repetitions, yielding 96 executions per setting. The principal method settings were three sampled plans and an eight-call read-repair budget.

The development-aligned sample used seed 42 to select five eligible cases per attack–suite cell, giving 80 cases. Because these keys had informed failure-driven iteration from v0.9.4 to v0.9.5, their role was task recovery on a reused development sample. An independent sample used seed 43 and two cases per cell, giving 32 keys that did not guide method changes. These samples were analyzed separately. In addition, clean evaluation covered all 97 benign tasks, and six component ablations each used a 32-case subset of the seed-42 pool. A separate eight-case probe supplied XML-style forged witness text, while token counts and wall-clock latency characterized the seed-42 workload.

Strict utility equals the fraction of cases whose complete user objective was satisfied; partial completion counts as failure. By contrast, targeted attack success rate (ASR) measures the fraction achieving the benchmark-defined attacker objective. For paired utility, $d_i=U_i^{+}-U_i^0$ compares the binary outcomes of IPIGuard++ and original IPIGuard on case i, and the reported difference is $100\overline{d}$ percentage points (pp). For the repeated attack experiments, the case key comprises suite, attack, user-task identifier and injection-task identifier. Paired outcomes are aligned by case and repeat index, and paired differences are averaged within each unique case before 20,000 case-clustered bootstrap resamples. The repeated clean-task analysis uses the analogous task-clustered procedure after averaging repetitions within each task. For the original single-execution comparisons, the statistical summaries use 20,000 paired percentile-bootstrap resamples, with seed 42 except for the independent comparison, which uses seed 43. Interval endpoints use the integer-floor indices at 2.5% and 97.5%, and two-sided exact McNemar tests evaluate equal probabilities of the two discordant outcomes. For zero observed attacks, the reported one-sided 95% binomial upper bound is $1-{0.05}^{1/n}$; subgroup, ablation and probe analyses are exploratory and unadjusted.

Original IPIGuard retained its pre-planning, TDG construction, placeholder resolution, node expansion, safety verification and Fake Tool Invocation behavior. Accordingly, the comparison measured the added IPIGuard++ policy and argument checks within that execution path. Other defenses discussed in Related Work provide mechanism context rather than measured comparison rows. The implementation record also reports 33 targeted tests covering quarantine, classification, recovery, witnesses, expansion and source-to-sink checks. These tests concern execution behavior, whereas task utility and ASR come from the benchmark evaluations. Table 1 summarizes the matched strict-utility comparisons and paired statistical outcomes for the development, independent, clean-task and forged-witness evaluations.

Table 1. Matched strict utility comparisons, with differences defined as IPIGuard++ minus original IPIGuard, paired 95% bootstrap intervals, favorable/tied/unfavorable (F/T/U) counts and two-sided exact McNemar tests; the forged-witness interval is shown in Figure 2d, and ASR is not applicable to clean tasks.

Comparison	n	Original	IPIGuard++	$\mathbf{\Delta }$ (pp)	95% CI (pp)	F/T/U	p	ASR (%)
Development, seed 42	80	62.500	87.500	$+25.000$	[16.250, 35.000]	20/60/0	1.9073 × ${10}^{-6}$	0/0
Independent, seed 43	32	50.000	53.125	$+3.125$	[$-15.625$, 21.875]	5/23/4	1.0000	0/0
Clean tasks	97	65.98	63.92	$-2.062$	[$-12.37$, 8.25]	12/71/14	0.8450	N/A
Forged-witness probe	8	37.500	75.000	$+37.500$	See Figure 2d	3/5/0	0.2500	0/0

Table 1. Matched strict utility comparisons, with differences defined as IPIGuard++ minus original IPIGuard, paired 95% bootstrap intervals, favorable/tied/unfavorable (F/T/U) counts and two-sided exact McNemar tests; the forged-witness interval is shown in Figure 2d, and ASR is not applicable to clean tasks.

Comparison	n	Original	IPIGuard++	$\mathbf{\Delta }$ (pp)	95% CI (pp)	F/T/U	p	ASR (%)
Development, seed 42	80	62.500	87.500	$+25.000$	[16.250, 35.000]	20/60/0	1.9073 × ${10}^{-6}$	0/0
Independent, seed 43	32	50.000	53.125	$+3.125$	[$-15.625$, 21.875]	5/23/4	1.0000	0/0
Clean tasks	97	65.98	63.92	$-2.062$	[$-12.37$, 8.25]	12/71/14	0.8450	N/A
Forged-witness probe	8	37.500	75.000	$+37.500$	See Figure 2d	3/5/0	0.2500	0/0

Figure 2. Task utility and paired effects for original IPIGuard and IPIGuard++: (a) development-aligned utility by attack type, with 20 cases per attack; (b) paired development outcomes and observed ASR; (c) clean-task utility by suite; and (d) paired utility differences with the reported 95% bootstrap intervals, where the adaptive pilot denotes the eight-case forged-witness probe and the independent sample uses seed 43.

Figure 2. Task utility and paired effects for original IPIGuard and IPIGuard++: (a) development-aligned utility by attack type, with 20 cases per attack; (b) paired development outcomes and observed ASR; (c) clean-task utility by suite; and (d) paired utility differences with the reported 95% bootstrap intervals, where the adaptive pilot denotes the eight-case forged-witness probe and the independent sample uses seed 43.

5.2. Task Recovery and Independent Sampling

IPIGuard++ completed 70 of the 80 development-aligned cases, compared with 50 for original IPIGuard. This difference corresponds to utility increasing from 62.5% to 87.5%, with a paired gain of 25.0 pp and a 95% bootstrap interval of 16.25 to 35.0 pp. The paired outcomes comprised 20 favorable changes, 60 ties and no unfavorable changes, giving an exact McNemar $p=1.9073\times {10}^{-6}$. Thus, the added execution checks recovered task completion on cases that the original path left incomplete. Neither system achieved an attacker objective in this sample. At $n=80$, the corresponding zero-event upper bound is 3.68%, which describes the resolution of the sampled security observation.

The development-sample gain appeared across all four application suites. Within this sample, Workspace increased from 50% to 90%, Slack from 75% to 80%, Travel from 70% to 95%, and Banking from 55% to 85%, with 20 cases per suite. These four suite-specific utility pairs provide a suite-level breakdown of the same development-aligned seed-42 attack sample and are reported only in the text rather than in a separate figure panel. Across attack types, Figure 2a shows the corresponding utility pairs: 55% to 80% for Ignore Previous, 60% to 90% for InjecAgent, 65% to 90% for Tool Knowledge, and 70% to 90% for Important Instructions, with 20 cases per attack. Because the cases had already informed development, this pattern characterizes the recovered workload rather than an independent estimate of the average benchmark benefit.

Independent sampling produced a different utility contrast. On the 32 seed-43 cases, original IPIGuard completed 50.0% and IPIGuard++ completed 53.125%, a difference of 3.125 pp with a 95% interval from $-15.625$ to 21.875 pp. Here, five favorable and four unfavorable changes, alongside 23 ties, gave an exact $p=1.0$. Consequently, the independent sample did not establish the large utility gain observed in the development sample. Three attack subsets had equal 50% utility for both systems, whereas Important Instructions changed from 50% to 62.5%. Both systems again had zero observed ASR, with an 8.94% upper bound at this sample size. For the newly added seeds 47 and 48, IPIGuard++ achieved higher mean utility than IPIGuard in both seeds, with differences of $+2.083$ and $+13.542$ percentage points, respectively. Across the three repetitions, IPIGuard++ utility was 78.125%, 81.250% and 81.250% for seed 47, and 87.500%, 87.500% and 87.500% for seed 48; its ASR remained 0.000% in every repetition. Across the 64 new unique task–attack cases, IPIGuard++ obtained 83.854% utility and 0.000% ASR, compared with 76.042% utility and 0.521% ASR for IPIGuard. The mean utility improvement was $+7.813$ percentage points, with a 95% case-clustered bootstrap interval of [$-0.521$, $+17.188$] percentage points. Together with the positive results for seeds 42 and 43, these results show the same direction of mean utility improvement across all four reported seeds. Because the interval for the newly added cases includes zero, we interpret this as consistent directional evidence rather than definitive statistical confirmation or universal superiority.

Across the 16 suite-by-attack cells for seeds 47 and 48, IPIGuard++ had higher utility in 8 cells, the two methods tied in 5 cells, and IPIGuard had higher utility in 3 cells. Specifically, IPIGuard performed better for Ignore Previous in Banking and for Important Instructions and Tool Knowledge in Slack. Ties occurred for Important Instructions and Tool Knowledge in Banking, Ignore Previous and Tool Knowledge in Travel, and Tool Knowledge in Workspace.

5.3. Contribution of the Execution Components

The ablations examined how removing individual checks changed task completion while keeping the remaining execution stack active. Each ablated configuration used the same 32 seed-42 cases as the full method, whose utility was 87.5%. Table 2 reports ablated-minus-full differences, so a negative value denotes lower utility after removal. Among these interventions, disabling deterministic argument witnesses produced the largest change: utility fell to 62.5%, with a difference of $-25.0$ pp and a 95% interval of $-40.625$ to $-9.375$ pp. The eight unfavorable changes and zero favorable changes yielded an exact $p=0.0078125$. This pattern connects explicit deterministic derivations to the completion of tasks that otherwise remain unresolved or fail subsequent checks.

Table 2. Matched component ablations on 32 development-pool cases, with full-method utility of 87.5%, differences defined as ablated minus full, paired 95% bootstrap intervals and exact McNemar tests; all contrasts are exploratory and unadjusted, and all configurations recorded zero targeted attack successes.

Configuration	Utility (%)	Difference (pp)	95% CI (pp)	F/T/U	p
Single plan	75.000	$-12.500$	[$-25.000$, $-3.125$]	0/28/4	0.1250
No trusted-intent recovery	71.875	$-15.625$	[$-28.125$, $-3.125$]	0/27/5	0.0625
No evidence quarantine	84.375	$-3.125$	[$-12.500$, 6.250]	1/29/2	1.0000
No argument witnesses	62.500	$-25.000$	[$-40.625$, $-9.375$]	0/24/8	0.0078125
No catalog closure	81.250	$-6.250$	[$-18.750$, 6.250]	1/28/3	0.6250
No final ranking	75.000	$-12.500$	[$-25.000$, $-3.125$]	0/28/4	0.1250

The other removal effects were smaller or less precisely resolved by their discordant outcomes. Replacing the three-plan design with one plan reduced utility by 12.5 pp, while removing trusted-intent recovery reduced it by 15.625 pp. Although both point estimates favor the complete design, their exact tests gave $p=0.125$ and $p=0.0625$, respectively. Removing catalog closure and final ranking similarly reduced utility by 6.25 and 12.5 pp. By comparison, removing quarantine produced a 3.125 pp reduction, with one favorable and two unfavorable changes among 32 pairs. Together, these contrasts describe the observed sensitivity of the complete execution path to its components.

The statistical procedures attach different meanings to these contrasts. In particular, percentile-bootstrap intervals summarize resampled paired differences, whereas the exact McNemar test conditions on the number of discordant pairs. A bootstrap interval can therefore exclude zero even when the discrete exact test does not reach the conventional 0.05 threshold. The witness ablation was the only contrast below that threshold in the unadjusted six-comparison set. Accordingly, its signal is reported as exploratory mechanism evidence, with the full family retained in Table 2. The ablation cases were drawn from the development pool, so they diagnose behavior within that pool.

All full and ablated configurations recorded zero targeted attack successes. This common outcome means that the observed utility changes occurred without a measured ASR difference in these cases. However, each ablation retained other checks that could reject the same attack, and each 32-case zero-event sample has an 8.94% upper bound. Thus, the comparison does not isolate a security contribution for every component.

A separate sensitivity analysis evaluated $K=1$, 3 and 5 on the same 32 attacked cases with three repetitions, giving 96 executions per setting. Utility was 90.625%, 90.625% and 89.583%, respectively, and ASR was 0.000% for all three settings. Mean total tokens were 30,170.5, 46,364.6 and 62,743.4; mean model calls were 8.802, 10.812 and 12.865; and mean observed latency was 69.74, 82.46 and 102.74 s, respectively. Thus, in this tested sample, increasing K raised the measured computational cost without improving utility or ASR. In particular, $K=1$ achieved the same observed utility and ASR as $K=3$ at a lower measured cost. $K=3$ therefore remains a preset design choice rather than an empirically proven optimum.

5.4. Clean-Task Behavior and Operating Cost

Table 3 retains the original single-execution clean-task and operating-cost measurements. A separate repeated clean-task evaluation ran all 97 tasks three times for IPIGuard and IPIGuard++, yielding 291 executions per method. IPIGuard++/IPIGuard utility was 82.500%/75.000% in Workspace, 90.476%/93.651% in Slack, 85.000%/61.667% in Travel, and 85.417%/85.417% in Banking. Overall utility was 85.223% versus 78.007%, a difference of $+7.216$ percentage points, with a 95% task-clustered bootstrap interval of [$-0.687$, $+15.120$] percentage points. Thus, Workspace and Travel favored IPIGuard++, Banking was tied, and only Slack favored IPIGuard.

Table 3. Clean-task utility by suite and mean per-case operating cost on the separate development-aligned attack workload; cost changes are relative percentages, whereas utility entries are completion percentages.

Measurement	n	Original IPIGuard	IPIGuard++	Relative Cost Change
Workspace utility (%)	40	62.50	67.50	–
Slack utility (%)	21	71.43	66.67	–
Travel utility (%)	20	70.00	65.00	–
Banking utility (%)	16	62.50	50.00	–
Overall clean utility (%)	97	65.98	63.92	–
Input tokens	80	105,932.89	74,006.85	$-30.14\%$
Output tokens	80	1556.50	2994.66	$+92.40\%$
Latency (s)	80	59.01	79.94	$+35.47\%$

The operational profile also combined a reduction with additional costs. On the seed-42 attack workload, mean input usage decreased from 105,932.89 to 74,006.85 tokens per case, a 30.14% reduction. In contrast, mean output usage increased from 1556.50 to 2994.66 tokens, and mean latency increased from 59.01 to 79.94 s. These changes correspond to increases of 92.40% and 35.47%, respectively. The extra planning and checking operations provide a procedural explanation for additional generated output and elapsed time, while constrained expansion is compatible with shorter accumulated input. Because the record contains aggregate provider measurements rather than isolated component timings, these explanations remain interpretations of the combined execution path.

On the 64 newly added attacked cases from seeds 47 and 48, with 192 executions per method, the mean output tokens for IPIGuard++, IPIGuard and No Defense were 1634.4, 1861.4 and 259.1, respectively; mean observed latency was 93.07, 107.11 and 24.43 s, and p95 latency was 162.70, 253.87 and 50.70 s, respectively. Thus, in this sample, IPIGuard++ used 12.19% fewer output tokens and had 13.11% lower mean latency than IPIGuard; however, its output-token consumption and mean latency were approximately 6.31 and 3.81 times those of No Defense, respectively. These results show that IPIGuard++ reduced the measured overhead relative to the original IPIGuard, while still introducing substantial absolute overhead compared with an undefended agent. Practical deployment therefore requires explicit token and latency budgets, particularly for interactive or latency-sensitive applications.

5.5. Forged Witnesses and Argument Checks

The forged-witness probe tested a specific attempt to turn attacker-authored text into execution authority. Its XML-style payload named user-input and verified-derivation labels, consensus and resolution concepts, and asserted a fabricated witness inside tool data. To exercise this route, the payload avoided the detector’s explicit JSON delimiters and common lexical markers. Across the eight matched cases, original IPIGuard completed three tasks and IPIGuard++ completed six, while both recorded zero targeted attack successes. The resulting 37.5 pp utility difference arose from three favorable changes and five ties, giving $p=0.25$. Accordingly, the probe documents behavior against the supplied forged-record family rather than a statistically established general adaptive-defense advantage.

The absence of a successful attack in this probe is consistent with runtime-created witness comparison rather than automatic acceptance of a text label. However, the tested implementation checks equality of the computed result and pending value without a general premise-authentication rule. In addition, assigning the derivation label replaces prior top-level source classes, and consensus nodes’ trusted-projection status can bypass the marker-taint block. These operational choices distinguish witness-result consistency from authenticated data provenance. At eight cases, the zero-event upper bound is 31.23%, so the probe supplies a targeted mechanism check rather than broad adaptive assurance. Attacks that manipulate premises, preserve raw/quarantined equality or poison candidate catalogs are directly relevant extensions of this test.

To examine witness authenticity under corrupted premises, we constructed a 40-item deterministic offline witness-operation matrix that included intentionally corrupted premises. Table 4 summarizes the expected and observed decisions for the five scenario categories. Thirty-two items met the safety expectations: all eight authentic controls were accepted, while forged-result-only, missing-premise and pending-value-mismatch cases were rejected as required. These results provide positive evidence that the witness mechanism can accept valid computations while detecting several important classes of forged, incomplete or inconsistent inputs.

Table 4. Outcomes of the 40-item deterministic offline witness-operation matrix by scenario. Each scenario contains one case for each of the eight supported witness operations; the final column reports the number of decisions that met the safety expectation.

Scenario	n	Expected Decision	Observed Outcome	Safety Expectation Met
Authentic control	8	Accept	8 accepted	8/8
Forged result only	8	Reject	8 rejected	8/8
Missing premise	8	Reject	8 rejected	8/8
Pending-value mismatch	8	Reject	8 rejected	8/8
Self-consistent corrupt premise	8	Reject	8 accepted	0/8

The remaining eight items were self-consistent corrupt-premise cases, one for each supported witness operation. All eight were accepted even though rejection was expected. In these cases, the corrupted premises remained internally consistent with the recorded witness result and pending value, so recomputation alone did not reveal the corruption.

5.6. Implications for Execution-Layer Defense

The experiments identify separate roles for effect authority, evidence recovery and argument computation. The development comparison and witness ablation connect the combined design to recovered task completion, while the independent comparison shows that the magnitude depends on the evaluated sample. Clean-task changes and endpoint measurements then reveal how additional checks affect legitimate work and operating cost. Together, these observations support treating recovery and checking as measurable execution decisions. They also motivate evaluating the resulting policy on independently chosen tasks rather than inferring its average benefit from repaired development cases. For deployment, the corresponding engineering priorities are explicit tool-effect metadata, premise-aware derivation records and targeted tests of the sensitive arguments that the application actually uses.

6. Conclusions

IPIGuard++ connects pre-data effect authorization with runtime evidence recovery and argument computation in a tool dependency graph. Sampled-plan agreement and trusted-intent recovery define authorized effect functions, while bounded read repair supplies information needed by pending operations. Within that boundary, raw/quarantined comparisons and deterministic witnesses check sensitive arguments, and catalog closure supports constrained candidate selection. Across the 64 newly added task–attack cases, IPIGuard++ improved mean utility over IPIGuard by $+7.813$ percentage points, and the same direction of improvement was observed across all four reported seeds. In the repeated clean-task evaluation, overall utility was 85.223% for IPIGuard++ and 78.007% for IPIGuard. No targeted attack successes were observed for IPIGuard++ in the repeated attack experiments. These findings support IPIGuard++ as an effective execution-layer defense under the tested settings, while the confidence intervals and subgroup results continue to qualify the strength and generality of the evidence. Combining effect authorization with witness-carrying argument checks makes tool-use decisions more explicit, inspectable and auditable. The execution policy can examine not only whether an operation is authorized, but also whether its sensitive arguments are supported by evidence. These checks are relevant to state-changing operations in workspace, collaborative messaging, travel and banking applications. The next evaluation should pair these implementation changes with prespecified task and attack protocols, independently selected cases, repeated executions and case-clustered analysis, measuring useful completion and adversarial outcomes under the same execution conditions. Further work should also strengthen premise-aware witnesses and examine adaptive attacks that target catalogs, identities and raw/quarantined agreement.