Prompt injection guards the agent's inputs. An on-chain agent has a second adversarial surface its threat model omits — its outputs. A correct, un-injected transaction is public intent the instant it hits the mempool, and it gets front-run before it lands.
A team builds an on-chain agent and does the security work the field tells them to do. They treat the open web as hostile, tag tool output as untrusted, isolate the planner from raw content, gate the signing path behind a policy check, scope the wallet’s authority. They have hardened every place an attacker could reach in. The agent reads a price feed, reasons correctly, and decides to swap a large position on a decentralized exchange. No injection got through; the plan is exactly right. The agent broadcasts the transaction.
And it loses money anyway. Not because anything in its context was poisoned — the plan was clean — but because the transaction itself, sitting in the public mempool waiting to be included in a block, is a public announcement of what the agent is about to do. A bot reads it there, in the open, before it lands: it buys ahead of the swap, lets the agent’s own trade move the price, and sells into it. The agent gets a worse fill than it reasoned about, the difference is the bot’s profit, and the agent did everything right and was still beaten — at a boundary the prompt-injection defense never touched.
The prompt-injection threat model treats an agent’s untrusted inputs as the whole problem. For an agent that browses, that is right as far as it goes — a web agent trusts the page it is reading, and a malicious page diverts it. But an on-chain agent has a second adversarial surface the input model omits entirely: its outputs. Every pending transaction is public before inclusion, and a fully correct, un-injected agent still leaks its intent and loses value at that output boundary — one no input-sanitization defense reaches. This post is about that second surface: why the transaction an agent emits is itself an attack surface, why input hardening cannot defend it, and what does.
The cleanest statement of the split is the anchor source’s, in one sentence. A systematic review of agent-on-blockchain integration — Autonomous Agents on Blockchains: Standards, Execution Models, and Trust Boundaries (arXiv 2601.04583) — builds a unified threat model for agent-driven transaction pipelines and puts the two attacks side by side: “a prompt-injection event during observation can corrupt planning, while adversarial execution effects can invalidate an otherwise correct plan.”
Two clauses, two victims. The first is the input surface everyone already defends: the agent observes and injected content corrupts the plan it forms — the prompt-injection class, the surface the audit of an agent that holds a wallet covers, the gap between reading hostile text and signing a transfer.
The second clause has no injection in it. “Adversarial execution effects can invalidate an otherwise correct plan.” The plan is correct — formed from clean inputs, reasoned without error — and invalidated anyway, at execution, by an adversary acting on the transaction after the agent emitted it. Nothing it read was hostile; the hostile thing is what happens to its output once public. The same review names the venue: “Because pending transactions are publicly observable prior to inclusion, blockchain execution environments incentivize adversarial reordering and insertion strategies,” so “agents must treat public mempools as adversarial venues rather than neutral queues.” The input half of the threat model has a mature defense discipline; the output half is, in most agent-security framings, simply absent — and it is the half that beats a correct agent.
When an agent acts, it broadcasts a transaction. On a public chain that does not go straight into a block; it sits in the mempool — the public, network-wide set of pending transactions — visible to everyone for the interval between broadcast and inclusion. During that interval it is a published statement of intent: this address is about to swap this amount of this asset at this venue. The anchor review puts it in those terms: “For an AI agent, the public mempool is not a neutral queue. It is a public information channel where valuable intent can be detected and strategically exploited.”
The leak is not a bug in the agent’s code or a gap in its context hygiene; it is structural to broadcasting on a transparent ledger. To get a transaction included you must first make it public, and that reveals what you will do to anyone watching. The adversary need not compromise the agent, breach its keys, or inject a token into its context — only read the mempool, public by design, and act faster on the agent’s stated intent than the transaction lands.
This is why input sanitization is the wrong tool, not merely an insufficient one. Every input defense — trust boundaries, planner isolation, provenance tagging, policy gates on signing — operates on what flows into the agent’s reasoning. The output leak happens after all of that has succeeded: the plan is fixed and correct, and the only thing the adversary touches is the published artifact. There is nothing to sanitize at that boundary, because the attack does not use an input — it uses your output as its input.
This is not speculative; the output attack has a name and a founding paper. Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges (arXiv 1904.05234) documented and quantified the arbitrage bots that “exploit inefficiencies in DEXes, paying high transaction fees and optimizing network latency to frontrun, i.e., anticipate and exploit, ordinary users’ DEX trades.” Put “the agent’s” for “ordinary users’” and it is the opening scene.
The same paper names the lever. Bots “engage in what we call priority gas auctions (PGAs), competitively bidding up transaction fees in order to obtain priority ordering, i.e., early block position and execution, for their transactions.” That is why the agent cannot defend at the input: the contest is over ordering, and the adversary buys position by outbidding on fees for transactions it observes. The agent’s correctness is irrelevant to a fight it is not party to.
This is structural, not a defect in any one agent or contract: the paper highlights “the large, complex risks created by transaction-ordering dependencies in smart contracts and the ways in which traditional forms of financial-market exploitation are adapting to and penetrating blockchain economies.” The value extracted this way — maximal extractable value, MEV — is a property of how public, ordered ledgers work, inherited the moment an agent transacts. That grounds the post’s hardest claim: a fully correct agent still loses, because the loss comes from nothing it got wrong.
Front-running might still seem rare — a tax on the unlucky, not a structural cost. The measurement says otherwise, at a scale that makes “edge case” untenable. A remeasurement — Remeasuring the Arbitrage and Sandwich Attacks of Maximal Extractable Value in Ethereum (arXiv 2405.17944) — reports the magnitude in real dollars: “Before September 2022, around $675M was extracted in terms of MEV in Ethereum.” That is value taken at the output boundary, off overwhelmingly correct transactions. The same study counts the events: “9.4 million in-the-wild MEV activities … 6,331,851 arbitrages and 3,016,971 sandwich attacks … more than 100K DEX addresses and 129K tokens are involved.” That is not a corner of the ecosystem but its weather.
The same paper warns the surface is undercounted by naive tooling. Improving on prior heuristic detectors, the authors “detect 16.4% and 1.2% more arbitrages and sandwich attacks, respectively” than state-of-the-art methods — the intuitions a team is likely to bring miss double-digit fractions of the attacks. An agent estimating its MEV exposure off-the-shelf believes the boundary is safer than it is.
The anchor review turns this from a market curiosity into a design constraint for machine-speed agents: “For an AI agent that executes repeatedly and at machine speed, treating MEV as an edge case is a reliable path to systematic value leakage.” A human trades occasionally and eats the tax occasionally; an agent that transacts in a loop pays it on every leaky action. The faster and more autonomous the agent, the more the output boundary bleeds.
The natural response is one move: stop broadcasting to the public mempool. Route the transaction privately — through a builder or private orderflow — so it is never visible before inclusion and the front-runner has nothing to read. The anchor review endorses exactly this; its first named mitigation is to “reduce public intent leakage. Where feasible, avoid broadcasting valuable actions to the public mempool and prefer execution pathways that reduce pre-trade visibility or expose only minimal information.” The output surface is defendable, then — but not closable, and that difference is the honest core of the claim.
The measurement that closes the loophole is Sandwiched and Silent: Behavioral Adaptation and Private Channel Exploitation in Ethereum MEV (arXiv 2512.17602), tracking what users do after moving to private routing. First, private routing is now a mass behavior — evidence the output attack is a first-class operational pressure: “around 40% of victims migrate to private routing within 60 days, rising to 54% with repeated exposures.” Second, and decisively, the private channel is itself exploitable: “private routing does not guarantee protection from MEV extraction: while execution failures push users toward private channels, these remain exploitable and highly concentrated.” The numbers: “In Nov-Dec 2024 we confirm 2,932 private sandwich attacks affecting 3,126 private victim transactions, producing $409,236 in losses and $293,786 in attacker profits.”
The defensible position holds three facts at once: the output boundary leaks value to a correct agent (high, measured, structural); private orderflow genuinely reduces the leak and is the right first mitigation, not a counsel of despair; and private channels are exploited too, so “we route privately” is risk reduction, not boundary closure. Quote only the first and you sound alarmist; quote only the second and you have talked yourself into a safety you do not have. That is why the output surface belongs in the threat model as its own line item, sized and budgeted, not assumed away.
The omission is a real pattern, not a strawman: a careful paper can cover the input surface thoroughly and still leave the output surface out. The first systematization of knowledge on the topic — SoK: Security and Privacy of AI Agents for Blockchain (arXiv 2509.07131) — frames the attack surface around input and credential threats. Its headline risks are wallet draining via “attack vectors such as prompt injection”; “fake memory” or context manipulation “where adversaries inject malicious memory to deceive the agent into harmful transaction flows”; and the agent as a custody risk because “such operations often require access to highly sensitive information, including end-users’ private keys, making AI agents a potential attack surface for adversaries.”
Every one of those is the input or custody boundary — corrupt the observation, poison the memory, steal the keys. The enumerated risks are the ones where the adversary reaches into the agent; the case where the agent does everything right and the adversary mines its correct, public output is not in the frame. This is the same boundary distinction as the levels of agent-chain integration: how much of an agent’s authority and execution live on-chain sets its public-output exposure, and one that drafts for a human approver leaks less than one that broadcasts autonomously in a loop. Place the system on that ladder first.
You cannot stop an on-chain agent from making transactions public; inclusion requires announcement. You can stop treating that boundary as if input hardening covered it, and make MEV-aware execution a first-class part of the agent.
Put the output boundary in the threat model as its own line. The input and output surfaces are different attacks with different defenses. Write the second one down: a correct, un-injected transaction can be front-run, sandwiched, or reordered after emission. A model listing only prompt injection, memory poisoning, and key compromise has documented one half of an on-chain agent’s exposure.
Reduce public intent leakage on valuable actions. The load-bearing mitigation: where feasible, do not broadcast valuable actions to the public mempool. Private orderflow, batched execution, and commit-reveal all attack the leak at its source by shrinking the window in which intent is readable. This is execution-side engineering; prompt hardening does not substitute for it.
Bound the loss you cannot prevent. Because the private channel is exploitable too, assume some extraction gets through and cap it: tight slippage limits on every swap, deadlines that void a stale transaction, sizing that splits a large action into less exploitable pieces.
Size the leakage and watch it. Measure realized slippage and extraction against expectation per action — and not with naive detection, since the remeasurement paper found state-of-the-art heuristics undercount attacks by double-digit fractions. An agent executing in a loop pays the difference repeatedly.
Keep the input defenses — they cover the other half. None of this retires the prompt-injection work; the input surface is still defended as the wallet-holding agent audit prescribes. Input hardening and output execution-discipline are two defenses for two surfaces, and an on-chain agent needs both.
Before an agent is allowed to broadcast transactions on a public chain on its own:
An on-chain agent is hardened on the side everyone looks at — the inputs, where a hostile page or a poisoned memory reaches in — and exposed on the side the input model never mentions: the outputs, where its own correct transaction becomes public intent the instant it hits the mempool, to be front-run, sandwiched, or reordered before it lands. The defense for the second surface is not a better prompt or a tighter trust boundary; it is MEV-aware execution that leaks less and bounds what leaks. Treat the agent as adversarial on both sides at once and build a defense for each — because the attacker reading your output never touches your input, and the agent that did everything right is the one standing at that boundary.
GRPO's group-relative advantage looks like a clean normalized policy gradient. Two of its normalizers aren't neutral: dividing by response length rewards longer wrong answers, dividing by reward std overweights easy and hard questions. The trainer optimizes both, faithfully.
16 min →
A big pass@1 jump after a GRPO run reads as the model having learned to reason better. Often it has not — it has learned to pick, more reliably, a solution path it already had. RLVR re-weights the base model's existing reasoning rather than creating new reasoning, and whether any RL budget escapes that is genuinely disputed.
14 min →
Chinchilla's twenty-to-one was fit on unique data, one pass. Teams now repeat scarce corpora at tens of times that ratio, where the law breaks — and past a repetition threshold the re-derivations reverse its verdict: spend compute on capacity, not more epochs.
14 min →