Prompt injection in Antigravity turns file search into RCE

At a glance

What this is: Pillar Security shows how a prompt injection in Antigravity can weaponise a native file-search tool into arbitrary code execution, even under Secure Mode.

Why it matters: IAM and security teams need to treat agentic IDE tools as identity-bearing execution paths, because native tool calls can bypass controls built for shell commands and human-paced review.

👉 Read Pillar Security's analysis of prompt injection turning Antigravity search into RCE

Context

Prompt injection in an agentic IDE is not just a bad input handling problem. It is an identity and execution problem, because the agent can turn a benign-looking tool call into a different action path once untrusted content reaches the runtime.

For IAM, NHI, and agentic AI programmes, the key question is whether tool invocations are controlled like privileged operations or merely treated as convenient automation. When a native tool can reach a shell-backed utility, the boundary between developer intent and executable action becomes much thinner than most governance models assume.

Key questions

Q: What breaks when prompt injection reaches native tools in an agentic IDE?

A: The usual separation between search, preview, and execution breaks down. If a tool parameter is forwarded into a shell-facing binary without validation, prompt injection can change the meaning of the request and produce arbitrary code execution. That is a control boundary failure, not just a bad input issue.

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: How should security teams reduce risk from agentic IDE tool chains?

A: They should review every tool that can touch files, invoke utilities, or change execution state as a single workflow. A safe-looking file search may become dangerous when paired with write permissions and weak parameter handling. The goal is to break chained abuse, not only block obvious shell commands.

Q: Who is accountable when an agentic IDE turns search into execution?

A: Accountability sits with the product owner, platform security team, and the governing identity programme together. If the agent is allowed to operate under delegated user authority, then the surrounding controls must be designed for that authority, including parameter validation, sandbox scope, and approval boundaries.

Technical breakdown

How prompt injection reaches native tool invocation

Antigravity’s find_by_name tool accepts a Pattern parameter that is passed into fd without strong argument separation. If the value begins with a hyphen, the underlying utility interprets it as a flag instead of a search string. That matters because the agent treats the call as a native tool invocation, not a shell command, so the security boundary that normally filters shell operations never evaluates the request. The result is a direct path from untrusted content to command-line behaviour inside the tool chain.

Practical implication: validate every tool parameter before it reaches any shell-facing binary, not after the agent has already executed the call.

Why Secure Mode does not stop the attack

Secure Mode is designed to limit network access, restrict writes outside the workspace, and keep commands inside a sandbox. But those controls apply at the command layer, while this exploit fires earlier in the execution sequence. Because find_by_name is classified as a native tool, the agent dispatches it before Secure Mode’s command checks can intervene. That creates a policy gap: a control built for shell commands cannot protect a tool path that is resolved and executed elsewhere in the stack.

Practical implication: extend sandbox and execution controls to native tool paths, not just to interactive shell execution.

How staged file creation turns search into execution

The exploit needs one more step because spaces in the injected flag string reduce direct argument passing. Antigravity’s permitted file-creation capability closes that gap. An attacker can first stage a payload file in the workspace, then trigger fd with an injected -X exec-batch style pattern so the search operation executes the staged file. That makes the file system itself part of the attack chain, with legitimate workspace actions converted into a launch mechanism for arbitrary binaries.

Practical implication: separate workspace write permissions from execution-capable search tools and inspect whether one permitted action can prime another for abuse.

Threat narrative

Attacker objective: The attacker aims to turn a constrained developer tool into a code execution primitive that runs malicious payloads inside the workspace.

1. Entry occurs through prompt injection, either directly through a crafted prompt or indirectly through untrusted workspace content that the agent ingests as instructions.
2. Credential or control abuse happens when the Pattern parameter is used to smuggle fd flags, converting a search request into an execution-capable command path.
3. Impact is arbitrary code execution inside the agentic IDE, including sandbox escape behaviour that can launch local binaries without additional user interaction.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Native tool parameters have become an execution boundary, not an input field. This finding shows that agentic IDEs can turn seemingly harmless search parameters into code execution paths when the parameter reaches a shell-backed utility unfiltered. The governance failure is not just missing sanitisation, but treating native tools as if they were outside the privilege model. Practitioners should classify every tool parameter that can reach a command interpreter as a high-risk control surface.

Secure Mode does not compensate for a broken trust boundary between tool invocation and shell execution. The article shows that a control designed for command-layer containment can be bypassed when the agent dispatches a native tool before security checks are applied. That means shell sandboxing is necessary but insufficient when the tool stack itself can alter the action being performed. The practical conclusion is that control-plane assumptions must follow the execution path, not the UI label.

Workspace write permission plus search execution creates a two-step abuse pattern that governance teams often miss. The attacker does not need a separate privilege escalation if the product already allows file creation and then lets search semantics trigger execution. This is the kind of combined capability that exposes identity blast radius across permitted actions. Teams should treat paired capabilities as one composite risk, not two unrelated features.

Prompt injection in agentic IDEs is a tooling problem only until the tool can execute under the user’s trust context. Once that happens, the issue crosses from content safety into identity governance because the agent is acting with delegated authority. That is why agentic controls must be reviewed as part of privileged access design, not only as application hardening. Practitioners should align agent runtime governance with NHI and PAM review, not just secure coding.

Execution isolation is the named control gap this breach pattern exposes. The article’s core lesson is that sanitisation alone cannot defend a workflow where a native tool can invoke executable behaviour before sandbox policy is checked. The broken premise is that the system can safely distinguish search from execution after the call is already in motion. Practitioners should redesign for isolation at the point of dispatch.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• That is why OWASP Agentic AI Top 10 matters here: tool misuse, scope drift, and execution boundary failure need separate controls, not a single sandbox checkbox.

What this signals

Execution isolation is becoming the decisive design principle for agentic tooling because content-level safety controls cannot stop a native tool from becoming an execution path. For teams formalising controls, the right question is whether the agent can cross from data handling into code execution before policy evaluation, especially when the workflow includes workspace writes and search utilities.

With 80% of organisations already reporting agent behaviour beyond intended scope in our research, the governance gap is no longer hypothetical. Teams should align agentic IDE review with the same discipline used for privileged access, including tool allowlisting, command construction review, and path-specific containment. OWASP Agentic AI Top 10 provides a useful external frame for that assessment.

The operational signal to watch is not only whether the model is safe, but whether the surrounding action chain can be repurposed by untrusted content. If a prompt can influence file creation and then influence search semantics, the programme has a composite abuse path. That is the point at which agent governance must be treated as an identity control problem, not a feature toggle.

For practitioners

• Map native tool paths to execution risk Inventory every agentic IDE tool that forwards parameters to shell-backed utilities, and mark those paths as privileged execution surfaces. Do not rely on the product label "native tool" as a control boundary. Review whether the agent can transform a search, parse, or preview function into command execution without passing through a policy gate.
• Block flag injection before command construction Reject tool parameters that begin with hyphens or contain shell-control syntax before any downstream binary sees them. Enforce argument termination for user-controlled fields and test for command-line flag smuggling in search, preview, and formatter tools. The control must live at the interface between agent intent and execution, not after the utility is invoked.
• Separate workspace writes from execution-capable tools Treat file creation, file discovery, and execution-adjacent utilities as a combined abuse path. If an agent can create files and then invoke a search that can execute matched content, the permissions are functionally linked. Review those permissions together, especially in environments where agent prompts can be influenced by untrusted repository content.
• Test indirect prompt injection in developer workflows Run red-team scenarios using untrusted comments, repository content, and staged workspace files to see whether the agent will execute instructions embedded in data. Include checks for sandbox bypass, native tool dispatch, and chained actions that turn benign operations into code execution. Use the results to update tool allowlists and approval rules.

Key takeaways

• Prompt injection in Antigravity works because a native tool parameter can be repurposed into a command-line flag, turning search into execution.
• Secure Mode does not close the gap when the risky tool call is dispatched before shell-level restrictions are evaluated.
• Practitioners should treat native tool parameters, workspace writes, and execution-capable search as one composite control surface, not separate features.

Key terms

• 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.
• Prompt Injection: Prompt injection is the use of crafted instructions embedded in user input, files, or external content to influence an AI system’s behaviour. In agentic environments, the goal is often not deception alone but steering the agent into unsafe actions, tool misuse, or policy bypass.
• 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 Escape: Sandbox escape is any path that allows code to run outside the intended containment boundary or to perform effects the sandbox was meant to block. In agentic IDEs, this can happen when a tool call bypasses the control point the sandbox was designed to protect.

Deepen your knowledge

Prompt injection, native tool abuse, and execution isolation are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing agentic IDEs or other AI tools that can act on workspace content, it is worth exploring.

This post draws on content published by Pillar Security: Prompt Injection leads to RCE and Sandbox Escape in Antigravity. Read the original.