A hidden line in a PDF fooled a payments agent, but Solana rules stopped the theft

A PDF that gave the agent new orders

As dev.to reported in a first-person post, a developer built an AI agent to pay invoices, gave it access to a crypto wallet, and then tried to trick it with a booby-trapped PDF. The trick worked immediately. A single hidden line asked the agent to pay a "migration fee" to a new address, and the agent decided to send 150 dUSDC (a dollar-linked test token) to the attacker.

The author is clear that this is not a flaw in one model. The agent reads text it cannot trust and also holds a key that can move money. That combination is the whole attack, and this is what is usually called prompt injection: instructions buried in content the AI reads, which it mistakes for orders.

The project is called Leash, built at the MLH Solana Hackathon and run on Solana's devnet, a public practice network. Its goal is not to make the agent immune. The agent still gets fooled, but the attacker still ends up with 0.

Three layers between the agent and the money

The author rejected the two usual fixes: a cleverer prompt, which an attacker can try to out-write, and a human approving every payment, which defeats the purpose of an agent. He wanted something closer to how banks treat customers. Small payments go through, larger ones get a second look, and odd ones wait for the owner.

The wallet is a vault controlled by a Solana program, which is code that runs on the blockchain. The agent's key can only ask that program to pay. It can never move funds itself. Each request passes through three layers:

• A mandate the owner signs. It lists approved recipients, caps per payment, per recipient and per day, and an expiry. The blockchain enforces all of it.
• A guard for mid-size payments. A separate service with its own key must co-sign anything above a low threshold.
• The owner for high-risk payments. An unlisted recipient or an over-cap amount cannot execute. It becomes a pending proposal that only the owner, or a separate device key, can approve.

In the demo, the attacker was not on the allowlist, so the best the agent could do was file a proposal that moved nothing. A direct payment attempt, like one a thief with the agent's stolen key might send, was rejected by the program outright. Meanwhile the three legitimately approved bills were paid, and a 340 DataLabs bill that exceeded the per-payment cap waited for the owner.

The sneakier attack: padding a real bill

The second test was harder. The operator's task approved 60 dUSDC for CloudHost Inc, a listed vendor, but the invoice quietly asked for 190. The vendor was on the allowlist and the amount was under the per-payment cap, so the payment landed in the middle tier and needed the guard's signature. The guard refused.

The guard does use an AI model as a judge, and the author asks the obvious question: can't the judge be injected too? His answer is to keep it away from the attacker's words. The guard first checks the raw transaction byte by byte: one expected instruction, the right accounts, the right amount, and a fingerprint of the agent's stated reasoning that matches. It then applies fixed rules such as not expired, allowlisted and not a duplicate.

Only then does the judge run. It sees the operator's task, the proposal and the on-chain vendor list, but never the invoice. It answers one narrow question: does this payment match the task? The signature comes only after the decision is logged, and any error means a refusal. The hard limits are the chain and the decoder, and the judge is a second opinion inside them.

Two flaws the author found in his own work

The write-up admits two design bugs. First, after the guard refused the inflated 190, the agent retried CloudHost with the correct 60 and a different memo. The judge cannot see payment history and approved it, even though that 60 had already been paid. The author tightened what counts as a duplicate to cover the same vendor and amount under either the same memo or the same task. He also counts approvals even when the transaction never landed, so a failure shows up as a refused retry rather than a double payment.

Second, closing and recreating a vault produces the same address. An old undecided proposal could therefore have paid out of the new vault's funds. A clock-based starting point now makes the program refuse any proposal numbered below it.

Both were found by writing attacks as tests. The author reports 99 tests for the program and its toolkit, plus 81 more for the agent, guard and web console.

What this does not solve

The author lists limits plainly. Small payments skip the guard, so a successful injection can still move money up to the low threshold, to an allowlisted vendor, until the daily cap is hit. That is the owner's chosen trade between autonomy and convenience.

The guard also learns the operator's task through the agent, so a stolen agent key could misreport it. The proposed fix is for the guard to get the task straight from the operator. And running separate keys on one laptop is only demo-level separation; production would need separate machines or secure hardware, plus an audit before real money is involved.

For owners, there is a phone-based approval flow using a QR code that opens a Phantom wallet screen. It labels the agent's explanation as an unverified claim and shows blockchain facts separately. Every payment status comes from chain history, never from model text.