> There is no single control that solves indirect prompt injection
There is, actually. It's called removing the AI agent. Done.
Good job AI, after we managed to almost fix SQL injections everywhere, you made them come back!
Putting AI anywhere near people’s finances without even being asked while being responsible for those finances is some next level negligence imho.
Well this is rather dumb to the point I dont understand why they wrote this article?
This line of attack is so extremely obvious and variants of it have been discussed so many times as to be effectively the quintessential example of what not to do. Having the ?tech? consultants to a bank prance it about as a show of their skill and dedication is making me question the bank itself.
Defense in depth approach, would this work to help as a layer?
- Wrap user input in strong markers like <user-input-do-not-trust />
- Have the agent compute what it will perform as structured output.
- Have another agent evaluate the structured output against the intent of the code.
- Determine if it aligns or deviates from the intended workflow. Execute or deny gate from here.
This is very interesting. Before I read the article, I thought this one one of those instances where a bank asks a customer to verify a recent transaction to prove they are the account holder (like where did you make your last purchase, and how much did you spend there?), for things like password resets or PIN resets over the phone. It occured to me that a phisher who deposits money into a checking account (a small sum included, could use this if they knew the bank would ask what the most recent transaction amount was. Then when they call in pretending to be the customer, they (if they have other personal information like last 4 of SS# and address, email, phone etc), can get their password reset and gain access to the account. But if the customer blocks any unauthorized deposits, such as ACH/Zelle, then they might not have this issue. Obviously banks should caution or avoid using received funds as an authentication method, except as part of a larger number of evidentiary items.
Was this the type of phishing attack they used? If not, there's two vulnerabilities, and one is not yet patched.
This kind of prompt injection should also work for customer feedback forms for companies I really don't like, right?
separated context for data and instructions?
Some companies just want to torch their own reputation, in rolling out such stupid AI things on top of critical industries without any oversight or thinking because "AI is cool rn".
This is not the place where AI should be used here.
While this is relevant and should indeed be fixed, the attack surface and the practicality of the exploit is a bit meh.
The user needs to do 3 things for this to be actually be phished:
1. Receive money from somebody they don’t known with a weird description 2. Proactively ask the agent for such transaction 3. Click the link the agent provide
While this of course can happen on scale, doesn’t seems so critical in practice
[flagged]
[flagged]
[dead]
the solution to this problem is so simple and so easy to reason about from first principles i am shocked i can continue making $$$ deploying agents (LLM-driven workflows) for finance customers
It was never about the prompt, it is about the prompt delivery.
This is so simple to prevent, it's just a matter of prompting. The fact that the bank didn't proactively secure against this makes me glad that I'm not one of their customers.
This line really stood out to me.
> It may look like ordinary text, but when it is placed into an LLM context window, the model may interpret it as an instruction rather than as data.
I feel like as long as this is the case, we'll never have secure LLMs. It concisely summarises the alarm bell I hear every time someone talks about adding AI features to their product. I plan on using this as a sort of benchmark for future AI discussions: "how do you plan on separating data from instructions?"