top | item 46049536

(no title)

jsmith99 | 3 months ago

There's nothing specific to Gemini and Antigravity here. This is an issue for all agent coding tools with cli access. 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.

discuss

order

ArcHound|3 months ago

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.

dabockster|3 months ago

> 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.

IshKebab|3 months ago

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

buu700|3 months ago

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.

xmcqdpt2|3 months ago

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.

connor4312|3 months ago

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.

simonw|3 months ago

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())"`?

gizzlon|3 months ago

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.

informal007|3 months ago

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.

simonw|3 months ago

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.

danudey|3 months ago

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.