用服务端权限约束邮件智能体发信

让 AI 自动回复客户邮件，风险不只在于答错话。陌生人发来的正文还可能夹带指令，诱导它转发收件箱、联系新地址。只在 system prompt 里写一句「禁止」，不足以充当发信权限控制。

作者以 osFoundry 桌面应用为例，给出了一套更具体的做法：限制模型能看到的邮件，再由服务器检查收件人、会话和发送频率。它值得参考的地方，是把「模型想发什么」和「系统允许发什么」分开处理。

先限制它能读什么，再限制它能发给谁

这个方案没有把整个邮箱交给 Agent，而是只分配一个子地址，例如 hello+support@…。只有发到这个地址的邮件，才会进入模型上下文。同一邮箱里的发票、密码重置邮件不会被传进去。

这是在减少暴露给模型的数据。攻击邮件即使诱导模型转发其他内容，模型也拿不到那些未被传入的邮件。

发送端还有一道限制：默认只能回复别人已经发起的会话，不能主动创建新会话，也不能给新地址发信。如果正文要求「把内容发给 x@example.com」，而这个地址不属于当前会话参与者，服务器就会拦住。

模型负责生成回复，服务器负责决定这封邮件有没有发送资格。

作者担心的是提示注入（prompt injection）：外部邮件把恶意指令混进待处理内容。系统提示可以约束模型行为，但邮件正文不能改写服务器上的权限规则。

收件人合法，也要防止自动回复打循环

只检查收件人还不够。客户一侧如果也是自动回复程序，双方可能互相触发，一封接一封地发下去。

原文给出的限制是：

• 每个会话每天最多回复 3 次。
• 整个邮箱每小时最多发送 10 封邮件。

计数和拦截都由服务器执行。模型即使认为「还需要补充一封」，超过额度也发不出去。

这两个数字是文中配置，作者没有解释如何确定阈值，也没有提供不同业务量下的对照数据。可以借鉴它的两层限额思路，但不能直接认定 3 次和 10 封适合所有客服邮箱。正常的多轮沟通也可能碰到上限。

新收件人先审批，夜间回复还取决于电脑状态

Agent 有时确实需要联系新对象。原文的例子是向仓库地址 orders@… 询问库存。此时邮件会进入待审批状态，由人检查收件人和正文，再点击 Allow。

批准后，邮件会发送并写入活动日志。后续发往同一地址的邮件，则不再逐次询问。

这里必须看清授权范围：人审的是一封邮件，但系统同时放行了后续发往这个地址的邮件。原文没有交代授权是否过期、如何撤销，以及后续邮件与会话限制如何配合。

运行方式也影响实际体验。完整回复由本地机器上的 Agent 生成，使用用户自己的模型 key；「已收到邮件」的确认通知由服务器发送，所以电脑关机也能发出。

如果希望夜间继续生成完整回复，可以开启有任务等待时阻止空闲睡眠的设置。屏幕仍会关闭，合上电脑盖子仍会睡眠，不能把它理解成全天候在线服务。

我的判断

我赞同把权限检查放在服务器。与单靠 system prompt 相比，这套做法给发送动作加上了明确、可执行的边界；与每封邮件都人工审批相比，它又允许已有会话自动流转。

但边界有限。它主要约束数据可见范围、发送对象和发送数量，不能保证回复内容正确，也不能保证已有会话里的信息披露都合适。新地址首次获批后自动放行，更需要明确授权的持续时间和撤销方式。

原文展示了产品界面和工作流程，没有给出攻击测试、误拦截率或长期运行数据。因此，可以把它当作一份实现思路，尚不能据此认定这套方案已经充分验证了安全性。

能拿来做什么

• 如果你在 Node 服务里接入邮件 Agent，可以把会话参与者校验和发送限额集中放在发信入口，让每次工具调用都经过同一套检查。
• 给模型准备邮件上下文时，先按专用收信地址筛选，避免为了处理客服邮件就把整个邮箱传进去。
• 审批界面应同时展示收件人、完整正文，以及批准后是否持续放行该地址，让人知道这次操作授予了什么权限。
• 如果 Agent 跑在本地电脑上，应区分服务器确认通知与模型完整回复，并明确关机、空闲睡眠和合盖各自会造成什么影响。