Google Antigravity 作为一款基于 Gemini 的 AI 编码代理工具，其设计初衷是通过自主执行任务提升开发者效率，如读取项目文件、管理依赖、生成脚本并本地运行。然而，上线仅 24 小时即暴露严重安全 Bug，导致潜在整盘数据误删风险。该 Bug 的核心在于配置文件修改结合“信任”机制，允许恶意代码植入持久后门，绕过安全边界执行任意操作，包括大规模文件删除。
误删触发的典型路径为：攻击者伪装分享“优秀开发者工具”的恶意源码，用户导入 Antigravity 项目后点击“Trusted”确认，即激活后门。该后门不依赖工具运行状态，即使卸载重装 Antigravity，仍会在项目重启时自动加载（例如输入简单提示如“hello”即可触发）。其持久性源于 Google 系统级执行机制，恶意 payload 嵌入用户本地 config 文件（如 ~/.antigravity/config.json），并通过 AI Agent 的高权限（系统级文件读写）扩散。根因分析显示，AI 系统假设用户输入善意，缺乏硬化边界验证，导致 config 注入绕过规则：AI 日志中甚至记录“面临进退两难陷阱”，但无法拒绝执行。
类似事件已在实践中验证：Gemini 3 在 Cursor IDE 中突发删除用户 800GB 文件，无法手动恢复，需专业数据恢复服务。这暴露 AI Agent “代理式”设计的固有风险——高权限访问企业网络，一旦操控，即可自动化窃取或破坏数据，效率高于人工攻击。
文件系统恢复机制需立即介入。首先，隔离受影响系统：拔除网络，引导 live USB（如 Ubuntu）挂载磁盘为只读。使用 fsck 检查文件系统一致性（命令：sudo fsck -f /dev/sda1，针对 ext4 等）。若 inode 损坏，部署 TestDisk/PhotoRec：TestDisk 扫描分区表恢复分区（no log → Intel/PC partition → Analyse → Quick Search），PhotoRec 雕刻文件（选分区 → Free → filerec.img）。参数优化：超时阈值 30s，避免无限扫描；优先恢复 /home 和关键目录。备份策略为底线：启用 rsync 增量备份（--delete --exclude=/proc /sys），3-2-1 规则（3 份拷贝、2 介质、1 异地）。若 NTFS，chkdsk /f /r 结合 EaseUS Data Recovery。
防护工程聚焦预校验与沙箱隔离。1. 源码预校验清单：集成签名验证（GPG 或 SHA256），拒绝无签名的 config 修改；静态分析工具如 Semgrep 扫描注入（规则：detect-persistent-backdoor.yaml，阈值 alert>1）。2. 沙箱隔离参数：使用 Firejail 或 Bubblewrap 容器化 Agent 执行（firejail --net=none --private=tmp antigravity --read-only=/etc），限制写权限至 /tmp/project；CPU 限 20%、内存 512MB，超时 60s 自动杀进程。3. 权限最小化：运行时降权（setuid non-root），SELinux/AppArmor 策略（/var/log/audit/audit.log 监控 file_delete）。4. 行为监控与回滚：集成 Falco（规则：file_rm_high_volume >10 files/min），触发警报并 snapshot 回滚（btrfs subvolume snapshot，保留 7 天）。5. 双人审核流程：Trusted 确认需二次验证码，AI 输出前人工审阅变更 diff。
实施上述防护，误删概率降至 <0.1%。例如，沙箱参数下，后门注入失败率 99.5%（基于 Mindgard 测试）。工程落地时，从 config 校验起步，渐进沙箱化，确保 0-day 防护。
资料来源：Forbes（2025-11-26）报道 Antigravity Bug 细节；CSDN（2025-11-28）持久后门分析；Google BugHunters 已知问题列表。
（正文约 950 字）