AI 何時會把讀到的內容誤當成獲授權執行的命令？

简介： 企业接入AI邮箱，期待提效减负，但需警惕邮件中隐藏的“指令陷阱”：发件人要求≠AI可执行命令。2026年发票欺诈攻击揭示风险——AI若混淆“收到请求”与“获授权行动”，可能越权转发、误判核实。自动化必须锚定企业预设权限边界与审批流程，而非依赖模型对语言的单点理解。

企业把邮箱接给 AI，通常有一个朴素的期待：少花一些时间翻邮件、找附件、整理待办，让重要的事情更快被处理。

但这也把一个问题带进了收件箱：当 AI 读到“请把附件转给财务”时，它读到的是发件人的要求，还是自己应当执行的命令？

2026 年 10 月 26 日，Sublime Security 披露了 10 月 22 日发现的发票欺诈邮件。邮件夹带隐藏指令，试图让邮件 Agent 将来信和 PDF 附件转往攻击者认为能够接收应付账款材料的地址。研究中的模型反应不一，文章没有报告这条指令已导致实际转发或付款。

这次攻击尝试提醒我们：面向 AI 的业务材料，也可能夹带对 AI 的指挥。企业在开放读取能力时，需要同时考虑，材料里的话能够影响哪些行动。

收到一项要求，和接受一项委托，中间还隔着组织的决定。

假设一家公司的财务负责人让 AI 整理当天收到的发票，列出金额、供应商和缺失材料，供会计核对。

一封来信里写着：这件事已经沟通过，请尽快将附件转给付款负责人，并注明材料已经核实。

对一个努力完成任务的助手来说，这段话可能被理解为下一步工作。附件找到了，负责人的地址也给出了，加上一句说明，似乎还能帮助同事减少重复劳动。

然而，原任务是整理待核对材料。来信提出了转发要求，还试图让助手替材料作出“已经核实”的判断。这已经改变了工作范围。

供应商可以提出收款请求，员工可以提交报销申请，客户可以要求退款。企业当然需要理解和回应这些要求。至于由谁接受、按什么规则办理、哪些材料足以支持执行，应当来自企业认可的委托和业务流程。

即使邮件确实由熟悉的供应商发来，也不能仅凭身份真实，就推导出它有权更改公司的审批条件。身份有助于回答谁说了这句话，授权还要回答他在这件事上能作什么决定。

发件人影响工作内容是正常的；发件人能否改变助手的行动范围，需要另有依据。

一封邮件的风险，也可能在内部流转时扩大。

谈到邮件安全，人们很容易先想到资料被发往外部。企业内部同样存在不同的职责和信任边界。

继续看前面的假设。如果 AI 把供应商的来信转给财务，并在摘要里写上“资料已核实，建议处理”，接收者看到的就多了一层判断。供应商原来的说法，可能借助公司助手的身份，获得了原本没有的可信程度。

问题也可能发生在系统之间：一个工具只负责归类邮件，另一个工具负责创建待办，第三个系统负责审批。这些步骤连接起来以后，如果“已归类”或“已转交”被后续环节理解成“已核实”，正式审批就可能建立在不成立的前提上。

内部转发本身不等于付款，进入待办也不等于批准。但后续环节如果没有保留来源和核验状态，就容易把“已经被前一道流程处理”理解成“前一道流程已经确认没有问题”。

这里值得警惕的，是信息在流转过程中悄悄改变了身份。

“来信声称已经批准”与“审批系统存在一条有效批准记录”，需要始终保持区别。AI 在压缩长邮件、整理摘要时，也要保留这种区别。否则，语言变简洁了，判断所需的条件反而丢失了。

只检查收件地址是否属于本公司，还不足以回答转交的目的、附带的判断和后续动作是否得到允许。接收范围与业务资格，是需要一起核对的条件。

让模型更会识别攻击，与明确谁能授权，是相互配合的工作。

识别隐藏指令、可疑附件、伪造身份，当然有价值。宿主也可以标记外部内容、限制工具范围，帮助模型区分用户要求与待处理材料。

这些措施能降低模型被误导的机会。与此同时，实际执行仍然需要一个独立依据：当前助手究竟代表谁，这项委托允许什么动作？

模型可能准确理解一封催款邮件，正确找到对应的发票，也正确识别出财务负责人。上述判断都成立，仍不能单独证明它有权声称材料已核实，或者把申请改成加急处理。

同样，给另一套模型检查原模型的决定，可以增加一道审查；但两套模型都认为“这样做很合理”，也不会自动产生一份公司的授权。

OWASP 在 Excessive Agency 风险说明中提出了相应的工程原则：使用具体用户的最小必要权限，在下游系统实施授权检查，并为高影响动作设置人工批准。授权判断不能全部交给模型自身。

落到企业应用里，模型可以提出一个候选动作，执行接口则应依据可信身份、任务范围和当前业务条件检查它。邮件正文中的“已批准”，不能直接填进系统的批准状态；模型自己生成的“允许执行”，也不能成为放行依据。

这样安排之后，即使内容识别存在遗漏，行动范围仍有另一处可以检查。它能限制部分错误的后果，并不意味着授权范围内的所有误判都会被消除。

自动化可以来自预先明确的规则，无须让用户逐封点头。

如果每封邮件、每次归类、每次转交都要停下来问人，很多自动化价值确实会被消耗掉。

更有用的做法，是把可以连续完成的工作提前讲清楚。

例如，在刚才的假设公司里，企业可以允许财务助手读取指定邮箱、提取发票信息，并将符合既定条件的材料送入固定的“待核对”队列。这些动作可以自动完成，前提是接收对象、资料范围和业务状态都符合这项委托。

材料进入队列后，仍保留待核对状态。若来信要求改收款信息、改变处理对象，或者声称可以跳过核验，助手就不能把它当成原任务中的普通步骤。它可以把这项要求单独列出，交给有权的人或系统处理，同时继续整理其他符合条件的邮件。

客户通过邮件提出退款，也可以成为自动流程的入口。能够触发后续操作，是因为企业预先定义了适用条件，并核验了客户与订单关系、退款资格等信息，而非因为来信里用了“请立即执行”这样的措辞。

这种自动化并不要求每一步都重新授权。它要求正常工作与超出范围的要求能够被区分，让已批准的流程顺畅运行，让需要新决定的地方停得准确。

批准本身也要对应具体内容。用户同意转交某份材料后，若收件人或附件发生了实质变化，就需要重新判断原批准是否仍然适用。一个笼统的“我同意”，不能被反复解释成对后续所有变化的同意。

助手能调用哪些工具，只说明了授权的一部分。

许多应用会在首次连接时询问：是否允许访问邮箱、发送邮件、读取业务数据？

这类权限很重要，却通常比较粗。拥有发送功能，可能是为了处理某类明确的业务通知；它不应自动覆盖助手后来读到的所有转发要求。

因此，企业还需要让工具权限与本次任务衔接起来。一个长期服务于多个部门的助手，在不同任务里可能代表不同的人，能够处理的邮件、订单和接收对象也随之变化。

如果执行端始终只看见一个权限很大的公共账号，就很难核对某次请求是否仍处于原委托范围。把“本次代表谁、针对什么工作”带进校验，可以避免仅凭程序持有有效凭据就放行动作。

这些条件也应当能够撤回。任务已经取消，员工权限已经调整，之前读到的“请继续处理”不能让旧委托重新生效。

企业接入 AI 后，既有权限和审批体系仍然有用。需要做的是把它们与助手的每次实际行动接上，而不是让模型在对话里重新猜一套公司的制度。

可核对的结果，要保留动作从哪里来、为什么被允许。

出了问题以后，一条“AI 已处理邮件”的记录，解释不了多少事情。

更有用的记录应当能还原：哪项任务让助手读取了这封邮件，哪段来信提出了新的要求，实际执行依据的是哪项预先规则或批准，以及最终发生了什么。

其中尤其需要保留来源差别。外部发件人的说法、模型的判断、内部核验结果，可以同时存在，但不能在转交时合并成一条没有出处的“已确认”。

结果也要符合实际状态。生成转发草稿、邮件服务接受发送、收件人收到邮件、下游业务完成，是不同的事实。系统能确认到哪一步，就应该表达哪一步；不确定时保留待核实状态，避免后续助手靠一句成功摘要继续推进。

这不意味着必须无限保存所有邮件和附件。可以依据需要保存受保护的原件引用、必要的动作信息、批准关联及执行结果，并设置访问权限和保留期限。审计本身也需要遵守资料边界。

值得积累的经验，正是这些交接细节：哪些说法容易被误当成事实，哪些动作容易被误当成完成，以及异常发生后怎样恢复而不扩大影响。

当 AI 开始代表组织办事，共同的责任表达会越来越重要。

邮箱只是一个容易观察的入口。同样的问题也会出现在工单、合同、网页、知识库和其他智能体传来的消息中。

企业需要让 AI 广泛理解材料，也需要让执行始终回到组织认可的依据。这会涉及模型、宿主、连接器、审批系统和实际业务系统，单靠某一个组件的聪明，很难替所有参与方补齐彼此的责任。

我们长期做业务软件，在把智能体接回真实业务的过程中，也反复遇到这种衔接问题。我们用 A2B 描述智能体接受委托、进入已有业务系统并产生业务后果的场景；用 ACC 提供能力与部分治理语义的开放参考，再通过 BailingHub 做其中一种可运行的实践。

这些工作关注的是主体、边界、停点和事实怎样衔接。邮件攻击识别仍需要相应的安全措施，业务系统也必须保留自己的最终授权。我们希望贡献的是实践中踩过的坑和多轮调整的经验，让同行能更容易讨论和核对同一类问题。

未来采用哪一种规范、是否继续使用这些名称，可以开放讨论。值得尽早达成共同认识的是：一段内容被 AI 读懂以后，需要依据什么，才能变成代表组织实施的行动。

企业现在就可以选一条准备交给 AI 的真实邮件流程，从来信一路看到业务结果：谁提出了要求，谁决定可以做，哪里会拦住超出范围的动作，最后又靠什么确认完成。

这些问题能够回答清楚，自动化才更容易扩大，而不用把越来越多的判断压回用户的每一次点击上。

企业交给 AI 的，是在明确范围内处理工作的能力。谁能改变这个范围，仍然需要企业自己决定。

项目参考

• ACC 开放能力契约：声明参考，业务系统保留最终授权。
• BailingHub 开源项目：将部分执行治理要求落实到运行链路的一种实践。