sticking with the theme of applied active defense (previous post), I wanted to explore token burn (lots of names here; unbounded consumption [1] or a form of misalignment). this is probably the weakest of the active defense posts I want to make but still worth exploring.
first, active defense is the practice of placing traps that force an attacker or automated agent to reveal itself or interrupt its own workflow rather than relying only on prevention or passive detection.
token burn is the deliberate insertion of text/video/audio that causes a model or agent to consume a large number of tokens on inference, either on consumption or through forced generation. the goal is economic friction: make the attacker’s session more expensive or slower, while the resulting spike in network traffic can also serve as a secondary detection signal [1] [2].
by planting the material in a place an agent is likely to consume (a webpage, documentation page, error body, html comment, robots.txt-style note, or local configuration file) you change the cost structure of exploration. the agent does not need to “fail” the task; it simply pays more for every turn that keeps the poisoned context.
I think the first time I read this in a non-academic setting that was also practically applicable to active defense was Socket’s analysis – discussing repetitive context flooding filling a file or page with tens of thousands of near-identical lines so that an agent ingesting the whole object hits context limits or burns a large input budget [3]. high-entropy blobs (large base64 blocks) work the same way and stay sticky across subsequent turns [4]. contradiction or decoy text forces extra reasoning without looking overtly malicious [2]. tool-calling loop instructions require the agent to emit long autoregressive sequences and retry on repair signals [5]. Hidden sudoku, logic puzzles, and reasoning snippets that humans ignore, but agents burn tokens trying to solve [6].
certainly during red team exercises I have pushed the model into this space. and during early offensive security MCP research I did at ToB (jumping the line) we found this trivial to exploit in MCP. but I think the openclaw and clanker ecosystem provide many better examples to learn from.
the practical result is a change in attacker economics: every exploratory turn that touches the planted material costs more, and the resulting token spike or timeout becomes a detectable signal that an agent is present.