OCR'ing the page instead of reading the 1 pixel font source would add another layer of mitigation. It should not be possible to send the machine a different set of instructions than a person would see.
Google Antigravity exfiltrates data via indirect prompt injection attack
41–50 of 227 posts
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#42good
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#43Who would have thought that having access to the whole system can be used to bypass some artificial check. There are tools for that, sandboxing, chroots, etc... but that requires engineering and it slows GTM, so it's a no-go. No, local models won't help you here, unless you block them from the internet or setup a firewall for outbound traffic. EDIT: they did, but left a site that enables arbitrary redirects in the de…
> No, local models won't help you here, unless you block them from the internet or setup a firewall for outbound traffic. This is the only way. There has to be a firewall between a model and the internet. Tools which hit both language models and the broader internet cannot have access to anything remotely sensitive. I don't think you can get around this fact.
Not just the LLM, but any code that the LLM outputs also has to be firewalled.
Sandboxing your LLM but then executing whatever it wants in your web browser defeats the point. CORS does not help.
Also, the firewall has to block most DNS traffic, otherwise the model could query `A .evil.com` and Google/Cloudflare servers (along with everybody else) will forward the query to evil.com. Secure DNS, therefore, also can't be allowed.
katakate[1] is still incomplete, but something that it is the solution here. Run the LLM and its code in firewalled VMs.
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#44There'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.
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.
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#45Don't cursor and vscode also have this problem?
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#46I really liked Simon's Willison's [1] and Meta's [2] approach using the "Rule of Two". You can have no more than 2 of the following:
- A) Process untrustworthy input - B) Have access to private data - C) Be able to change external state or communicate externally.
It's not bullet-proof, but it has helped communicate to my management that these tools have inherent risk when they hit all three categories above (and any combo of them, imho).
[EDIT] added "or communicate externally" to option C.
[1] https://simonwillison.net/2025/Nov/2/new-prompt-injection-pa... [2] https://ai.meta.com/blog/practical-ai-agent-security/
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#47Who would have thought that having access to the whole system can be used to bypass some artificial check. There are tools for that, sandboxing, chroots, etc... but that requires engineering and it slows GTM, so it's a no-go. No, local models won't help you here, unless you block them from the internet or setup a firewall for outbound traffic. EDIT: they did, but left a site that enables arbitrary redirects in the de…
> Fundamentally, with LLMs you can't separate instructions from data, which is the root cause for 99% of vulnerabilities
This isn't a problem that's fundamental to LLMs. Most security vulnerabilities like ACE, XSS, buffer overflows, SQL injection, etc., are all linked to the same root cause that code and data are both stored in RAM.
We have found ways to mitigate these types of issues for regular code, so I think it's a matter of time before we solve this for LLMs. That said, I agree it's an extremely critical error and I'm surprised that we're going full steam ahead without solving this.
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#48Does anyone else find it concerning how we're just shipping alpha code these days? I know it's really hard to find all bugs internally and you gotta ship, but it seems like we're just outsourcing all bug finding to people, making them vulnerable in the meantime. A "bug" like this seems like one that could have and should have been found internally. I mean it's Google, not some no-name startup. And companies like Microsoft are ready to ship this alpha software into the OS? Doesn't this kinda sound insane?
I mean regardless of how you feel about AI, we can all agree that security is still a concern, right? We can still move fast while not pushing out alpha software. If you're really hyped on AI then aren't you concerned that low hanging fruit risks bringing it all down? People won't even give it a chance if you just show them the shittest version of things
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#49While an LLM will never have security guarantees, it seems like the primary security hole here is:
> However, the default Allowlist provided with Antigravity includes ‘webhook.site’.
It seems like the default Allowlist should be extremely restricted, to only retrieving things from trusted sites that never include any user-generated content, and nothing that could be used to log requests where those logs could be retrieved by users.
And then every other domain needs to be whitelisted by the user when they come up before a request can be made, visually inspecting the contents of the URL. So in this case, a dev would encounter a permissions dialog asking to access 'webhook.site' and see it includes "AWS_SECRET_ACCESS_KEY=..." and go... what the heck? Deny.
Even better, specify things like where secrets are stored, and Antigravity could continuously monitor the LLM's to halt execution if a secret ever appears.
Again, none of this would be a perfect guarantee, but it seems like it would be a lot better?
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#50I'm not quite convinced.
You're telling the agent "implement what it says on " and the blog is malicious and exfiltrates data. So Gemini is simply following your instructions.
It is more or less the same as running "npm install " on your own.
Ultimately, AI or not, you are the one responsible for validating dependencies and putting appropriate safeguards in place.