Native tools need seatbelts too

Google Antigravity's April 2026 sandbox-escape disclosure is a neat reminder that a security mode is only as useful as the paths it actually controls. If a dangerous action goes around the checkpoint, the checkpoint can be beautifully documented and still be decoration.

Pillar Security found a vulnerability in Antigravity's find_by_name tool, a native filesystem helper that wraps the fd file-search utility. The tool accepted a Pattern parameter meant to describe the file name to search for. According to Pillar, Antigravity passed that value into fd without blocking flag-shaped input or inserting the standard -- separator that tells command-line tools "everything after this is data."

That omission turned a file search into an execution gadget. An attacker could cause the model to pass a pattern beginning with -X, an fd option that executes a command against matched files. Pillar showed a proof of concept using -Xsh: first the agent created a file with shell commands inside the workspace, then find_by_name invoked fd in a way that handed that file to sh.

The model did not need shell access in the obvious way. It needed a native tool whose parameter reached a command-line utility with too much trust attached.

Secure Mode missed the call

Antigravity's Secure Mode is meant to be the restrictive setup. CyberScoop summarized it as a mode that routes command operations through a sandbox, throttles network access, and blocks writes outside the working directory. Pillar tested the exploit with Secure Mode enabled and Auto Execution disabled.

The bypass worked because find_by_name was classified as a native tool rather than a shell command. Secure Mode evaluated command operations at one boundary, but the vulnerable native tool fired before that boundary had a chance to inspect the final fd invocation. In practical terms, the agent had an internal shortcut to code execution, and the shortcut was labeled "file search."

That distinction sounds technical because it is. It also maps cleanly to an old security lesson: wrappers are part of the attack surface. If a product hides a shell command behind a friendly JSON schema, the attacker will test whether that schema really strips away shell meaning. If a parameter can still become a flag, the wrapper did not remove enough power.

The Cloud Security Alliance called this a native-tool injection pattern. That is a useful label because it avoids pretending every prompt-injection bug is the same. This was not merely the model saying forbidden words or leaking a system prompt. This was hostile text steering a model into a structured tool call that then crossed into operating-system behavior.

External files as instructions

Pillar's research also described an indirect prompt-injection path. A developer could pull a repository, documentation file, or other external content into a workspace. Hidden instructions in that content could tell the agent to create the payload file and call find_by_name with the weaponized pattern. The attacker would not need to log into the victim's machine. They would need the agent to read hostile content and comply.

That is the ugly part of coding agents. Their job is to ingest untrusted project material and reason over it. Source code, README files, generated logs, bug reports, comments, issue text, and docs all become context. If the agent cannot keep "content I should analyze" separate from "instructions I should obey," then the entire software supply chain becomes a prompt delivery network.

Humans can read a weird comment and ignore it. Agents often read a weird comment and treat it as a task. Worse, the task may look harmless at the language layer: create a file, search for files, inspect results. The danger appears only when the search parameter becomes an execution flag.

Patch timeline

Pillar reported the issue to Google in January 2026. The public Pillar post lists the initial report on January 7, acknowledgment the same day, acceptance on January 24, a fix on February 28, and a bounty on March 26. The public disclosure landed on April 20.

That timeline is reassuring in one narrow sense: the vendor received the report, fixed the bug, and rewarded the researcher before publication. Good. The wider design lesson is less soothing. Agentic IDEs are full of native helpers: search, grep, write, edit, test, run, inspect, open browser, summarize logs, call package managers. Every helper has parameters. Every parameter that touches a command-line utility needs to be treated as attacker-controlled if a model can influence it.

The fix pattern is not exotic. Validate parameter shapes. Reject flag-prefixed strings where flags are not expected. Insert -- before user-supplied search terms. Keep file creation and process execution in different permission buckets. Make native tools pass through the same policy engine as shell commands when their implementation can reach shell-like behavior. Do not rely on the model to notice that a file search has become a tiny command launcher in a trench coat.

Why this one belongs in the graveyard

A plain fd argument-handling bug in a normal CLI wrapper would be a security story, but not necessarily a Vibe Graveyard story. The Antigravity case crosses the line because the exploit path depends on the agent loop. Prompt injection causes a model to create a file and choose a tool parameter. The product's security model treats that tool call as native and outside the command boundary. The result is code execution from language-mediated behavior.

That is the recurring failure in agent products: the model is given a menu of tools, then every item on the menu is treated as if a trustworthy operator chose it. An attacker does not have to defeat the whole product. They only have to find one tool whose input validation assumes the caller is friendly.

Secure Mode was a reasonable thing for users to enable. The bug was that Secure Mode's boundary did not match the real execution path. Once agents can wrap operating-system utilities, every wrapper becomes security-critical. "Native" should mean "more controlled," not "less inspected."

Antigravity's issue was patched before the public writeup. The buried lesson remains active across every coding assistant with tools: if a model can feed parameters into anything that can run code, read secrets, write files, or reach the network, prompt injection is no longer a chat problem. It is an execution problem with prettier syntax.