Antigravity's file-search command injection

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.

File-search permissions

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

Source: Pillar Security: Antigravity prompt injection and sandbox escape.