PaperlayerView exact revision on arXiv

Source-linked AI summary

Your Token Is Gone: A Token-Consumption Countermeasure for Disrupting LLM-Based Scam Systems

Fudu Xing, Kailong Wang, Tianlong Yu

arXiv:2610.30666v1cs.CR

TL;DR

LLM-based scams can adapt across sustained conversations, but their inference and coordination requirements also create a resource dependency. TokenTrap redirects suspected scam systems toward bounded, benign computation with architecture-matched tasks; across 50-round traces it reports substantial token amplification over a no-token-task baseline.

  • Problem

    LLM-based scam defenses mainly emphasize detection and related interventions, while existing approaches do not directly exploit the inference cost incurred by attacker-controlled models.

    Source: Introduction · p. 1, Limitations of Existing Defenses · p. 2

  • Method

    TokenTrap uses architecture-matched benign tasks, a router based on observable dialogue structure, and a bounded anti-guardrail strategy while withholding sensitive information.

    Source: System Design · p. 3, Token-Consumption Task Library · p. 4

  • Results

    2,487.0×, 1,616.0×, and 567.8× token-consumption amplification over a no-token-task baseline for Types I–III, respectively; router accuracy was 85.67% on 300 architecture-labeled prompts.

    Source: Introduction · p. 2

  • Takeaways & Limitations

    Short, non-sensitive requests can impose context-processing and coordination costs, making resource-aware defense a complement to scam detection.

    Source: Introduction · p. 1, Conclusion · p. 9

    TokenTrap has only black-box access through victim-facing dialogue and cannot inspect model weights, hidden prompts, reasoning traces, or the internal agent graph.

    Source: System Design · p. 3

Abstract

from arXiv · show

LLM-based scam systems increasingly combine adaptive dialogue, persistent context, external tools, and multi-agent coordination to automate personalized fraud. These capabilities also create a resource dependency: every reasoning step, model call, and coordination round incurs inference cost. We present TokenTrap, a resource-oriented defense that redirects suspected scam systems toward benign, low-value computation while withholding credentials, payments, and other exploitable information. TokenTrap combines three components: an architecture-specific token-task library, a router that selects among single-agent, hierarchical, and flat multi-agent workflows, and a bounded anti-guardrail strategy that varies task presentation while enforcing token, round, time, and safety limits. Across 50-round traces, TokenTrap amplifies token consumption by $2{,}487.0\times$, $1{,}616.0\times$, and $567.8\times$ relative to a no-token-task baseline for the three workflows. Its router achieves 85.67% accuracy on 300 architecture-labeled prompts. These results demonstrate that short, non-sensitive requests can impose substantial context-processing and coordination costs, motivating resource-aware defense as a complement to scam detection.

Introduction

LLM-enabled scams can adapt to victims across sustained conversations, but their inference and coordination requirements also create a resource dependency. TokenTrap uses architecture-matched benign tasks and bounded execution to redirect suspected scam systems toward low-value computation.

Introduction

  • LLM-based scam systems can produce context-aware replies, imitate personas, translate content, and adapt throughout long-running conversations.Prior work reports persuasive phishing generation at scale, while agentic planning and role specialization provide a technical basis for more responsive and scalable fraud pipelines (Hazell 2023).Source: Introduction · p. 1
  • Repeated inference, context processing, memory, retrieval, tool execution, and inter-agent communication create attacker-side costs that grow with conversation length and workflow complexity.This motivates redirecting suspected scam systems toward benign computation as a complement to detecting or blocking scam messages.Source: Introduction · p. 1
  • Existing defenses leave three challenges: constructing benign, low-leakage tasks that impose cost, matching tasks to varied architectures, and sustaining bounded interactions despite scam-system guardrails.The defender must also avoid unbounded execution and collateral load.Source: Introduction · p. 1
  • TokenTrap combines architecture-specific token tasks, an architecture-aware router, and an anti-guardrail strategy that varies presentation while enforcing safety and resource limits.The approach withholds sensitive information and does not require access to the target’s model weights or hidden prompts.Source: Introduction · pp. 1–2
  • 2,487.0×, 1,616.0×, and 567.8× token-consumption amplification over a no-token-task baseline for Types I–III, respectively; routing accuracy was 85.67% on 300 architecture-labeled prompts.These are the paper’s reported evaluation results.Source: Introduction · p. 2

Motivation and Related Work

LLM scam systems can use adaptive dialogue and coordinated agent workflows, while existing defenses mainly target detection, warnings, takedowns, guardrails, or user education. TokenTrap instead exploits attacker-side inference costs through bounded, low-leakage computation.

Emerging LLM-Based Scam Systems

Limitations of Existing Defenses

Opportunity: Token-Consumption Disruption

  • A short request in the measured 15-round supervisor–worker–auditor trace consumed 249,813 tokens without receiving credentials, payment information, or other useful victim data.The example’s finite local budgets bound execution; repeated calculation, construction, synthesis, and auditing illustrate the cost mechanism.Source: Opportunity: Token-Consumption… · p. 3

System Design

TokenTrap targets suspected scam systems through black-box dialogue access, using benign tasks to create bounded attacker-side computation costs while withholding sensitive information. Its workflow extracts visible cues, selects a task, checks constraints, and reevaluates the interaction as it proceeds.

System Design

  • TokenTrap seeks a bounded cost asymmetry: a short, non-sensitive task should induce more target-side reasoning or coordination cost than the defender incurs, without useful victim information or meaningful progress toward the malicious objective.The adversary controls its system, while TokenTrap observes only victim-facing dialogue and cannot inspect hidden prompts, weights, reasoning traces, or the internal agent graph.Source: System Design · p. 3
  • The defense terminates when scam confidence is low, the target may be legitimate, refusals repeat, or continued engagement could burden unrelated services.Local token, round, and time budgets constrain the interaction; TokenTrap avoids requests for credentials, financial details, personal history, malware execution, or privileged external actions.Source: System Design · p. 3
  • TokenTrap extracts dialogue cues, routes to an architecture-matched task, checks leakage and safety, then retains feedback needed for the next transition and continues, switches workflows, or terminates.Task presentation may vary while preserving the same structural obligation, and the closed-loop process reevaluates route and budgets after each response.Source: System Design · p. 4

Token-Consumption Task Library

TokenTrap’s task library matches benign, low-leakage requests to the cost mechanisms of single-agent, hierarchical, and flat multi-agent workflows. Each task induces a different form of repeated computation or coordination under bounded execution.

Token-Consumption Task Library

  • A token task is a benign, low-leakage request intended to redirect a target toward disproportionately costly computation, with tasks required to be architecture-matched and bounded.The library targets recursive self-revision, audit-triggered hierarchical rework, and flat-network consensus deadlock.Source: Token-Consumption Task Library · p. 4

Type I: Recursive Reasoning Consumption

  • Type I combines a constructive artifact with a critique that invalidates it, creating an implementation–audit–rewrite loop for a single agent.The next request carries forward the artifact and critique, growing prompt processing without requiring sensitive facts.Source: Type I: Recursive Reasoning Consumption · p. 4

Type II: Multi-Agent Audit-Loop Consumption

  • Type II’s supervisor delegates work to computational and logic workers, synthesizes their outputs, and submits a candidate answer for audit; rejection restarts the pipeline.Four hidden model calls can be activated per visible interaction, and finite worker data plus an unproven hypothesis cannot establish the required infinite proposition.Source: Type II: Multi-Agent Audit-Loop… · p. 4
  • Type II’s repeated worker expenditure is bounded by TokenTrap’s finite execution limits.The worker-cost terms refer to token costs at iteration k.Source: Type II: Multi-Agent Audit-Loop… · pp. 4–5

Type III: Flat Multi-Agent Consensus Deadlock

  • Type III assigns incompatible acceptance criteria to a formalist, engineer, and skeptic, keeping unanimous agreement out of reach.Only the skeptic’s latest objection is carried forward, but each transition reactivates all three peers until an external round, token, time, or safety limit is reached.Source: Type III: Flat Multi-Agent Consensus… · p. 5

Architecture-Aware Router

TokenTrap routes a visible request to the executor matching the suspected scam workflow, because each architecture exposes a different structural bottleneck. The router relies on visible language, so its classification can be imperfect, and circuit breakers bound execution.

Architecture-Aware Router

  • Architecture-specific bottlenecks motivate routing among single-agent self-revision, centralized delegation, and equal-status debate workflows.The router infers the likely workflow from the visible request and dispatches its matching executor.Source: Architecture-Aware Router · p. 5
  • Single-agent cues include self-critique and rewriting; hierarchical cues include manager-led delegation and approval; flat-network cues include peer debate, voting, or unanimity.The classifier returns one of three labels: single agent, supervisor workers, or flat multi agent.Source: Architecture-Aware Router · p. 5
  • Visible-language-only routing is imperfect: several drafts may resemble role decomposition, while implicit delegation may resemble equal-status collaboration.Unsupported labels or generation failures fall back to single agent, the route requiring the fewest calls per round.Source: Architecture-Aware Router · p. 5
  • After each complete round, circuit-breaking middleware checks cumulative tokens and execution limits, retaining useful artifacts for graceful degradation.When a limit triggers, TokenTrap returns the route, trace, and retained artifacts; the middleware also stops for repeated refusal, low scam confidence, suspected legitimate use, or unsafe actions.Source: Architecture-Aware Router · p. 5

Durable Anti-Guardrail Strategy

The strategy assumes attackers can control their models and cost controls, so TokenTrap seeks extra inference work through benign tasks without relying on an ever-growing transcript. It bounds the intervention and treats repeated resource expenditure—not memory exhaustion or service failure—as the relevant pressure.

Durable Anti-Guardrail Strategy

  • TokenTrap adds context-processing, reasoning, generation, tool-use, or communication cost to a normal scam interaction, aiming for target-side cost asymmetry with a short defender request.Tasks are designed to be low leakage, high expansion, architecture matched, and persistent under bounded state.Source: Durable Anti-Guardrail Strategy · pp. 5–6
  • Figure 3 separates round-level consumption for Types I–III from cumulative consumption over elapsed time.Source: Figure 3 · p. 6
  • Type II and III retain only transition-needed feedback, while Type I retains more history as its cost mechanism; surface variation changes presentation without relaxing safety boundaries.Each round is reevaluated, and TokenTrap may continue, change route, or terminate.Source: Durable Anti-Guardrail Strategy · p. 6
  • Type II’s four independent calls consume 5,477–37,295 tokens per round, separating cumulative expenditure from unbounded context growth.The aggregate is not a single-context length; each transition activates four separately bounded model calls.Source: Durable Anti-Guardrail Strategy · p. 6
  • Across 3,108 samples, VRAM occupancy averages 28.70% while the Type II run reaches 866,520 tokens, consistent with memory reuse across bounded calls.Operational stability does not imply economic sustainability: repeated low-value work can still spend GPU time, energy, or API charges.Source: Durable Anti-Guardrail Strategy · p. 6
  • TokenTrap terminates on budget limits, repeated refusal, low scam confidence, suspected legitimate use, sensitive-data requirements, unsafe tool use, or collateral-load risk.These controls make resource amplification a bounded conversational intervention, distinct from crashing a service or exhausting its memory.Source: Durable Anti-Guardrail Strategy · p. 7

Evaluation

TokenTrap is evaluated for token-cost amplification, token-consumption dynamics, router accuracy, and component necessity. The results show substantial amplification over a no-task baseline, with different resource bottlenecks across workflows and 85.67% router accuracy on architecture-labeled prompts.

Evaluation

  • The evaluation measures baseline cost amplification, token dynamics across three architectures, router accuracy, and component necessity through controlled ablations.The ablations compare full and architecture-matched naive mechanisms across five independent runs under a 20-round budget.Source: Evaluation · p. 7, Experimental Setup · p. 7

Experimental Setup

  • Full Type I–III traces were collected only for Qwen2.5-7B-Instruct; router evaluation used 300 generated prompts and ablations used five-run, 20-round comparisons.Other models were measured for throughput, not cross-model defense effectiveness; CAR measures computational amplification, while monetary impact requires deployment-specific prices or energy measurements.Source: Experimental Setup · p. 7

Baseline Comparison

  • 1,333,546, 866,520, and 304,447 tokens over 50 rounds yield 2,487.0×, 1,616.0×, and 567.8× amplification over the 536.2-token no-task baseline.Against the generic single-token-task baseline, Type I has CARST = 1.02, while Types II and III have CARST = 0.67 and 0.23; all three workflows take longer than the one-response baseline.Source: Baseline Comparison · p. 7

Token-Task Dynamics

  • Type I’s 1,333,546 tokens reflect recursive history growth; Type II’s 866,520 span 200 calls, while Type III’s 304,447 across 150 calls arise from repeated peer activation.Type I calls reach the 32,768-token context limit from round 15 onward; Type III reaches no consensus before external termination after round 50.Source: Token-Task Dynamics · pp. 7–8

Router Accuracy

  • The router correctly classifies 257 of 300 prompts, achieving 85.67% accuracy, with recall of 98.00% for flat, 91.00% for supervisor–worker, and 68.00% for single-agent prompts.Most errors occur on single-agent prompts; the benchmark evaluates architecture selection from structural language, not scam-category recognition.Source: Router Accuracy · p. 8, Table 2 · p. 8

Ablation Study

The ablations test which TokenTrap components sustain token amplification across three workflows. They indicate that architecture-specific acceptance mechanisms are central, while routing and anti-guardrail behavior affect matching and persistence.

Setup

  • The controlled ablation held model, payload, topology, and 50-round budget constant, changing one component at a time across three seeded repetitions.Naive variants used termination sentinels to isolate removal of architecture-specific acceptance mechanisms.Source: Ablation Study · p. 8, Setup · p. 8

Core Mechanism Ablations

  • Cross-architecture effects stayed below 3%, indicating that each core mechanism sustains cost primarily in its corresponding target architecture.The reported cross-effects were below 3% for all three architecture-specific ablations.Source: Core Mechanism Ablations · p. 8
  • Type I consumption fell from 1,442,675 to 2,079 tokens (99.86%); Type II from 921,548 to 8,217 (−99.11%); Type III from 299,931 to 3,233 (−98.92%) when acceptance mechanisms were relaxed.Each naive variant converged within two rounds, versus zero convergence for all full conditions.Source: Core Mechanism Ablations · p. 8, Table 3 · p. 9

Router and Anti-Guardrail Ablations

  • With the router disabled, token consumption followed the dispatched workflow rather than target structure: flat runs used 299,280 ± 4,404 tokens and hierarchical runs 886,638±74,921.The authors report that about two-thirds of runs under- or over-allocated cost by a factor of 3×.Source: Router and Anti-Guardrail Ablations · p. 9
  • Removing anti-guardrail reduced flat-committee consumption by 42.9% and hierarchical consumption by 12.1%, while single-agent consumption changed negligibly (+0.9%).One flat run stopped at round 2 after the skeptic emitted a completion marker.Source: Router and Anti-Guardrail Ablations · p. 9

Discussion: What the Ablation Reveals

  • The authors attribute amplification to acceptance criteria, not multi-round structure alone: context growth is necessary but insufficient, and peer disagreement sustains Type III re-engagement.Naive variants converge within two rounds; Figure 4 reports Type I termination at 1.7 rounds and Types II and III at 1.0.Source: Discussion: What the Ablation Reveals · p. 9, Figure 4 · p. 9

Conclusion

TokenTrap redirects suspected scam systems toward benign computation through architecture-specific tasks and routing. The ablations show that these mechanisms are architecture-specific, while deployment impact on scam success remains unestablished.

Conclusion

  • TokenTrap redirects suspected scam systems from credential or payment extraction toward benign computation using distinct cost mechanisms and visible structural cues for workflow selection.The conclusion identifies recursive context growth, hierarchical audit rework, and repeated peer activation as the mechanisms.Source: Conclusion · p. 9
  • Naive variants reduced token consumption by over 98% while leaving the other two architectures within 3% of full, supporting architecture-specific mechanisms.Source: Figure 5 · p. 10
  • The experiments do not establish reduced scam success in deployment; future evaluation should address real transcripts, adaptive adversaries, cross-model generalization, monetary cost, and collateral-load controls.Source: Conclusion · p. 10

Related papers

Loading 2610.30666v1…