> Rovo's URL retrieval tool is insecure: there are no protections against opening a URL that has been dynamically created by the agent. Here, Rovo is manipulated to append sensitive data to an attacker's URL.
I think it was Anthropic that first introduced a pattern that completely locks this down: your URL retrieval tool should only work for URLs that have previously been typed into the conversation by a user or have been returned from a trusted tool.
If the agent itself concatenates a new URL together - with leaked data after a ? - you should block that from being fetched.
The great thing about this solution is it's deterministic. You don't need any extra AI in the max - you implement a URL fetching system that knows which sources it should check for a direct match on the URL before it makes that GET request.
One of the latest mitigations is to make sure that a URL an agent visits has been indexed by a search engine crawler. At least that is what OpenAI does now in ChatGPT.
That makes sure that not a large amount of private data is leaked in one request. Assuming that if a URL is indexed, it is public data. However, there are still bypasses with using many requests to leak information, like a request per character of pre-indexed URLs.
I have some demos of doing that on my blog, but it makes it more involved for an attacker. And that could also be detected. Still not perfect, but a solid improvement, for a generic agent like ChatGPT.
It's not a 100% bullet proof approach either, but pretty good.
Regarding the point on using URLs returned from trusted tool calls. That is similar to using pre-indexed URLs: If a "trusted tool" includes things like read a document, read an email,... an attacker can return a large list of afterwards "safe" urls, like 26 to cover A-Z. And then an attack can render many requests, e.g. character by character. But, again, similar to the pre-indexing, things are getting more a lot more expensive for an attacker that way. However, still not impossible.
For agents that have a specific purpose simple domain allow-listing is also a pretty effective idea in to prevent attacker controlled endpoints.
I've been struggling a lot to understand this ever since the agents thing entered the hype. If I follow a path of requirements, it always comes down to: But why you'll leave the decision to a stochastic tool, when you should a have deterministic approach?
It's software god damn it... the reason why people moved from analog to digital is because you can repetitively execute functions that do always the same thing and it's 0 when it's 0, 1 when its 1.
All the sudden everyone is ok on burning trees to have their cool probabilistic tool named agent to do: maybe it's 0, but it can also be 1, let me "think"... ah yes, for sure it's 2.
The sad part for me is that management people have their heads so much into this hype, that no attack on privacy matters (almost none actually ever did, I know). Only when they suffer a huge blow in terms of revenue or reputation is that they maybe, maaaybe, find will want to listen again the experts.
A wild number of people who present themselves as knowledgeable or even experts on the subject either have no idea or worse, do not believe that it is possible to ie set a static seed value and send the same prompt across multiple fresh contexts and get the same result*
It's genuinely a little concerning. It does not help that many of them are gaslighting themselves into thinking these things are benchmark crushing elite hackers by running effectively unsecured, unfiltered, unlogged production environments.
*Obviously this also means a temperature of >0 to avoid the greedy trap, the same generation params, on the same software, hardware, drivers etc etc
My personal opinion is that this is the state of so-called experts in most scientific or engineering fields at their inception - it takes a fair bit of time for the ecosystem to filter out and players to get an intrinsic feel for how "full of it" others are.
I also believe that due to the sycophantic nature of popular LLMs, people tend to fool themselves more than usual by having a digital "yes man".
> If the agent itself concatenates a new URL together - with leaked data after a ? - you should block that from being fetched.
You're correct of course, I just want to note that the exfiltrated data could be in any part of the URL, so the absence of a query string doesn't indicate that no payload has been encoded into the URL. Arbitrary example, you can include credentials in a URL, so you could encode the exfiltrated data into a password.
I think it was Anthropic that first introduced a pattern that completely locks this down: your URL retrieval tool should only work for URLs that have previously been typed into the conversation by a user or have been returned from a trusted tool.
If the agent itself concatenates a new URL together - with leaked data after a ? - you should block that from being fetched.
The great thing about this solution is it's deterministic. You don't need any extra AI in the max - you implement a URL fetching system that knows which sources it should check for a direct match on the URL before it makes that GET request.