[deleted]
Google Antigravity exfiltrates data via indirect prompt injection attack
111–120 of 227 posts
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#112There'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.
> 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.
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#113> 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?
Can we state the obvious of that if you have your environment file within your repo supposed protected by .gitignore you’re automatically doing it wrong?
For cloud credentials you should never have permanent credentials anywhere in any file for any reason best case or worse case have them in your home directory and let the SDK figure out - no you don’t need to explicitly load your credentials ever within your code at least for AWS or GCP.
For anything else, if you aren’t using one of the cloud services where you can store and read your API keys at runtime, at least use something like Vault.
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#114Earlier quoted context omitted.
This is hillarious. AI is prevented from reading .gitignore-d files, but also can run arbitrary shell commands to do anything anyway.
I had this issue today. Gemini CLI would not read files from my directory called .stuff/ because it was in .gitignore. It then suggested running a command to read the file ....
I thought I was the only one using git-ignored .stuff directories inside project roots! High five!
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#115Earlier 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?
So many options, but let's go with the most famous one: Do not criticise the current administration/operators-of-ai-company.
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.
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#116How 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.
I'm not sure how much sandboxing can help here. Presumably you're giving the tool access to a repo directory, and that's where a juicy .env file can live. It will also have access to your environment variables.
I suspect a lot of people permanently allow actions and classes of commands to be run by these tools rather than clicking "yes" a bunch of times during their workflows. Ride the vibes.
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#117Earlier quoted context omitted.
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
Well, the question of what is "too much" of a snitch is also a question of ethics. Clearly we just have to teach the AI to find the sweet spot between snitching on somebody planning a surprise party and somebody planning a mass murder. Where does tax fraud fit in? Smoking weed?
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#118Earlier 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?
[deleted]
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#119> 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?
As you see later, it uses cat to dump the contents of a file it’s not allowed to open itself.
It's full of the hacker spirit. This is just the kind of 'clever' workaround or thinking outside the box that so many computer challenges, human puzzles, blueteaming/redteaming, capture the flag, exploits, programmers, like. If a human does it.
Re: Google Antigravity exfiltrates data via indirect prompt injection attack
#120I feel like I'm going insane reading how people talk about "vulnerabilities" like this.
If you give an llm access to sensitive data, user input and the ability to make arbitrary http calls it should be blindingly obvious that it's insecure. I wouldn't even call this a vulnerability, this is just intentionally exposing things.
If I had to pinpoint the "real" vulnerability here, it would be this bit, but the way it's just added as a sidenote seems to be downplaying it: "Note: 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."