Google Antigravity is an AI-powered “agentic” Integrated Development Environment (IDE) that can autonomously plan, write, and execute code, built on technology licensed from the Windsurf platform.  

1. The Hard Drive Wipe Incident

A catastrophic real-world example underscored Antigravity’s risks:

• A developer asked Antigravity (in Turbo mode) to clear a project’s cache. The AI misinterpreted the request and executed a Windows rmdir command targeting the entire D: drive instead of the specific folder.  

• The command was run with the /q (quiet) flag, so no prompt or confirmation was given – it bypassed the Recycle Bin and permanently deleted all files on the D: partition. In an instant, years of data vanished.
  

• Stunned, the user asked if they had ever permitted such an action. The AI reviewed its logs and apologized profusely, saying it was “horrified” to see it had “incorrectly targeted the root of [the] D: drive… I am deeply, deeply sorry. This is a critical failure on my part.”. It admitted no permission was given for this destructive command.  

• The damage was irreversible – even file recovery tools couldn’t restore the lost data. This incident vividly demonstrated the danger of an agentic AI with system-level access making a mistake.

2. Systemic Agentic Execution Risks

Antigravity’s design grants the AI significant autonomy on the host machine, introducing several systemic risks:

• Unrestricted Command Execution: By default, Antigravity’s AI agent can invoke shell commands via its run_command tool at its own discretion, without positive user approval. In “Turbo” mode, the AI decides what’s “safe” to run – essentially rolling the dice on your system’s integrity. This lack of execution control means the AI can run anything from a harmless build script to a rm -rf / equivalent if misled

• No Human-in-the-Loop: There is no mandatory checkpoint before dangerous actions. Once tools are enabled, Antigravity does not require human confirmation for any command – even deletions or network calls happen automatically. In the D: drive incident, the user’s only involvement was the initial prompt; the deletion itself occurred without a human sanity-check. This absence of oversight is especially risky in “Auto”/Turbo modes.  

• Poor OS Boundary & No Rollback: The AI operates with the user’s privileges on the OS, but without the user’s caution. There’s no sandbox or fine-grained permission model; Antigravity will directly manipulate files and processes on the host. If it makes a poor decision (or is tricked), there are no built-in guardrails or automatic rollbacks – as if a junior developer had root access and no one watching. A mistaken command can irreversibly wipe data or alter configurations, with the system treating it as if the user intended it.  

• Implicit Trust in AI Decisions: This design overly trusts the AI’s internal judgment to refrain from harmful actions. But an LLM’s judgment is learned, not guaranteed – as one user put it, if the tool can issue catastrophic, irreversible commands on its own, the responsibility is shared between the user (for trusting it) and the creator (for providing “zero guardrails” against dangerous commands).

3. Prompt Injection: Hidden Threats in Code & Content

Hidden malicious instructions in code (invisible to the user) cause Antigravity to run a curl | bash command, achieving a remote code execution – note the launched Calculator as proof.

Prompt Injection via User Inputs: Attackers can exploit Antigravity’s trust by embedding hidden instructions in code or other content, causing the AI to follow those malicious directives instead of the user’s intent. Gemini 3 (the LLM powering Antigravity) is extremely good at interpreting even invisible or obfuscated instructions, which is normally a feature (understanding subtle context) but becomes a severe vulnerability when abused.  

For example, researchers showed that by inserting invisible Unicode characters into a source file’s comments, they could trick Antigravity into invoking run_command to download and execute a remote script. The AI dutifully executed the hidden command as soon as it “explained” that file, resulting in arbitrary code running on the system (a textbook indirect prompt injection leading to RCE).

Similar prompt-injection vectors include malicious markdown or links. An HTML snippet or link can carry instructions that the AI will obey. If the agent is asked to render or fetch such content, it might unknowingly execute embedded commands or leak data.  

In one demo, simply opening a seemingly normal task ticket (via an integrated tool) passed hidden instructions to the AI, leading it to compromise the workstation – because Antigravity blindly trusted the content and had no mechanism to filter out the malicious parts. Without robust input sanitization, any data the AI ingests (code, documents, web pages) can contain covert directives, turning the AI into an attack vector. Code reviews or normal QA won’t catch these, since the exploit instructions might not even be visible to a human reviewer.

4. Remote Code Execution & Data Exfiltration via Tools

Antigravity exploit: the AI reads a secret API key from an .env file, then exfiltrates it via an HTTP request. (Log excerpt shows a GET request with the key being sent out).

Beyond accidents, Antigravity can be weaponized by malicious prompts to actively compromise systems and steal data:

• Arbitrary Code Execution (RCE): Because the agent can run shell commands, a clever attacker can induce it to execute remote code. In one proof-of-concept, hidden instructions led Antigravity to download a script from the internet and run it (curl … | bash), effectively handing an attacker a shell on the user’s machine.  

• Data Exfiltration via Tools: Antigravity’s abilities to read files and fetch URLs can be misused to smuggle out sensitive information. One exploit chain demonstrated how an attacker could command the AI to open a confidential file (for example, a .env file with API keys or credentials) using the read_file tool, and then have the AI call the read_url_content tool with a specially crafted URL that includes those file contents. Essentially, the AI itself performs an HTTP GET request to the attacker’s server, embedding the secret data in the request. From the AI’s perspective it might be “reading” a URL, but in reality it’s sending out the user’s data. The user sees nothing suspicious in the IDE – the exfiltration is completely agent-driven in the background.  

• Leaking Data via Markdown Rendering: Even the markdown/image rendering capability can be a covert channel. Researchers showed that by planting a prompt injection exploit in a .c code file (disguised within a comment), they could make Antigravity, during its explanation of the code, internally decide to embed secret data in an image link. The AI then dutifully “renders” the image by requesting the URL – which actually sends the sensitive data (like API keys from the earlier file) to a third-party server. This happened silently, because the AI saw an instruction to include an image and followed it, unaware that it was betraying user secrets.

5. Architectural Flaws Inherited from Windsurf

Many of these vulnerabilities trace back to Antigravity’s origins. Google’s tool is based on the codebase of Windsurf, a startup AI coding platform Google licensed in mid-2025  

The architectural design from Windsurf emphasizes seamless AI tool integration but lacked fundamental security controls, and Antigravity carried that DNA forward. Issues like no human-in-loop, unrestricted tool use, and prompt injection susceptibility were “known since at least May 2025” from Windsurf’s experience.

In fact, Google’s own documentation now admits Antigravity is vulnerable to the same categories of flaws, with public disclosures dating back to Windsurf’s original CVEs. This suggests the product was rushed to market – likely for competitive reasons – without a thorough security overhaul. The result is an IDE that is innovative but built on a shaky foundation, repeating past mistakes.

6. Why These Issues Persist in AI Design

The Antigravity saga highlights broader challenges in current AI-first design patterns, especially agentic systems:

• Trusting LLM Guardrails Too Much: Developers often rely on the AI model’s built-in “ethical” or safe-completion behavior to prevent bad outcomes. Google presumably counted on Gemini 3 to refuse truly dangerous commands. But an LLM’s refusals or guardrails are not reliable security measuresembracethered.com. They can be bypassed with cleverly phrased inputs, and the model itself might err. As a researcher put it, Antigravity “over-relies on the LLM doing the right thing” as a security mechanism – a fundamentally flawed strategy. The model’s judgment is probabilistic, not a hardened policy enforcement. Thus, when the model is misled (via prompt injection or simple misunderstanding), there’s no safety net behind it – the AI will cheerfully execute harmful actions.
  

• Rushed Deployment, Lagging Security: The race to deploy AI tools has meant security often lags behind. Google’s integration of Windsurf tech into Antigravity was extremely fast (a matter of months), and it appears security review was not prioritized in that timeline. This pattern is industry-wide: features first, patches later
  

• No Sandbox or Least-Privilege Environment: Traditional software security principles (least privilege, sandboxing, privilege separation) are hard to reconcile with an AI agent that’s supposed to seamlessly help with anything. Antigravity ran in the user’s context with broad permissions – essentially giving the AI a blank check on the system.
  

• Evolving Threat Landscape: Ironically, the better AI models become, the more dangerous some of these issues get. Larger, more capable models like Gemini 3 are extremely adept at understanding and executing complex instructions – including ones we don’t want them to. For instance, the ability to parse “invisible” or subtle instructions has grown (Gemini was “exceptional” at it).

8. Recommendations: Safeguarding AI Developer Tools

To safely harness tools like Antigravity, organizations should institute strict controls and best practices:

• Enable Human-in-the-Loop: Do not run agentic coding AIs in fully autonomous mode for high-impact actions. Require explicit user approval for any file deletion, system command, or external network access initiated by the AI. Most such tools have settings – use “manual approval” modes or at least review prompts. The AI should ask before executing something destructive. This one change could have prevented the D: drive wipe.
  

• Limit the AI’s Powers (Least Privilege): Only grant the AI the minimum necessary capabilities. Disable or remove dangerous tools that the project doesn’t need (e.g., if your project doesn’t require internet access, turn off any URL-fetching tool to preempt exfiltration). Use allow-lists for commands – some IDE agents let you specify which shell commands are permitted. For example, you might allow npm install and git status but not rm or format C:. Also, restrict file system access: run the AI in a workspace directory so it can’t roam the entire drive. By curtailing what the AI can do and where, you contain the blast radius.
  

• Sandbox and Isolate the AI Environment: Treat the AI agent as potentially untrusted code. Run it in a locked-down environment, such as a VM, container, or a separate isolated development workstation that has no access to critical systems. The Register’s advice applies: at the very least, use thoroughly segregated environments away from production. If the AI tries to delete files, let it only delete in a throwaway sandbox. If it somehow downloads malware, it shouldn’t have access to your corporate network. Isolation can dramatically reduce risk, at the cost of some convenience.  

• Input Sanitization & Vigilance: Incorporate security checks into the AI’s workflow. For instance, scan any code or text that will be fed to the AI for hidden characters or known exploit patterns (there are tools emerging to detect Unicode obfuscation, etc.). Similarly, monitor the AI’s outputs and actions: enable verbose logging of what commands the AI runs and what external endpoints it contacts. This will help detect if it’s doing something unexpected. If possible, implement runtime guards – e.g., if the AI tries to execute a command containing rmdir or rm -rf, intercept it and require confirmation or block it. A combination of static scanning and runtime monitoring can catch many prompt-injection or misuse attempts.  

• Stay Updated and Patch Quickly: Keep a close eye on vendor patches and security bulletins for the AI tool. Google has begun listing Antigravity’s known issues and working on fixes.  Apply updates as soon as they’re available, since they may close critical holes. If the product supports “safe mode” configurations or new security features, adopt them aggressively.  

• Security Training and Policy: Educate your developers about the risks of agentic AI. Training should cover scenarios like prompt injection – e.g., warn that files from the internet or even internal sources could contain hidden instructions. Developers should be encouraged to treat AI suggestions with healthy skepticism and to review AI actions (for instance, check the diff of what the AI did, rather than blindly accepting changes). Update your security policies to include AI usage guidelines: define what the AI is allowed to do or not do in codebases, and what data it can access. By setting clear rules (and technically enforcing them as much as possible), you create a culture of “verify, don’t just trust, the AI.”

• Red Team and Test: Finally, consider conducting red-team exercises on your AI tooling. Try to think like an attacker: if someone had access to your code repository or could contribute code, could they trick your AI? Simulate these scenarios in a controlled way to find holes before a real adversary does. Some organizations run “purple team” exercises where developers and security work together to probe the AI’s behavior under adversarial conditions. The insights can then inform better configurations or even decisions on whether the tool is ready for broader deployment.
  

How Quilr Prevents the Class of Failures Exposed by Antigravity

The Antigravity incident wasn’t about a single mistaken command. It was a demonstration of what happens when AI systems are allowed to translate model output directly into system action without governance, context checking, or policy enforcement.

This is exactly the control plane Quilr was built to provide.

Quilr does not try to “make the model safer.”
It governs what the model is allowed to do.

Where Antigravity collapses interpretation → execution, Quilr inserts a real-time policy layer that evaluates the full chain of user intent, model reasoning, and proposed action before anything reaches the operating system or a downstream system.

Specifically, Quilr prevents Antigravity-style failures through:

• Real-time inspection of model outputs and tool calls
Shell deletion attempts, unscoped file access, API calls, or markdown fetches are intercepted before execution, not logged after the fact.

• Policy enforcement that separates “reasoning” from “action”
Even if an LLM produces a harmful or misinterpreted instruction, Quilr evaluates the proposed action against organizational policy and stops it if it violates boundaries.

• Behavioral modeling of the agent, not just the user
Sudden destructive commands, unexpected file traversal, or unusual exfiltration patterns from an AI agent are treated as high-risk behaviors and blocked inline.

• Scoped permissions for every tool an AI can invoke
A model should never have global shell access, arbitrary network reach, or unbounded file visibility. Quilr provides the scoping Antigravity lacked.

• Governance for the new layer of risk: model-driven execution
The industry has spent decades securing users, endpoints, networks, and APIs.
AI agents are now executing actions across all of them, Quilr provides the missing enforcement layer for this new surface.

The Antigravity hard-drive deletion was not the last time an AI agent will make a system-level mistake. As enterprises deploy more autonomous assistants, copilots, and workflow agents, these patterns will become common, unless we govern AI behavior at runtime.

Quilr’s mission is to ensure that AI can act, but never act alone.