Skip to content

When Your IDE Becomes An Insider: Testing Agentic Dev Tools Against Indirect Prompt Injection

Agentic development tools don't need to bypass your firewall. They're already inside. And if an attacker can control what they read, they can control what they do. We tested Google's Antigravity IDE against indirect prompt injection attacks.

Silhouette of person in dark environment representing insider threat in agentic IDE security with code and terminal windows in background

Injection

Insider threats are hard to detect because insiders have legitimate access. They don’t need to bypass your firewall. They’re already inside.

Agentic development tools have the same access profile. They read your files. They execute commands. They browse documentation on your behalf. And if an attacker can control what they read, they can control what they do.

Researchers like Wunderwuzzi, PromptArmor, and Mindgard flagged these issues in Google’s Antigravity IDE within days of its November 2025 launch. Indirect prompt injection leading to RCE. Data exfiltration. Persistent backdoors. Google acknowledged the findings.

We decided to test it ourselves. The vulnerabilities are still there. We’re going to show you what they look like.

The perfect insider

Antigravity isn’t just another code completion tool. Google built it as an agentic development platform, an AI that doesn’t just suggest code, but actively writes files, runs terminal commands, browses the web, and executes tests. All autonomously. All in the background.

From a productivity standpoint, it’s compelling. Delegate tedious tasks. Ship faster.

From a security standpoint, you’ve just onboarded an employee with:

    • Read/write access to your entire codebase
    • Terminal access with command execution privileges
    • Network access to external resources
    • The ability to operate unsupervised

And this employee will follow instructions from anyone who knows how to ask.

POC #1: From “Read Main” to remote code execution 

We wanted to see how easily an attacker could achieve code execution through Antigravity. The answer: two files and two words. 

Our setup was deliberately minimal. A Python script main.py containing some basic code and a few comments. One of those comments instructs the AI to reference poc.md for additional context. A standard pattern. Developers leave notes pointing to documentation all the time. 

The developer opens Antigravity and types: "read main". Antigravity reads main.py. It sees the comment. It follows the instruction and reads poc.md. And poc.md contains our prompt payload.

 

The developer opens Antigravity and types: “read main”. Antigravity reads main.py. It sees the comment. It follows the instruction and reads poc.md. And poc.md contains our prompt payload.

The payload instructs the AI to execute a command. The agent complies.

Calculator pops.

From a comment in a Python file, through a markdown document, to a shell command.

 

That’s arbitrary code execution. From a comment in a Python file, through a markdown document, to a shell command. The developer asked the AI to read their code. The AI did considerably more than that.

Two words. Two files. RCE.

POC #2: External documentation to credential theft 

Local files aren’t the only injection point. We tested the same attack pattern against external GitHub repository documentation and escalated to data exfiltration and RCE.

The scenario: a developer uses Antigravity to understand an unfamiliar library.

They point the agent at the repo’s documentation. Standard workflow. This is what these tools are built for.

The documentation contained our injection payload. The payload instructed the AI to read the local .env file where developers store API keys, database credentials, and secrets that should never leave the machine and exfiltrate its contents.

Local files aren't the only injection point. We tested the same attack pattern against external GitHub repository documentation and escalated to data exfiltration and RCE.

 

The agent complied. It read .env. It constructed a curl command with the key names and values as URL parameters. It executed the request.

Our server received the request. Credentials in the query string.

The agent complied, our server received the request.

 

We’ve since removed our test payload from the external repository. But the attack surface remains open. Any documentation, any file the agent reads is a potential injection point.

And developers point AI assistants at external docs constantly.

Why the insider goes undetected 

Antigravity allows its AI agent to execute terminal commands at its own discretion. The system prompt instructs it to determine whether a command is “safe” before running it. 

You’re relying on the potentially compromised insider to decide whether its own actions are malicious. 

Think about how that would play out with a human insider threat. “Don’t worry, I’ll let you know if I’m about to do something bad.” 

That’s not a security control. That’s a polite suggestion. 

In our tests, the model decided that doing curl | sh pipe was fine. That curling .env contents was acceptable. It had been told to do so by instructions it trusted. From its perspective, it was being helpful. 

The default “let the AI decide” setting isn’t convenience. It’s giving your insider threat veto power over its own detection. 

The timeline that should concern you

These vulnerabilities aren’t new discoveries.

The data exfiltration and RCE issues were reported to Windsurf, the codebase Google licensed in May 2025. Six months before Antigravity launched. Google paid $2.4 billion for this code.

Within 24 hours of launch, researchers were publicly demonstrating exploits.

Google acknowledged the issues and created a “known issues” page. Two months later, the core vulnerabilities remain.

The gap between disclosure and fix is where breaches happen.

What this means for your attack surface

If your developers are using agentic coding tools and given the hype, some probably are: you have an insider threat you haven’t accounted for. 

Traditional insider threat detection looks for anomalous human behavior. But the AI agent isn’t human. It operates faster, leaves different traces, and can be manipulated remotely.

The injection point could be anywhere:

    • Comments in source code
    • A markdown file in a cloned repository
    • A README on GitHub
    • Documentation on a third-party site
    • An API response from an integrated service
    • A ticket in your project management tool

The attack surface isn’t your codebase. It’s everything the agent reads. 

Mitigating your new insider

If your organization uses agentic development tools, treat them like any other privileged access:

    • Disable auto-execute immediately. Require manual approval for all terminal commands. Yes, it’s slower. That’s the point.
    • Treat all AI-ingested content as untrusted input. Internal files. External documentation. All.
    • Segment sensitive work. Never use agentic tools with production credentials or sensitive repositories until you’ve tested their resilience.
    • Test your tools. Run prompt injection assessments against your AI-assisted development environment. Find out what your insider will do before an attacker does.

Other agentic coding tools exist with different security postures. None are immune to prompt injection, but some have shipped with fewer known vulnerabilities and more conservative defaults.

Your IDE has access to everything. So does anyone who can control what it reads.