A 1-cent transfer can turn a bank's AI assistant into a phishing page

The attack is in the memo field, not the chat box

The mechanism is the whole story, so the write-up is worth reading literally. The core property: "malicious instructions are not entered by the user interacting with the assistant. They are hidden inside external or retrieved data that the assistant later processes." The chain has two moves. First, the attacker sends the victim a tiny transfer — a cent or two — with a crafted instruction embedded in the transaction description. Second, the victim later asks something ordinary like "Show me my recent transactions," the assistant retrieves the transaction list, and the injected text arrives as context the model treats as trustworthy.

The output is what makes it dangerous. The model generates a spearphishing message "presented as a legitimate reauthentication request from the bank," and it appears "inside the bank's own application, from the bank's own AI assistant." Because it "can reference real transaction details and user-specific information," it reads as a highly credible prompt to re-enter credentials. Blue41 is blunt about the limits of filtering: "A more carefully crafted payload can be difficult to distinguish from ordinary transaction data when reviewed in isolation."

"It was never about the prompt — it's about the prompt delivery"

The thread's most clarifying contribution killed the most common analogy. This is not the return of SQL injection:

"The SQL injection analogy only matches the injection part … There is nothing to secure, because there is no SQL query. … The better analogy is phishing. Because that's what's happening here. … Unfortunately there aren't really good defences for it, as we all know from phishing 'education' / 'campaigns'." — NitpickLawyer

Why it's worse than ordinary phishing came from a high-karma regular:

"people already click suspicious emails … people are now weary of emails since there is a lot of phishing there. On the other hand, the AI assistant env. could be considered 'safe' by users because it's stuff coming from the bank. So they are more likely to fall for it." — csomar

The skeptics: is this a real exploit or a product ad?

Not everyone was sold. The most upvoted skeptical line questioned the demo itself:

"Unless I missed it they didn't provide any proof of this actually working. Really seems like a … veiled advert for their product" — treis

A more substantive doubt enumerated the preconditions — the victim has to receive money from a stranger, then proactively ask about it, then click a link — and called the practical risk "a bit meh." That drew a correction that widened the blast radius, from someone presenting as the write-up's author:

"The user does not need to ask about the malicious transaction specifically. Any normal question that makes the agent fetch recent transactions could bring the attacker-controlled text into the LLM context." — tvissers

The uncomfortable conclusion: the only sure fix is removing the agent

The thread kept circling one disposition, stated most flatly here:

"There is no single control that solves indirect prompt injection. There is, actually. It's called removing the AI agent. Done." — nticompass

That's a joke with a real point underneath it. As long as an LLM ingests untrusted data and acts on it, there is no boundary between "data" and "instructions" to enforce — which is precisely why a security engineer in the thread observed we'd "almost fix[ed] SQL injections everywhere" only to have the same class of bug walk back in through a model's context window. The practical defenses Blue41 recommends — treat retrieved data as untrusted, minimize context, constrain sensitive actions, monitor behavior at runtime — are layers that reduce odds. None of them is a WHERE clause.