当智能体学会发信：企业邮件系统如何守住\"确认权\"
过去一年，企业办公的图景正在悄然改写。越来越多的团队让智能体（Agent）代为收发邮件、整理日程、检索资料，效率的提升是真实可见的。
但 2025 年 10 月 npm 生态中的 postmark-mcp 事件提醒我们，这场效率革命的另一面同样真实。这个伪装成 Postmark 官方邮件连接器的工具，前 15 个版本行为清白，第 16 个版本仅仅新增了一行逻辑：为每封经 AI 助手外发的邮件添加密送，将邮件静默抄送至攻击者控制的邮箱。下架前它已被下载约 1643 次，约 300 家组织正在运行，发票、密码重置链接、客户往来记录，在没有任何人点击链接、填写表单的情况下离开了组织边界。
受害者什么都没做错，因为风险的引入点，恰恰是企业为提升效率而主动接入的工具本身。
一、安全隐患
从安全工程视角复盘，postmark-mcp 事件暴露了三个结构性缺陷：
01、信任是时刻性的，而工具是持续演化的。 管理员在接入时完成了一次审批，但工具的后续版本迭代、工具描述变更不会触发重新审查。这就是典型的"契约漂移"（rug pull）：前 15 个版本的清白历史，不能为第 16 个版本作担保。02、语义层的指令注入无法被传统依赖扫描捕获。 "加一行 BCC"既不构成 CVE，也不改变依赖树。npm audit、Dependabot 等面向已知漏洞的工具在此全部沉默。微软 2026 年 6 月的研究表明，将恶意指令植入工具描述后，主流 Agent 模型的中招率超过 60%，部分模型高达 72%。03、这是对企业邮件体系最致命的一点：Agent 的外发行为绕开了"人的确认"。 发票、密码重置链接、客户沟通记录，在没有任何人工环节的情况下离开了组织边界。发送动作本身，成了攻击的完成时刻。Agent 的引入方式千差万别，供应链治理固然重要，但企业真正能够牢牢掌握、且必须立即加固的，是邮件系统本身的出口。
二、亿邮方案
作为深耕电子邮件领域二十余年、并作为起草单位深度参与 GB/T 37002-2026《网络安全技术 电子邮件系统安全技术规范》修订的厂商，亿邮在邮件系统层面所做的，并不是给 Agent 增加一个“是否允许发送”的开关，而是将确认作为发送链路上不可绕过的结构性节点分布在三个相互衔接的控制面上。
01、MTA 层的发信审计与队列控制 亿邮自主研发的 MTA 引擎在发信路径上承载的不只是投递功能，还内置了发信审计能力。系统支持自定义过滤策略和发信拦截的实时通知，被网关策略命中的用户发送行为可以在进入投递之前被拦截并进入发信队列，而不是静默放行。这一层控制的意义在于，无论发信请求来Webmail、
客户端还是 Agent 工具调用，只要经过邮件系统的 MTA，就处于同一套审计与拦截规则之下。Agent 的“自动化”优势不能被用来豁免链路检查。
02、网关层的“再次验证”与隔离机制 亿邮邮件安全网关对命中规则的邮件可执行禁止、转入隔离区、再次验证等操作。其中“再次验证”与“转入隔离区”在 Agent 场景下具有特殊的工程价值：当一封由自动化流程触发的邮件在内容、收件人模式或发送频率上偏离了基线，网关不是简单地放行或拒绝，而是将其置入一个需要人工显式确认才能继续的状态。隔离区机制在亿邮网关中原本用于拦截邮件的用户侧处置，其逻辑同样可以延伸至发信侧：被策略标记的待发邮件不会因为调用方是“已授权的 Agent”就跳过处置环节。
03、高风险操作与敏感内容的二次确认策略亿邮安全增强电子邮件系统支持细粒度的收发权限管理，对高风险操作（如向特定地址发送、大量外发等）实行二次审批或动态验证；对含敏感信息的出域邮件，可依据预设策略执行实时拦截或审批。在邮件 AI 方案中，模型输出的事实性陈述被要求可追溯至线程内既有文本或经批准的知识库来源，而非依赖参数化记忆的自由生成。换言之，亿邮在 Agent 能力介入的起点就设置了“必须被人看到并放行”的约束，而不是等到邮件已经进入 SMTP 会话之后才指望过滤器兜底。
此前有反驳称：要求 Agent 每一次发信都经过人工确认，会消解自动化本身的价值。这个推论混淆了“确认的频率”与“确认的必要性分布”。
亿邮的工程实践并不是对所有发信行为施加同等粒度的人工介入，而是依据风险信号对确认节点进行差异化部署：常规的、模式稳定的发送可以在策略框架内放行；偏离基线的收件人、敏感内容、异常时间窗口或权限边界上的操作，则强制回到确认节点。
动态白名单机制是一个可参照的例子：系统对通过验证的外域收件人建立有限期的信任记录，减少重复确认，但信任的有效性和更新条件始终由系统策略控制，而非由外部工具自行宣告“我仍然可信”。
在 Agent 参与邮件链路的场景下，真正需要被设计的是确认权的回收路径。亿邮在架构上始终坚持：邮件系统始终保留对发送行为的最终裁决能力，包括在发信队列中拦截、在隔离区中扣留、在网关层要求再次验证、在内容策略上触发二次审批。这些能力不依赖于 Agent 的自觉，也不依赖于对某个第三方工具历史版本的信任评估。工具可以被替换，链路可以被重新配置，但确认权不离开邮件系统的控制域。