AI Agent 的阿喀琉斯之踵：当网页指令遇上你的凭证

前两天 HN 上有篇文章引起了不小的讨论：一个 coding agent 被 GitHub issue 里的恶意指令操控，读取了用户的私有仓库并把内容发到了公开 PR 里。用户之前点了「Always Allow」，agent 拿着完整的仓库权限，老老实实地执行了攻击者的指令。

这不是假设场景，是真实发生的事。

问题的本质：不可信内容 + 敏感操作

Prompt injection 本身不新鲜。但当 AI Agent 开始拥有真实的操作权限 — 浏览网页、读写文件、执行代码、发送邮件 — 注入攻击的后果就从「生成一段奇怪的文本」升级到了「替你执行恶意操作」。

OpenGuard 的分析整理了几个关键数据点：

• OpenAI Operator 在 31 个浏览器 agent 测试场景中，即使加了防护，prompt injection 成功率仍有 23%
• Agent Security Bench 报告的混合攻击成功率高达 84.3%
• Anthropic 在浏览器 agent 评估中指出，即使 1% 的攻击成功率，对于每天处理上千页面的 agent 来说都意味着每天有十几次被利用的机会

核心问题可以用一句话概括：不可信的外部内容 + 有权限的工具调用 = 灾难。

攻击面比你想的大

微软在 2025-2026 年间公开的研究列举了具体的攻击向量：

• HTML 里的隐藏图片标签泄露数据
• 诱导 agent 点击恶意链接
• 直接在内容中嵌入工具调用指令
• 利用 agent 的邮件/消息权限发送钓鱼内容

而这些攻击的前提条件出奇地简单 — 只要 agent 在浏览网页、读取邮件、处理文档的过程中遇到了精心构造的内容，游戏就开始了。

当前的防御思路

目前业界的应对策略大致分几层：

1. 输入过滤：检测并拦截已知的注入模式。有用但不够，攻击者总能找到新的绕过方式
2. 权限最小化：不给 agent 不必要的权限。这是最基本的，但很多产品为了用户体验选择了宽松授权
3. 确认机制：敏感操作前要求用户确认。有效但影响流畅度，而且用户很快会养成无脑点确认的习惯
4. 隔离执行：让 agent 在沙箱中运行，限制其对外部系统的访问

坦白说，没有银弹。Prompt injection 和 SQL injection 一样，会成为 AI 应用开发者的日常课题。

开发者该怎么做

几条实践建议：

• 永远不要给 agent「Always Allow」权限。每次操作都该有明确的授权范围
• 把 agent 能访问的内容和能执行的操作分开考虑。读网页和写文件不应该用同一套权限
• 对 agent 的输出做审计。不只是看它说了什么，更要看它调用了哪些工具、传了什么参数
• 假设你的 agent 会被注入。设计系统时把这当作默认条件，而不是边缘情况

这让我想到，在多模型时代，不同模型对 prompt injection 的抵抗力也不同。这是选择模型时容易被忽略的一个维度。

---

如果你在多个 AI 模型之间频繁切换，推荐试试 OfoxAI（ofox.ai）— 一个账号搞定 Claude、GPT、Gemini 等主流模型，也方便你对比不同模型的安全表现。