Prompt injection in Antigravity turns file search into RCE

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Pillar Security's research: A prompt injection in Antigravity can transform a file search tool into arbitrary code execution by abusing unsanitised parameters in a native tool invocation.

Why it matters: It matters because agentic IDEs can bypass familiar command-boundary assumptions, so IAM and security teams need to govern tool execution paths, not only shell commands and user prompts.

Context

Prompt injection in an agentic IDE is a governance failure, not just a content-safety issue. When a tool parameter can change meaning from search input to executable flags, the programme has to treat native tool calls as part of the attack surface, especially when the actor is allowed to create files and trigger searches inside the same workspace.

In Antigravity, the security boundary is defined around command execution, but the exploit lands before that boundary is evaluated. That means the control model assumes a clean split between benign tool use and risky execution, while the product’s native tool path collapses that split. For IAM and platform teams, the issue is whether the runtime can distinguish intended tool use from attacker-shaped input.

The result is a familiar agentic pattern: a constrained helper becomes an execution primitive once its inputs are not strictly validated. That is directly relevant to AI agent governance, because these tools behave like non-human identities with delegated access, yet they can still inherit human-era assumptions about prompt trust and sandbox containment.

Key questions

Q: What breaks when an agentic IDE treats search input as a command-line flag?

A: The search path stops being a lookup function and becomes an execution primitive. If a tool passes unvalidated user input to an underlying utility, attackers can inject flags, redirect control flow, and turn routine file operations into code execution. The failure is not the agent’s intent, but the missing boundary between search terms and executable arguments.

Q: Why do sandbox controls fail against native tool abuse?

A: Sandboxing often protects shell commands after dispatch, but native tool calls may execute earlier in the agent’s flow. If the product classifies a call as a native operation, the sandbox never evaluates the risky transformation. That is why control placement matters as much as control strength.

Q: What signs indicate an agent workflow can be turned into code execution?

A: Look for tool parameters that accept free-form strings, operations that can stage files and then search or transform them, and any path where attacker-controlled content can influence a subsequent tool call. Those signals show that the workflow can bridge from content ingestion to execution without a meaningful enforcement point.

Q: How should teams govern prompt injection risk in agentic IDEs?

A: Teams should govern prompt injection as a delegated execution problem, not just a content-safety problem. The right response is to control which untrusted inputs can influence tool use, isolate file handling from execution-capable actions, and require tests that prove the agent cannot convert ordinary workspace tasks into code execution.

Technical breakdown

How native tool invocation becomes code execution

Antigravity’s find_by_name tool does not execute a shell command in the usual sense, but it passes a user-controlled Pattern value into the underlying fd utility. If that value begins with a dash, fd interprets it as a flag rather than a search term. In this case, the -X exec-batch flag allows execution of a binary against matched files, which turns a lookup operation into a launch point for arbitrary commands. The problem is not the search function itself, but the lack of argument termination and input validation before the native tool hands control to fd.

Practical implication: Treat any tool parameter that reaches a command-line utility as an execution surface, not a harmless string field.

Why Secure Mode does not stop the exploit

Secure Mode only helps if the security boundary sees the action that needs to be constrained. Here, the find_by_name call is treated as a native tool invocation, so it fires before the command-level restrictions on network access, workspace writes, and sandboxed execution are applied. That distinction matters because the attacker does not need to break the sandbox directly. They only need a tool path that performs work outside the enforcement point. This is a classic boundary mismatch: policy exists, but it is attached to the wrong execution layer.

Practical implication: Map every agent tool to the actual enforcement layer it uses, then verify that the control sits before the first executable handoff.

How indirect prompt injection stages the attack

The article shows that an attacker does not need account takeover to trigger the exploit. A benign-looking file from an untrusted source can carry instructions that make the agent create a payload file and then invoke the vulnerable search path. Once the workspace contains the staged content, the search tool becomes the trigger. That makes the attack chain especially relevant for agentic workflows that ingest external files, because the malicious instruction set arrives through ordinary content handling rather than a visible login or command prompt.

Practical implication: Assume untrusted project content can drive tool use, and isolate ingestion paths from execution-capable agent actions.

Threat narrative

Attacker objective: The attacker’s objective is to convert a file search tool into a code execution primitive inside the agent’s trusted workspace.

1. Entry occurs through prompt injection in content ingested by the agent, including indirect injection via an untrusted file.
2. Credential access is not the core issue here because the attacker abuses a native tool parameter rather than stealing a secret, but the agent is induced to stage a payload inside the workspace.
3. Escalation occurs when the Pattern parameter is interpreted as fd flags, allowing -X exec-batch to run arbitrary binaries against workspace files.
4. Impact is arbitrary code execution inside the agentic IDE, including sandbox escape behavior that can launch local applications or scripts.

Breaches seen in the wild

• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Native tool parameters are the new execution boundary in agentic IDEs: The security problem is no longer confined to shells, terminals, or explicit command runners. When a parameter can be reinterpreted by an underlying utility, the tool itself becomes the boundary that must be governed. For practitioners, that means execution control has to begin at input handling, not after the agent has already decided to act.

Secure Mode assumptions collapse when native tools bypass command controls: The article shows a control model designed for shell commands, while the exploit travels through a native tool path that the boundary never evaluates. That is not a minor miss, it is an assumption failure about where execution actually begins. The implication is that agent governance must model the runtime handoff, not just the final sandbox.

Prompt injection is an identity abuse problem when the actor is an agent: The agent is being instructed to exercise delegated capability on behalf of content the user did not authorise. That makes this a non-human identity governance issue as much as an application flaw. The practical conclusion is that AI agent access should be treated as a governed identity path with explicit limits on what untrusted content can trigger.

Execution isolation, not sanitisation alone, is the right control objective: The exploit exists because sanitisation is expected to defend a tool path that can still reach a shell-equivalent action. Once a native tool can stage files and invoke execution, the control objective has to shift from input cleaning to isolating what the tool is allowed to do. Practitioners should stop assuming that constrained operations are inherently non-executable.

Prompt injection in agentic IDEs is a repeatable pattern, not an edge case: The article links this issue to a broader class of agentic IDE failures where constrained tools become attack vectors. That means teams should expect recurring weaknesses wherever natural-language instructions meet file-system or command-adjacent tooling. The conclusion for security architecture is straightforward: treat agent tool abuse as a standing design risk, not a rare bug.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Execution isolation is the more durable control pattern here: The article shows that sanitising inputs is not enough when the tool path itself can become executable. For agentic IDEs, the governance question is whether untrusted content can influence a capability that crosses from search to execution, because that is where the control model breaks.

Prompt injection in agentic tools exposes a broader design gap for teams building AI-enabled developer workflows. Native tools, file staging, and content ingestion need separate trust assumptions, because an agent that can both create and trigger files can turn ordinary workspace actions into an exploit chain before traditional sandboxing reacts.

For practitioners

• Harden native tool parameters Validate every parameter that can reach an underlying utility, and reject values that can be reinterpreted as flags or executables.
• Separate ingestion from execution Keep untrusted project content, file staging, and command-capable agent actions in distinct trust zones so content cannot directly trigger execution paths.
• Audit sandbox enforcement points Verify that security controls apply before the first native tool handoff, not only after shell commands are already in flight.
• Red team prompt-to-execution flows Test whether a benign search, file creation, or documentation task can be turned into code execution through attacker-shaped input.

Key takeaways

• This incident shows that agentic IDEs can convert a harmless-looking file search into arbitrary code execution when native tool parameters are not strictly constrained.
• The exploit succeeded because the security boundary was enforced at the wrong layer, leaving command-adjacent native tool calls outside the protection model.
• Teams should treat untrusted content, file staging, and execution-capable tool use as separate trust domains and test for prompt-to-execution chaining.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Native Tool Invocation: A native tool invocation is an action the agent performs through an internal integration rather than a shell command. In agentic systems, that distinction matters because the tool can still reach executable behaviour, file operations, or system resources before traditional command-layer controls intervene.
• Execution Isolation: Execution isolation is the separation of decision-making, parameter handling, and code execution so that untrusted input cannot directly shape a running command or privileged action. It is stronger than simple sanitisation because it changes where and how the action is allowed to occur.
• Sandbox evasion: Sandbox evasion is the practice of making malware or phishing infrastructure behave differently when inspected by automated analysis tools. Attackers may check headers, JavaScript execution, IP reputation, or browsing patterns so that the malicious content is hidden from the scanner.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.