# 客服智能体读到一封“批准邮件”，没人授权却退了4200美元

**Summary:** Intigriti的研究显示，伪造的对话记录竟能触发4200美元退款。我认为可以让模型准备操作建议，但身份验证和授权决策必须交由常规软件处理。

- Canonical: https://markhuang.ai/zh/news/support-agent-fake-approval-4200-refund
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-14
- Section: News
- Tags: AI客服, 智能体安全, 提示注入
- Source: [Intigriti](https://www.intigriti.com/researchers/blog/hacking-tools/hacking-ai-customer-service-agents)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一封邮件在到达授权关卡前，分裂成对人无害的路径和对机器危险的路径](https://cdn.markhuang.ai/news/support-agent-fake-approval-4200-refund/hero.webp)

*同一条消息对人看起来无害，却可能通过智能体的工具路径传递完全不同的信号。授权关卡必须对两种呈现都保持警惕。*

[Intigriti 9月2日关于AI客服智能体的研究](https://www.intigriti.com/researchers/blog/hacking-tools/hacking-ai-customer-service-agents)中有个直白的例子：攻击者在邮件链里塞进一封伪造的事先批准，客服控制台把它渲染得像真人客服写的，结果智能体直接批了4200美元退款。Intigriti表示，这项研究也是他们DEF CON 34演讲的基础，几个周末下来，漏洞赏金已经超过5万美元。

在我看来，模型只是故障的一环。邮件系统可能以一种方式理解消息，而客服控制台和账户API却以另一种方式解读。一旦智能体把每种解读都当作可信事实，一个显示层面的小把戏就能变成经过授权的操作。

我不会让客服模型去判断用户是否已认证，或者是否允许退款。它可以收集上下文并提议下一步操作，但背后的安全决策必须基于规范的身份数据和策略数据。

## 退款始于对同一消息的两种解读

这个伪造批准的例子是Intigriti文章中更大模式的一部分。一封邮件可以同时包含人看到的HTML正文和智能体读取的不同纯文本正文。不可见的HTML可以向机器读者留下指令。远程图片服务器甚至可以根据访问者身份返回不同内容。在每种情况下，审核界面都可能省略影响智能体的证据。

这就是为什么“有人检查过”太模糊，不能算作有效控制。审核者看到的到底是哪个版本？他是否看到了智能体实际使用的身份、来源、工具参数和具体操作？如果控制台把引用文本美化成可信的消息气泡，界面可能恰恰隐藏了审核者需要的关键区别。

来源还记录了模型之外的解析器分歧。在一个例子中，包含括号注释的邮箱地址被邮件层规范化，但随后以原始形式放入后端查询字符串，另一个解析器将其部分视为第二个参数。[RFC 5322定义了结构化邮件字段中的括号注释](https://datatracker.ietf.org/doc/html/rfc5322#section-3.2.2)，并警告地址字段中的注释可能混淆旧版实现。当两种有效解读被允许决定两个不同的安全事实时，漏洞就出现了。

## 认证不能是一场对话

研究中的多个例子攻击了消息与账户之间的交接环节。伪造的发件人可以把智能体引向错误的客户。被抄送的攻击者可能收到本该给那位客户的数据。从聊天切换到邮件或电话可能会重置薄弱的验证流程。即使模型完美遵循指令，仍可能服务了错误的人。

这是个老掉牙的“混淆代理人”问题，只是套上了聊天界面。智能体之所以有权限，是因为公司赋予了它权限。攻击者提供文本，说服这个代理人把权限用在错误的上下文中。更强的系统提示可能减少明显故障，但无法确定谁拥有账户，也无法判断请求的操作是否符合公司政策。

[OWASP关于过度代理的指南](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)把检查点放在我认为正确的位置：下游系统应根据安全策略验证每个请求，工具应在用户自己的授权上下文中运行，高影响操作必须经过审批。退款API应该接收服务器生成的账户标识符，并自行执行退款限额。它不应接受从文本中重构的身份或批准。

我在看[屏幕驱动智能体的信任循环](/news/gemini-computer-use-trust-loop)时也得出了同样的结论。提示可以描述智能体应该做什么，但权限和审批关卡决定它能做什么。

> **Info:**
>
> 我的规则很简单：模型可以提议操作，但确定性软件必须认证客户、将操作绑定到该客户、检查策略并记录决策。人工审批应在最终操作边界进行，并且能看到原始证据。

## 更多上下文可能创造新的攻击面

研究超出了实时对话，延伸到了客服收件箱和知识库。在一个记录的场景中，智能体保留了收件箱中植入的指令，然后在真正的一次性验证码稍后到达时应用了它。在另一个案例中，包含不存在促销活动的社区评论进入了检索索引，并在操作员控制台中显示为普通的内部引用。

客服需要历史记录、政策文档和账户上下文才有用。这使得来源追踪更加重要。检索层必须保留论坛评论与政策页面之间的区别，或先前客户消息与操作员批准之间的区别。即使是来自第三方的真实邮件，也不代表有权转发其内容。

[OWASP提示注入防范速查表](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html)建议输入输出验证、最小权限、工具特定参数检查、监控和人工审核。我会再加一条产品要求：展示给审核者的每个事实都应保留其来源类别和信任级别。没有来源标注的引用反而会让被污染的上下文看起来更可信。

## 这些也是普通的集成漏洞

一篇[r/netsec上关于Intigriti文章的讨论](https://www.reddit.com/r/netsec/comments/1wae5zc/hacking_ai_customer_service_agents_bug_bounty/)包含了怀疑观点，认为说服安全性差的服务智能体纯粹是运营方的过错。我部分同意。许多例子结合了熟悉的漏洞，如欺骗、弱速率限制、宽松解析器、路径遍历或可预测标识符与智能体。把每个故障都称为“AI安全”可能会掩盖使其可利用的普通工程错误。

这种批评改变了我的修复思路。模型应该被当作常规安全架构里一个不可信的规划器，而不是用来修补周围薄弱身份校验的组件。智能体测试应该覆盖畸形邮件、冲突表示、被污染的检索内容和跨渠道重试——因为现有的漏洞正是通过这些途径获得了自然语言的控制面。

## 我会允许客服智能体做什么

我会从只读工具和窄范围记录开始。智能体可以总结案例、定位已批准的政策、起草回复或准备退款提案。每个工具应暴露一个有限的操作，而不是通用的后端请求，并且只应返回经认证客户有权查看的数据。

任何更改账户所有权、泄露机密、发送资金或联系外部系统的操作都需要单独的授权步骤。审核者应看到标准化的发件人身份、未经处理的原始消息、后端选择的账户以及确切的提议操作。日志应同时保留模型看到的内容和工具执行的内容。

4200美元退款让人印象深刻。但修复手段其实就是常规的访问控制。一个有用的客服智能体可以解读混乱的请求并准备好下一步操作，但后端仍然必须验证：谁在提请求、他控制哪个账户、策略是否允许这个操作。