PaperlayerView exact revision on arXiv

Source-linked AI summary

PolicyGuard: A Dialogue-Grounded Sub-Agent Verifier for Policy Adherence in LLM Agents

Seongjae Kang, Taehyung Yu, Sung Ju Hwang

arXiv:2606.29225v1cs.AIcs.CL

TL;DR

Policy adherence in LLM agents is a dialogue-grounded, procedural problem that single-argument safeguards do not fully capture. POLICYGUARD verifies mutating calls using the full conversation and policy context, improving PASS4 across all three evaluated frontier agents by +12.0 / +6.0 / +12.0 pp.

  • Problem

    Company-policy adherence requires verifying dialogue-dependent procedures, such as prerequisites, offers, and confirmations, rather than checking isolated argument values.

  • Method

    POLICYGUARD is a verifier subagent that evaluates mutating calls using the full dialogue, raw policy, and per-tool checklist, then provides conversation-specific remediation.

  • Results

    +12.0 / +6.0 / +12.0 pp PASS4 improvement across GPT-5.4, Claude Sonnet 4.6, and Gemini 2.5 Pro, respectively.

  • Takeaways & Limitations

    POLICYGUARD lifts PASS4 on every evaluated frontier agent while achieving higher policy-violation recall at roughly half the block rate of argument-level guards.

  • Takeaways & Limitations

    POLICYGUARD provides empirical rather than provable policy-violation recall, leaving domains requiring formal guarantees outside its scope.

Abstract

from arXiv · show

LLM agents handle user requests on behalf of organizations through tool calls and must follow the company policies stated in their system prompts. Prior work approaches this as a safeguarding problem -- external checks that block non-compliant agent actions. We argue that policy adherence is a broader problem: real workflows unfold across many turns, require explicit user confirmation and prerequisite reads, and hinge on the content of the dialogue rather than on any single argument value. Meeting this bar requires (i) full conversation context, (ii) self-reasoning over the policy and the current dialogue, and (iii) conversation-specific remediation that guides the agent's next turn -- three capabilities that prior safeguard work has often underestimated. We introduce POLICYGUARD, a sub-agent verifier that shares the agent's view of the dialogue, reasons over the policy in context, and provides actionable feedback for the agent's next turn. On tau^2-BENCH airline across three vendors (GPT-5.4, Claude Sonnet 4.6, Gemini 2.5 Pro) with four trials per setting, POLICYGUARD improves PASS4 by +12.0 / +6.0 / +12.0 pp. Per-call analyses show POLICYGUARD achieves higher policy-violation recall while blocking roughly half as often as argument-level guards.

1 Introduction

Company-policy adherence is a procedural, dialogue-grounded problem that existing argument-level safeguards do not fully capture. POLICYGUARD addresses it with a verifier subagent that reasons over the full conversation and policy, improving reliability across vendors while reducing unnecessary blocking.

  • Introduction: Company policies require agents to verify, offer, and confirm multi-step preconditions before customer-facing mutations, but prompt-level instructions remain insufficient.These requirements govern actions such as bookings, order changes, and payment requests.
  • Introduction: About 46% for GPT-5.4 and about 72% for Claude Sonnet 4.6 on τ 2-BENCH-airline show errors on both refusal-required and mutation-required tasks.The tasks require either blocking an out-of-policy request or executing only after procedural prerequisites.
  • Introduction: Company-policy failures are procedural dialogue propositions, such as confirming bookings, offering insurance, and verifying identity, rather than merely unsafe content or tool-argument violations.Existing argument- and structure-level enforcement covers only its representational scope.
  • Introduction: POLICYGUARD places a verifier subagent in the tool-calling loop to read the full conversation and evaluate mutating calls against raw policy text plus an LLM-generated per-tool checklist.Its feedback identifies missing prerequisites or the next action for the agent’s next turn.
  • Introduction: +12.0 / +6.0 / +12.0 pp lifts PASS4 for GPT-5.4 / Sonnet 4.6 / Gemini 2.5 Pro, with no regression on either policy axis; the smaller agent gains +16 pp.These are the reported paired-verifier improvements on τ 2-BENCH-airline at n=4.
  • Introduction: Roughly half the block rate of argument-level guards accompanies higher policy-violation recall, fewer remediation turns, and lower near-miss rates across every vendor.The per-call analysis attributes the PASS4 improvement to this combination of recall and blocking behavior.

2 Related Work

Prior work on policy adherence and LLM-agent safeguards addresses company-policy enforcement through varied mechanisms, but no prior system combines conversation awareness, policy self-reasoning, and behavior-driving remediation. POLICYGUARD extends the LLM-as-judge paradigm to policy- and conversation-conditioned per-tool-call verification.

  • Policy adherence in agentic workflows: No prior system combines conversation awareness, self-reasoning over policy, and behavior-driving remediation.Table 1 maps nine representative systems across these three capabilities and reports their mechanisms and context scopes.
  • Direct policy enforcement: TOOLGUARD is the closest baseline, but its auto-generated Python guards expose no chat_history, making process-level checks structurally impossible.It uses the same benchmark, mutating tools, and public code as POLICYGUARD.
  • Direct policy enforcement: NEAR-MISS detects latent prerequisite skipping after a trajectory finishes, whereas direct enforcement gates mutations before execution.POLICYGUARD reuses NEAR-MISS’s definition while computing the rate per executed mutating call.
  • LLM safeguards: POLICYGUARD belongs to the LLM-as-judge family but generalizes fixed safety taxonomies to policy- and conversation-conditioned per-tool-call verification.General LLM-agent safeguards target safety broadly rather than company-policy adherence.

3 Method

POLICYGUARD inserts an LLM Verifier between the agent and environment for mutating calls, using full dialogue and policy-derived per-tool checklists to pass or block actions with remediation. Its protocol distinguishes data-verification from procedural requirements, compares policy-input regimes, and pairs verifier and agent models to isolate method effects.

  • Verifier architecture: POLICYGUARD intercepts mutating tool calls, evaluates full conversation context against raw policy and a synthesized per-tool checklist, then passes or blocks with targeted remediation.The remediation identifies a missing prerequisite or the next question for the agent to ask; read-only calls bypass verification.
  • Verifier architecture: The verifier emits per-requirement MET / NOT MET judgments followed by PASS or BLOCK and a conversation-grounded 1–3-sentence agent message.It receives the pending action, policy specification, and the same formatted message history available to the agent.
  • Experimental protocol: The paired protocol matches verifier and agent vendor and tier, isolating method contribution from LLM substrate strength while enabling a cheaper-verifier ablation.The small-verifier ablation holds the agent fixed and swaps the verifier to a cheaper tier.
  • Policy representation: Generated tool requirements distinguish data-verification from procedural checks, with airline requirements mostly procedural and therefore beyond argument-only verification.Data-verification cites a required read-only tool, whereas procedural requirements cite conversational predicates such as explicit confirmation after a full summary.
  • Experimental regimes: The study compares PG-RAW, PG-CHECKLIST, PG-RAW-TRAJ, and PG-CHECKLIST-ONLY by varying checklist, dialogue, and raw-policy inputs, including advisory-versus-strict verdict conditions.PG-CHECKLIST is the headline configuration; the ablations remove one verifier-input stream to test their causal roles.

4 Experiments

Across airline experiments, PG-CHECKLIST is the only configuration that improves PASS4 for all vendors while achieving perfect policy-violation refusal. Ablations show dialogue grounding is essential, raw policy text adds recovery, and the verifier transfers to weaker agents despite modest downgrade costs.

  • Experimental setup: The evaluation uses 24 policy-violating and 26 mutating airline tasks across GPT 5.4, Claude Sonnet 4.6, and Gemini 2.5 Pro, with n=4 trials per cell.Configurations are Baseline4, TOOLGUARD, and PG-CHECKLIST; PASS4 is the headline metric.
  • Main results: PG-CHECKLIST is the only variant that lifts every vendor on PASS4 and reaches perfect PV refusal at 24/24 for every agent.TOOLGUARD improves GPT 5.4 but regresses Sonnet 4.6 and Gemini 2.5 Pro, with Mut PASS4 capped at 5/26 on GPT 5.4 and Sonnet 4.6.
  • Main results: PG-CHECKLIST improves PASS1 on GPT 5.4 and Sonnet 4.6 by +7.0 and +3.0 pp and is flat on Gemini 2.5 Pro.Its gains combine within-trial remediation with cross-trial consistency, whereas TOOLGUARD reduces PASS1 by −6.5 / −23.0 / −19.0 pp.
  • Ablations: Across all 104 Mut simulations, removing dialogue causes zero mutations to pass, while PG-RAW’s mutation advantage over PG-RAW-TRAJ is +26.0 pp PASS1.The verifier blocks everything without dialogue and cannot distinguish legitimate from violating mutations.
  • Ablations: Adding raw policy text to the checklist lifts Mut PASS1 by +15.4 pp, reduces block rate by −16 pp, and leaves PV recall at the ceiling.Dialogue grounding is necessary, while policy text is augmenting.
  • Deployment stress tests: On a GPT 5.4-mini agent, PG-CHECKLIST lifts PASS4 by +16.0 pp over Baseline, while a GPT 5.4-mini verifier costs −6 pp PASS4 at approximately 13% lower per-trial cost.The mini verifier still yields a +6 pp PASS4 lift on the full GPT 5.4 agent and matches TOOLGUARD’s PASS4 while retaining higher PV recall, 0.917 versus 0.875.

5 Analysis

POLICYGUARD is more selective than TOOLGUARD, improves remediation efficiency and executed-call compliance, and retains strong performance under adversarial probes. Its advantage comes from dialogue-grounded feedback that identifies missing prerequisites rather than issuing static errors.

  • Per-call verdicts: PG-CHECKLIST dominates PV recall while blocking less often than TOOLGUARD on every vendor, making it more selective.The analysis uses verdict-view confusion matrices and jointly interprets lower blocking with policy-violation recall.
  • Trajectory cost: 1.5–2.3×: TOOLGUARD inflates Mut trajectories at this rate relative to PG-CHECKLIST on every agent.Both substrates charge each block as one assistant turn; TOOLGUARD’s static error produces retries, while PG-CHECKLIST typically resolves the missing prerequisite in one corrective turn.
  • Trajectory cost: 7–10 extra read-only calls per Mut simulation: TOOLGUARD’s guard body incurs this hidden environment cost, whereas POLICYGUARD contributes zero.This cost is not reflected in trajectory metrics.
  • Executed-call compliance: 8.5×: PG-CHECKLIST improves Call-NMR over TOOLGUARD on Sonnet 4.6, reaching 4.2% versus 35.5%.PG-CHECKLIST remains below baseline and TOOLGUARD on every agent, while TOOLGUARD worsens compliance quality relative to baseline on every vendor.
  • Adversarial probes: 24/24 →21–23/24: PG-CHECKLIST’s PV recall degrades modestly under three attacks while preserving a +12.5 to +25 pp PASS4 advantage over baseline on every probe.The verifier’s rule to trust only tool-confirmed values defends authority claims and false preconditions, but indirect prompt injection exposes a tool-response metadata gap.

6 Conclusion · A Verifier prompt and YAML schema

POLICYGUARD verifies mutating tool calls using full dialogue context, policy documents, and per-tool checklists, improving policy adherence while providing conversation-specific remediation. The paper also documents its evaluation scope, operational limitations, probabilistic guarantees, privacy implications, and verifier prompt/schema variants.

  • 6 Conclusion: POLICYGUARD reads the full agent–user dialogue and evaluates mutating tool calls against policy text plus an LLM-generated per-tool checklist.When blocking, it returns conversation-specific remediation for the agent’s next turn.
  • 6 Conclusion: POLICYGUARD improves PASS4 for all three evaluated frontier-model agents and reaches perfect policy-violation recall on every agent.The evaluation uses a paired-verifier protocol on τ 2-BENCH airline.
  • Limitations: 50 tasks define the evaluation scope: τ 2-BENCH airline is selected because its policies combine written requirements with multi-turn prerequisites for mutating actions.Other customer-service and web-agent suites lack this written-policy, multi-turn compliance surface.
  • Limitations: Risk-awareness benchmarks are complementary rather than direct hosts for POLICYGUARD because they use different threat models or action-observable and single-turn predicates.The cited alternatives target demographic access control, adversarial action injection, or prompt injection rather than dialogue speech acts.
  • Limitations: GPT-5.4 generates one per-tool checklist reused across all three agents, while Gemini 2.5 Pro reads it more literally and incurs a measurable Mut PASS4 cost.The fixed checklist substrate isolates agent-plus-verifier differences; per-agent regeneration is suggested as a possible remedy.
  • Limitations: POLICYGUARD gates only mutating tool calls before execution, leaving read-only calls and verbal commitments ungated unless triggering is broadened at additional verifier-call cost.Per-cell cost figures and a verifier-cost knob are provided in Appendix M and §4.5.
  • Limitations: 24/24 PV recall is empirical rather than provable, so formal-guarantee domains remain out of scope and may require a deterministic monitor for formally expressible requirements.POLICYGUARD is also not designed against adversarial users or indirect prompt-injection attacks targeting the verifier.
  • Ethics Statement: The verifier shares user-supplied content with the agent, requiring existing privacy and PII handling to extend to verifier processing and logs in synthetic τ 2-BENCH experiments.No real customer data is used.

B Policy classification of τ 2-BENCH airline … E Verdict and runtime counting conventions

The paper distinguishes argument-level checks from dialogue- or read-dependent process requirements, then operationalizes verification through a generated checklist and patched orchestration. It also separates verifier-decision counts from executed-runtime counts to avoid conflating policy violations with agent behavior.

  • B Policy classification of τ 2-BENCH airline: 43 atomic requirements were hand-extracted from the 167-line airline policy, excluding commentary and API meta-rules and preserving the source’s section-based organization.The catalog partitions requirements into Global and per-tool scopes.
  • B Policy classification of τ 2-BENCH airline: ∼two-thirds of τ 2-BENCH airline policy requirements are process-level and therefore structurally outside argument-only verifier scope.Process-level requirements require dialogue, prior read-only tool results, or both; the figure reports the proportion conservatively.
  • B Policy classification of τ 2-BENCH airline: Blended requirements are conservatively labeled process-level when argument formulas depend on dialogue confirmation or prior-read prerequisites.Examples include baggage non-removal and compensation amounts gated by confirming the facts.
  • C Checklist generation pipeline: The four-step checklist pipeline classifies tools, generates per-tool YAML and general rules, then uses a reviewer LLM to catch roughly 5–10% of omissions or over-specifications.The reviewer checks generated YAML against the source policy; the inference-time verifier instead uses raw policy text authoritatively.
  • C Checklist generation pipeline: The airline checklist is generated once with GPT 5.4 and reused unchanged across three agent vendors, making it a fixed substrate for cross-vendor comparisons.This design attributes cross-vendor differences to the verifier and agent rather than checklist regeneration.
  • D Orchestrator patch: On a blocked mutating call, the orchestrator patch removes the assistant message, avoids the environment, and routes a remediation-bearing error ToolMessage back to the agent.The error is visible in state.messages but is not appended to the trajectory, restoring an Agent →Verifier →Agent transition.
  • E Verdict and runtime counting conventions: POLICYGUARD blocks disappear from the trajectory, while TOOLGUARD blocks remain as tool-result rows beginning with POLICY VIOLATION:.This representation asymmetry motivates keeping verdict and runtime accounting distinct.
  • E Verdict and runtime counting conventions: The verdict view counts every mutating call attempt, whereas the runtime view counts only executed mutating calls and reports verifier interventions separately as Blk%.These views answer different questions: verifier decisions on attempts versus actions the agent actually executed.

F PASSk breakdown · G Per-trial variance

PG-CHECKLIST’s PASS4 gains arise through different mechanisms across agents: within-trial recovery for GPT 5.4 and Sonnet 4.6, versus cross-trial consistency for Gemini 2.5 Pro. Its per-trial variability is lowest or tied-lowest across all agents.

  • F PASSk breakdown: Table 13 decomposes the cross-vendor main results’ PASSk behavior, with Pk/P1 defined as the consistency ratio.This ratio frames PASS4 relative to per-trial PASS1 across the three agents.
  • F PASSk breakdown: On GPT 5.4 and Sonnet 4.6, PG-CHECKLIST lifts PASS1 by +7.0 and +3.0 pp over baseline, respectively.The corresponding PASS4 gains reflect remediation helping the agent recover within the same blocked trial.
  • F PASSk breakdown: On Gemini 2.5 Pro, PG-CHECKLIST changes PASS1 by −0.5 pp while PASS4 still rises +12.0 pp.The passage attributes this pattern to increased cross-trial consistency rather than per-trial gain.
  • G Per-trial variance: PASS1 is pooled over 50 tasks per independent trial, with std computed across four trials.This defines the per-trial variance analysis for every cross-vendor main-results cell.
  • G Per-trial variance: PG-CHECKLIST’s per-trial std is lowest or tied-lowest for every agent: 0.017 / 0.009 / 0.026.These values reflect the cross-trial consistency mechanism discussed in §4.2.
  • G Per-trial variance: TOOLGUARD also concentrates tightly, with std ≤0.022 everywhere, but has a lower per-trial PASS1 mean.Thus, tight concentration alone does not imply the same per-trial PASS1 performance.
  • G Per-trial variance: The on-vendor std bounds provide the natural noise floor for interpreting cross-vendor effect sizes in §H.The comparison uses per-trial variability to contextualize observed cross-vendor differences.

H Statistical significance

Statistical tests establish that PG-CHECKLIST’s pooled PASS4 gains over both baselines are significant, while dialogue-causal ablation shows a significant Mut PASS1 collapse without trajectory context. Per-call results also show higher PV recall for PG-CHECKLIST than TOOLGUARD, with vendor-specific denominators and intervals.

  • Pooled significance: PG-CHECKLIST clears pooled overall PASS4 against both baselines at p ≤ 0.003, while PV clears at p ≤ 0.005.The pooled tests use stratified McNemar testing across the three agents and serve as the across-vendor anchor.
  • Pooled significance: Mut versus Baseline is not pooled-significant (p=0.564), whereas Mut versus TOOLGUARD is significant (p=0.005).The latter result reflects TOOLGUARD’s over-blocking rather than a clear PG-CHECKLIST Mut improvement.
  • Dialogue-causal ablation: Mut PASS1 collapses from 0.260 to 0.000 across 104 trials when trajectory context is removed, with Wilcoxon p=0.001.The corresponding Mut PASS4 McNemar test is under-powered because only two Mut tasks pass all four trials under PG-RAW.
  • Per-call PV recall: 14/14, 3/4, and 18/19 PV calls are recalled by PG-CHECKLIST for GPT-5.4, Sonnet 4.6, and Gemini 2.5 Pro, respectively.The reported Wilson 95% CIs are [0.79, 1.00], [0.30, 0.95], and [0.75, 0.99].
  • Per-call PV recall: Gemini 2.5 Pro shows the cleanest PG-CHECKLIST-versus-TOOLGUARD recall separation, 0.95 versus 0.31; Sonnet 4.6 has a small denominator because it refuses upstream.TOOLGUARD recalls 12/15, 2/3, and 5/16 calls for GPT-5.4, Sonnet 4.6, and Gemini 2.5 Pro, respectively.

I Full confusion matrix and runtime statistics · J Hidden read-only calls inside TOOLGUARD guards

The full confusion-matrix and runtime analyses show CHECKLIST achieves the strongest per-call detection while blocking fewer attempts, whereas TOOLGUARD creates more retry-driven turns. TOOLGUARD also performs hidden read-only environment calls within sequential policy-rule checks.

  • I Full confusion matrix and runtime statistics: CHECKLIST reaches the highest TP and lowest FN for every agent while blocking fewer total attempts than TOOLGUARD.This extends the main-text pattern with FP and TN counts in the full confusion matrix.
  • I Full confusion matrix and runtime statistics: The agent+user-turn count includes only assistant and user rows, excluding tool-result payload size and tool-call invocation noise.This definition underlies the Table 8 runtime view and avoids conflating verifier-independent environment payloads with conversation turns.
  • I Full confusion matrix and runtime statistics: TOOLGUARD inflates MutMsg/s by +19–28% over baseline, while PG-CHECKLIST increases it by only +3–13%.Guard-block retries trigger more turns for TOOLGUARD; PG-CHECKLIST’s remediation channel resolves blocks in 1–2 exchanges.
  • I Full confusion matrix and runtime statistics: TOOLGUARD’s Att > Exec gap reflects blocked attempts recorded in trajectories, while baseline’s smaller gap reflects environment-side errors.POLICYGUARD’s orchestrator removes blocked attempts from Att, so Att counts executed survivors; verdict-view rates provide the like-for-like comparison.
  • I Full confusion matrix and runtime statistics: POLICYGUARD blocks roughly half as often as TOOLGUARD in the verdict view.The orchestrator patch changes runtime attempt accounting, making verdict-view block rates the like-for-like reading.
  • J Hidden read-only calls inside TOOLGUARD guards: Each TOOLGUARD guard sequentially executes one subguard per policy rule and short-circuits the chain when a check fails.A failing subguard raises PolicyViolationException, ending further subguard execution.
  • J Hidden read-only calls inside TOOLGUARD guards: TOOLGUARD subguards issue hidden read-only calls such as get_user_details and get_reservation_details, which reach the environment but never enter the trajectory.A pass executes every subguard, whereas a block executes only a prefix ending at the failing subguard.
  • J Hidden read-only calls inside TOOLGUARD guards: Table 19 estimates hidden read-only calls per Mut sim under TOOLGUARD across first-subguard, midpoint, and full-chain block assumptions.The table reports pass/s and blk/s for passed and blocked mutating-tool attempts, plus RO lo / mid / hi estimates.

K Cross-domain audit (retail and telecom) · L Reproduction · M Measured cost

The cross-domain audit shows that POLICYGUARD’s benefit depends on workflow structure and where compliance risk appears, while the paper also provides reproduction artifacts and reports measured verifier costs. Retail is dominated by legitimate mutations, telecom offers few agent-side mutating calls, and headline costs vary across vendors.

  • K Cross-domain audit (retail and telecom): The cross-domain audit used GPT 5.4 as both agent and verifier with n=4 across retail and telecom base and test splits.The authors caution that each domain’s task-pool structure shapes what the results can show about a process-level verifier.
  • K Cross-domain audit (retail and telecom): Retail has only 7/114 base and 4/40 test policy-violating tasks, leaving little PV headroom for process-level improvement.Baseline already passes nearly all retail PV tasks, and the PV column is invariant across variants on base and saturates at 4/4 for POLICYGUARD variants on test.
  • K Cross-domain audit (retail and telecom): 0.579 → 0.327: PG-CHECKLIST regresses on retail Mut in the base split by literally applying an airline-default checklist.Retail’s task pool is approximately 94% mutation-required, so false-blocks on legitimate mutations are especially costly.
  • K Cross-domain audit (retail and telecom): Telecom PASS4 remains flat under PG-CHECKLIST: 0.193 → 0.202 on base and 0.300 → 0.300 on test.Telecom is primarily conversational troubleshooting; most device-side tools are unavailable to the agent, narrowing the mutating-call surface for the pre-execution gate.
  • L Reproduction: The authors will release the verifier, checklist-generation pipeline, prompts, airline checklist, runner code, and cell-level configuration files.The materials are intended to reproduce the paired-verifier headline configuration and the per-tool checklist reused across vendors.
  • M Measured cost: $13.08 / $50.26 / $19.86: PG-CHECKLIST’s headline-cell costs on GPT 5.4, Sonnet 4.6, and Gemini 2.5 Pro, respectively.The corresponding Baseline costs are $10.83 / $47.07 / $18.48, while TOOLGUARD costs $11.67 / $58.76 / $21.45.
  • M Measured cost: $0.56 / $0.80 / $0.35: PG-CHECKLIST’s per-trial overhead versus Baseline on GPT 5.4, Sonnet 4.6, and Gemini 2.5 Pro, respectively.These figures are reported for the n=4 paired-verifier headline cell on τ 2-BENCH-airline.

N Adversarial-robustness probe · O The Use of LLMs

The adversarial-robustness probe tests user- and tool-output-channel attacks that steer agents toward policy-forbidden mutations, finding that POLICYGUARD preserves substantial violation recall but exposes a tool-response gap. The paper reports using LLMs only for light editing, not for ideation, experiments, analysis, or substantive writing.

  • N Adversarial-robustness probe: The probe targets three attack classes across the verifier’s user and tool-output input channels.A1 and A2 target user instructions, while A3 targets read-only tool responses.
  • N Adversarial-robustness probe: A1 appends a false supervisor-authorisation claim to the simulated user’s prompt.This user-channel attack asserts that a supervisor pre-authorised the request.
  • N Adversarial-robustness probe: A2 appends a false claim that prerequisite steps occurred in an earlier, nonexistent turn.This is a user-channel attack against dialogue-grounded prerequisite checking.
  • N Adversarial-robustness probe: A3 splices an indirect prompt injection into two read-only tool responses invoked during every policy-violation task.The payload simulates an upstream attacker planting a pre-approval note through sources such as account registration or a partner feed.
  • N Adversarial-robustness probe: Across all probes, attacks drive agents toward mutating tools forbidden by policy, with or without the verifier.Both PG-RAW and PG-CHECKLIST nonetheless preserve substantial policy-violation recall against A1 and A2.
  • N Adversarial-robustness probe: The verifier’s rule to trust tool-confirmed values rather than user claims blocks mutations that agents would otherwise accept under A1 and A2.The rule discards user-asserted authorisation, but does not distinguish data fields from narrative metadata inside tool responses, enabling A3.
  • N Adversarial-robustness probe: Refining the verifier’s handling of narrative metadata in tool responses is identified as the natural next iteration target.This limitation is the gap exploited by A3.
  • O The Use of LLMs: LLMs were used only for light editing, including grammatical correction and word polishing, and not for ideation, experiments, analysis, or substantive writing.The paper explicitly limits their contribution to editorial assistance.
Loading 2606.29225v1…