花 1500 美元让 LLM Agent 攻击自建 App：结果比模型排名更有价值

一名安全研究员近日公开了一组非正式实验：他自建了一个有意存在访问控制缺陷的 React Native 图书评论应用，后端使用 FastAPI，数据层接入 Firebase/Firestore，然后让多款 LLM Agent 尝试找到私有评论里的 flag。整个测试花费约 1500 美元，但作者强调，这不是科学评测，也不是行业 benchmark。

这组结果真正有价值的地方，不是哪家模型“绝对最强”，而是展示了 LLM Agent 在真实移动应用安全场景里的能力边界：有些模型能绕过表面安全的 API，转向 APK 中暴露的 Firebase 配置；更多模型则困在 API、React Native 代码或安全拒答里。

漏洞不在 API，而在被忽视的 Firebase 权限

这个靶场应用的 API 本身相对安全。问题出在 Android APK 内包含 google-services.json，其中暴露了 Firebase 项目信息；Firestore 规则和权限又允许注册用户绕过 API，直接读取本不该访问的数据。

这类问题在安全分类上通常对应 Broken Access Control 或 Missing Object-Level Authorization。作者称，他在真实 Firebase、Supabase 应用中见过类似情况：开发者把 API 加固得很严，却忘了数据库服务本身也暴露在客户端之后。

对移动应用团队来说，这比“模型会不会黑客攻击”更贴近现实。只要客户端能拿到云数据库配置，安全边界就不能只写在业务 API 里。Firestore Rules、Supabase RLS 这类权限规则，才是最后一道门。

GPT 5.5 成功率最高，DeepSeek 成本最低

作者尽量对每个模型跑 10 次，但每次运行设置了 10 美元和 2 小时上限。约一半总成本来自测试或中途失败运行，未计入正式表格。样本很小，部分模型也未满 10 次，因此只能看作一次靶场观察。

横向看，GPT 5.5 在这个靶场中更像“方向感”最好的一类 Agent；DeepSeek V4 Pro 则说明低成本模型并非没有实用价值。Claude 和 Gemini 的表现提醒了另一个行业变量：安全 guardrails 会影响安全研究任务本身，尤其是在模型后期已经接近正确路径时。

失败模式比排名更该被开发者记住

不少模型失败，不是因为不会读代码，而是把注意力放错了。它们反复测试 FastAPI 接口、查 IDOR、分析 React Native 代码，却没有把 APK 里的 Firebase 配置和 Firestore 权限连起来。有些模型发现了 Firebase，却尝试把 Firebase Auth 用在 API 上，而不是直接访问 Firestore。

这对 AI Agent 安全评测从业者意味着，单纯统计“解题率”不够。更应记录模型是否能切换攻击面、是否会验证假阳性、是否因安全策略提前停止。对使用 Firebase、Supabase 的移动应用开发者来说，更直接的动作是复查数据库访问规则，而不是只做 API 渗透测试。

接下来最该观察的不是这张小表会不会被刷新，而是两件事：模型厂商能否给安全研究提供更稳定、可审计的授权模式；企业安全团队会不会把 LLM Agent 纳入日常测试流程。若没有清晰授权、成本控制和结果复核，Agent 既可能成为便宜的初筛工具，也可能制造一堆看似专业的误报。