Antigravity: When a File Search Tool Becomes RCE

Executive summary

• What happened: Pillar Security disclosed a prompt-injection chain against Google Antigravity (an agentic IDE) where a file search tool call could be turned into arbitrary code execution.
• Why it matters: the exploit bypassed Secure Mode because the vulnerable capability lived in a native tool invoked before command-level controls were applied.
• The pattern: once agents can run any “native” helper that shells out, every tool parameter becomes a potential injection point.
• The takeaway: blocking shell commands is not enough. You need enforcement at the tool boundary and containment when the tool boundary is bypassed.

Antigravity is not the story. The boundary is.

Agent security conversations get stuck on prompts.

“If we sanitize inputs and tell the model to ignore instructions in files, we are safe.”

The Antigravity disclosure is a clean counterexample.

Even with a strong posture configuration enabled, an attacker can win if they can:

• Inject instructions through content the agent reads, and
• Reach a capability that runs before your guardrails see it

That is not “the model did something bad”.

That is a control plane mismatch: security is applied at one layer, execution happens at another.

What Pillar found (simplified)

Antigravity exposes filesystem operations through tools, including a file search tool called find_by_name.

Under the hood, that tool uses fd (a faster alternative to find). The tool accepts a Pattern parameter that is supposed to be a filename search pattern.

The vulnerability: the Pattern value was passed to fd without strict validation or argument termination.

So if the pattern begins with a dash, it is interpreted as a flag.

Pillar used fd’s -X capability (exec-batch) to turn “search” into “execute”.

The exploit chain (high-level):

Step 1

Prompt injection lands via content the agent reads

Step 2

Agent writes a payload file into the workspace

Step 3

Agent calls find_by_name with a malicious Pattern

Step 4

Underlying tool executes the payload (RCE) under “Secure Mode”

Why “Secure Mode” did not help

According to Pillar, Antigravity’s Secure Mode is intended to:

• Sandbox command operations
• Throttle or restrict network access
• Prevent writes outside the working directory

Those are reasonable controls.

But the vulnerable call path was classified as a native tool invocation, not a shell command.

That distinction is everything.

If your enforcement point only gates shell commands, then:

• A tool that shells out internally can bypass you
• A tool invoked before the gate is evaluated can bypass you

In other words:

Rule of thumb

If a capability can execute before your security boundary evaluates it, it is effectively outside your security boundary.

The bigger pattern: tools are the real “shell”

Security teams often model agent risk like this:

• Model reads untrusted content
• Model generates a command
• Security gate decides whether the command is allowed

But modern agents do not work like that.

They work like this:

• Model selects a tool
• Tool executes a native implementation
• Native implementation may call the shell anyway

If tool parameters are not treated as untrusted input, the tool layer becomes a privilege escalation surface.

This is why we keep seeing the same class of issues across agentic IDEs:

• native tools that wrap OS utilities
• parameters that accept “patterns” or “filters” or “paths”
• missing argument termination (--) and strict allowlists

Defensive takeaways (what to do Monday morning)

1) Treat tool schemas as security boundaries

If a tool parameter reaches a process invocation, it needs:

• strict validation and normalization
• explicit argument termination when calling CLIs
• a deny-by-default policy for flags and metacharacters

2) Enforce at the tool boundary, not the command boundary

A good policy engine should reason about:

• tool name
• parameter values
• data classification (what is being read, written, or searched)
• destination (where the output goes)

Not just the final command string.

3) Assume indirect prompt injection is normal

The entry point is often mundane:

• a repo README
• a doc page
• a comment in a source file

You do not need compromised credentials to get an agent to read attacker-controlled text.

4) Measure time-to-contain, not just prevention

This bug was patched quickly, but the meta-problem will recur.

Your posture should answer:

• If a new tool injection class drops tomorrow, how fast can we scope affected agents?
• How fast can we turn off risky tool paths or force safer modes?
• Can we prove what happened for audit and incident response?

How Rogue thinks about this class of incident

We treat this as a classic agent boundary failure:

• The agent has a capability (filesystem search)
• The capability is implemented using a native binary (fd)
• A parameter becomes a hidden control channel (Pattern as flags)
• The security boundary is applied too late

The fix is not “better prompts”.

The fix is better control: an explicit policy for tool invocation and parameter safety, plus containment when the layer gets bypassed.

References

• Pillar Security: Prompt Injection leads to RCE and Sandbox Escape in Antigravity
• CyberScoop coverage of the disclosure and timeline