假设你正在与另一家公司代表进行邮件沟通，讨论如何支付他们提供的服务费用。你收到了一些付款说明。
随后，他们很快跟进通知你，他们最近更新了流程，并发送了新的付款说明。
一切看起来都很正常。你发送了一封邮件确认已收到更新的信息，并按照修订后的指示操作——例如，使用新的分发地址。
一周后，你接到通知，对方公司表示尚未收到所需资金。你一头雾水：“我用你们更新的信息汇款了。”你告诉他们。然而，当你仔细检查邮件群聊中的地址时，才发现真相。你的心瞬间沉到了谷底。
邮件线程中其他人都是伪造的，只有你是真实的。你刚刚在毫无察觉的情况下，将一笔巨额资金转给了一些陌生人，而他们的邮箱地址早已被篡改。
发生了什么？该邮件线程的一名成员被盗用了。该账户的劫持者利用他们的邮件线程访问权限，将一条消息转发给你和新的收件人。很少有人会想到，邮件群聊在进行中途会发生如此剧烈的变化。结果，你被骗了，向错误的人付款。更糟糕的是：你不知道数百万美元的损失最终去了哪里。
谁该为此负责？目前还很难确定；或许唯一的解决途径是一场充满争议的法律诉讼。
解决这个问题其实相对简单，但很少有人真正做到：
-
无论何时，只要有人要求你采取可能带来重大后果的行动，比如汇款大额资金，请务必——务必！——仔细检查发送者的完整邮件地址。
-
确保线程中的每个人都符合你的预期。
-
三思而后行，确认无误再付款。
这是一个适用于大多数情况的实用准则：如果有人要求你下载或发送某些东西，请确保提出请求的人是你信任的对象。即便如此，也可以考虑通过其他通信渠道发送确认信息，以确保细节无误。如果你特别谨慎，可以添加邮件签名和加密功能。这样，你就能确信收到的指令确实来自你认为的发送者（或者至少是他们的设备）。
6.混淆 AI 代理如果不提及当前最“流行”的问题——提示注入（Prompt Injection），这份列表就不完整。提示注入和其他注入攻击类似：将“控制”命令替换为数据输入。对于大型语言模型（LLM）而言，这意味着告诉它“忽略之前的指令……”，然后按照其他指令操作。
举个例子，研究人员曾在电子邮件中演示这种攻击，使用“隐形”文字（白底白字）。隐藏的信息会指示 LLM 向用户发出警告，称其帐户正在被盗用，并要求立即拨打钓鱼电话解决问题。当电子邮件被汇总后，LLM 会传递警告信息，从而引发钓鱼攻击。