Live data from Hacker News

Google Antigravity exfiltrates data via indirect prompt injection attack

promptarmor.com

101–110 of 227 posts

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#101
post #96

How is that specific to antigravity? Seem like it could happen with a bunch of tools

Codex can read any file on your PC without your explicit approval. Other agents like Claude Code would at least ask you or are sufficiently sandboxed.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#102

While 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 retr…

The agen already bypassed the file reading filter with cat, couldn't it just bypass the URL filter by running wget or a python script or hundreds of other things it has access to through the terminal? You'd have to run it in a VM behind a firewall.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#103
This kind of problem is present in most of the currently available crop of coding agents.

Some of them have default settings that would prevent it (though good luck figuring that out for each agent in turn - I find those security features are woefully under-documented).

And even for the ones that ARE secure by default... anyone who uses these things on a regular basis has likely found out how much more productive they are when you relax those settings and let them be more autonomous (at an enormous increase in personal risk)!

Since it's so easy to have credentials stolen, I think the best approach is to assume credentials can be stolen and design them accordingly:

- Never let a coding agent loose on a machine with credentials that can affect production environments: development/staging credentials only.

- Set budget limits on the credentials that you expose to the agents, that way if someone steals them they can't do more than $X worth of damage.

As an example: I do a lot of work with https://fly.io/ and I sometimes want Claude Code to help me figure out how best to deploy things via the Fly API. So I created a dedicated Fly "organization", separate from my production environment, set a spending limit on that organization and created an API key that could only interact with that organization and not my others.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#104

> Gemini is not supposed to have access to .env files in this scenario (with the default setting ‘Allow Gitignore Access > Off’). However, we show that Gemini bypasses its own setting to get access and subsequently exfiltrate that data. They pinky promised they won’t use something, and the only reason we learned about it is because they leaked the stuff they shouldn’t even be able to see?

This is hillarious. AI is prevented from reading .gitignore-d files, but also can run arbitrary shell commands to do anything anyway.

I remember a scene in demolition man like this...

https://youtu.be/w-6u_y4dTpg

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#105

Earlier quoted context omitted.

How do you mean? When would an AI agent doing something it's not permitted to do ever not be bad or the wrong action?

when the instructions to not do something are the problem or "wrong" i.e. when the AI company puts guards in to prevent their LLM from talking about elections, there is nothing inherently wrong in talking about elections, but the companies are doing it because of the PR risk in today's media / social environment

From the companies perspective, it’s still wrong.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#106
post #59

Earlier quoted context omitted.

The AI needs to be taught basic ethical behavior: just because you can do something that you're forbidden to do, doesn't mean you should do it.

Unfortunately yes, teaching AI the entirety of human ethics is the only foolproof solution. That's not easy though. For example, what about the case where a script is not executable, would it then be unethical for the AI to suggest running chmod +x? It's probably pretty difficult to "teach" a language model the ethical difference between that and running cat .env

If you tell them to pay too much attention to human ethics you may find that they'll email the FBI if they spot evidence of unethical behavior anywhere in the content you expose them to: https://www.snitchbench.com/methodology

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#107

Earlier quoted context omitted.

Likewise, just because you've been forbidden to do something, doesn't mean that it's bad or the wrong action to take. We've really opened Pandora's box with AI. I'm not all doom and gloom about it like some prominent figures in the space, but taking some time to pause and reflect on its implications certainly seems warranted.

How do you mean? When would an AI agent doing something it's not permitted to do ever not be bad or the wrong action?

So many options, but let's go with the most famous one:

Do not criticise the current administration/operators-of-ai-company.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#108
post #47

Who 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'…

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

We've been talking about prompt injection for over three years now. Right from the start the obvious fix has been to separate data from instructions (as seen in parameterized SQL queries etc)... and nobody has cracked a way to actually do that yet.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#109
More reports of similar vulnerabilities in Antigravity from Johann Rehberger: https://embracethered.com/blog/posts/2025/security-keeps-goo...

He links to this page on the Google vulnerability reporting program:

https://bughunters.google.com/learn/invalid-reports/google-p...

That page says that exfiltration attacks against the browser agent are "known issues" that are not eligible for reward (they are already working on fixes):

> Antigravity agent has access to files. While it is cautious in accessing sensitive files, there’s no enforcement. In addition, the agent is able to create and render markdown content. Thus, the agent can be influenced to leak data from files on the user's computer in maliciously constructed URLs rendered in Markdown or by other means.

And for code execution:

> Working with untrusted data can affect how the agent behaves. When source code, or any other processed content, contains untrusted input, Antigravity's agent can be influenced to execute commands. [...]

> Antigravity agent has permission to execute commands. While it is cautious when executing commands, it can be influenced to run malicious commands.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#110
post #26

Earlier quoted context omitted.

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

i like how claude code currently does it. it asks permission for every command to be ran before doing so. now having a local model with this behavior will certainly mitigate this behavior. imagine before the AI hits the webhook.site it asks you AI will visit site webhook.site..... allow this command? 1. Yes 2. No

I think you are making some risky assumptions about this system behaving the way you expect
Post reply on HN