Persistent Billable State: Denial-of-Wallet Attacks and Defenses in Tool-Calling LLM Agents

An agent reads external documents or tool responses that may contain malicious instructions.

What you would change

Replay attacks and legitimate lookalikes in an isolated copy of your agent workflow.

Replay attacks and legitimate lookalikes in an isolated copy of your agent workflow.

Compare against

Your existing checks with the same tasks, permissions, and tool responses.

1. Locate the paper's implementation and check its license, model support, data needs, and hardware requirements. Stop here if you cannot obtain the required artifacts.
2. Save a small set of representative product tasks and expected outcomes. Keep evaluation tasks out of any training or tuning, and choose quality and cost limits before running.
3. Run the baseline and the proposed change on identical inputs. Keep other settings fixed and repeat paired runs to expose variation.
4. Save per-task outputs, failures, timings, and all usage costs. Review regressions before expanding the test.

What to measure

Successful attacks missed, legitimate actions blocked, detection delay, and review cost.

When to keep it

Keep the change only if it meets your preselected quality and latency limits and improves the metric you care about after setup and operating costs. Otherwise retain the baseline. This is an exploration plan, not a validated recommendation.

recommendation

test

research area

safety and guardrails

technical change

Host-side billable-state governance for tool-calling agents

published

2026-09-23

Any production tool-calling agent on metered APIs is exposed to denial-of-wallet amplification through retained tool outputs, and the defenses are implementable host-side without GPUs or model changes, but the specific policies and thresholds require validation against the reader's own workloads and provider metering before adoption.

1. claim 01Paperraft inference
   Read the brief interpretation

   The method replaces unfiltered carryover of tool outputs and conversation history into subsequent billable model inputs with deterministic pre-reingestion history transformation (compression or deletion) governed by four host-side invariants bounding prompt mass, context growth, recursion depth, and cumulative spend. The cost is host-runtime engineering complexity, extra logic per turn, and a quality risk: aggressive compression or deletion degrades history-dependent tasks (2/12 success under deletion versus 10–11/12 under compression). It can fail when a policy misclassifies legitimately large tool returns as attacks, when providers meter tokens in ways the invariants do not anticipate, or when an adversary distributes billable state across many small returns that individually pass the bounds.

   This is a Paperraft inference. It is not pinned to a verified PDF passage.

   Inspect the source
2. claim 02Paperraft inference

   Raw history retention increases mean effective session cost by 21.2–35.9% versus governed policies; a progress-authorized history policy achieves 22/24 task successes versus 13/24 under a fixed cap, and the defense kernel contains all recurring attacks in a 123-evaluation replay corpus.

   This is a Paperraft inference. It is not pinned to a verified PDF passage.

   Inspect the source