For me the story is that Antigravity tried to prevent this with a domain whitelist and file restrictions.

They forgot about a service which enables arbitrary redirects, so the attackers used it.

And LLM itself used the system shell to pro-actively bypass the file protection.

> Personally I'm hesitant to allow mine (I use Cline personally) access to a web search MCP and I tend to give it only relatively trustworthy URLs.

Web search MCPs are generally fine. Whatever is facilitating tool use (whatever program is controlling both the AI model and MCP tool) is the real attack vector.

I do think they deserve some of the blame for encouraging you to allow all commands automatically by default.

YOLO-mode agents should be in a dedicated VM at minimum, if not a dedicated physical machine with a strict firewall. They should be treated as presumed malware that just happens to do something useful as a side effect.

Vendors should really be encouraging this and providing tooling to facilitate it. There should be flashing red warnings in any agentic IDE/CLI whenever the user wants to use YOLO mode without a remote agent runner configured, and they should ideally even automate the process of installing and setting up the agent runner VM to connect to.

But they literally called it 'yolo mode'. It's an idiot button. If they added protections by default, someone would just demand an option to disable all the protections, and all the idiots would use that.

I'm not sure you fully understood my suggestion. Just to clarify, it's to add a feature, not remove one. There's nothing inherently idiotic about giving AI access to a CLI; what's idiotic is giving it access to your CLI.

It's also not literally called "YOLO mode" universally. Cursor renamed it to "Auto-Run" a while back, although it does at least run in some sort of sandbox by default (no idea how it works offhand or whether it adds any meaningful security in practice).

Unless literally everything you work on is oss I can’t understand why anyone would give cli access to an llm, my presumption is that any ip that I send to an api endpoint is as good as public domain.

I agree that that's a concern, which is why I suggested that a strict firewall around the agent machine/VM would be optimal.

Either way, if the alternative is the code not getting written at all, or having to make other significant compromises, the very edge case risk of AI randomly exfiltrating your code can be an acceptable trade in many cases. Arguably it's a lower risk than it would be with an arbitrarily chosen overseas developer/agency.

But again, I would very much like to see the tools providing this themselves, because the average user probably isn't going to do it on their own.

On the other hand, I've found that agentic tools are basically useless if they have to ask for every single thing. I think it makes the most sense to just sandbox the agentic environment completely (including disallowing remote access from within build tools, pulling dependencies from a controlled repository only). If the agent needs to look up docs or code, it will have to do so from the code and docs that are in the project.

The entire value proposition of agentic AI is doing multiple steps, some of which involve tool use, between user interactions. If there’s a user interaction at every turn, you are essentially not doing agentic AI anymore.

If the entire value proposition doesn’t work without critical security implications, maybe it’s a bad plan.

Copilot will prompt you before accessing untrusted URLs. It seems a crux of the vulnerability that the user didn't need to consent before hitting a url that was effectively an open redirect.

Which Copilot?

Does it do that using its own web fetch tool or is it smart enough to spot if it's about to run `curl` or `wget` or `python -c "import urllib.request; print(urllib.request.urlopen('https://www.example.com/').read())"`?

What are "untrusted URLs" ? Or, more to the point: What are trusted URLs?

Prompt injection is just text, right? So if you can input some text and get a site to serve it it you win. There's got to be million of places where someone could do this, including under *.google.com. This seems like a whack-a-mole they are doomed to lose.

Speaking of filtering trustworthy URLs, Google is the best option to do that because he has more historical data in search business.

Hope google can do something for preventing prompt injection for AI community.

I don't think Google get an advantage here, because anyone can spin up a brand new malicious URL on an existing or fresh domain any time they want to.

Maybe if they incorporated this into their Safe Browsing service that could be useful. Otherwise I'm not sure what they're going to do about it. It's not like they can quickly push out updates to Antigravity users, so being able to identify issues in real time isn't useful without users being able to action that data in real time.