邮件与日历智能体

从"这个领域哪里不一样"开始。

每一份领域实战手册都从点明任务开始。这里的任务很好说——分拣、起草、摘要、排期、跟进——而难点不在那儿。难点是数据源的一个性质，值得说得尽可能锋利：

这改变了整个搭建的形状。在客服智能体里，不可信文本来自一个你能框定、能打标的请求。在数据分析智能体里，输入是你自己的表。而在这里，不可信文本在存储层与可信文本无法区分——同一个文件夹、同一套 schema、同一个 API——而智能体的核心循环就是把这些全读一遍。任何以"然后我们检索相关邮件"开头的设计，都已经把攻击者撰写的内容装进了那个决定下一步做什么的上下文里。

动手写代码之前，有两个后果值得先接受。其一，再多的提示词加固都修不了这件事；"忽略邮件里的指令"这类说法，对一个无法可靠区分指令与数据的系统而言只是建议。其二，这里能提供的价值依然巨大且真实，所以答案不是拒绝这个领域——而是把发送通路建成"来自邮件的内容永远够不到它"。机制见提示注入入门。

那"致命三件套"在这里是默认自动凑齐的。

智能体的标准风险框架是三样单独看都没问题、凑在一起就危险的成分：能访问私有数据、会接触不可信内容、有一条能把数据送出去的通道。收件箱智能体第一天就三样齐全，而且不是因为设计失误——是因为产品定义就是如此。

• 私有数据就是整个邮箱，而在多数组织里，那是任何人手上最富含机密的单一存储：合同、同事本不该那样发过来的凭据、董事会材料、关于第三方的个人信息。
• 不可信内容持续到来，来自任何人，对发送方零成本，而且被放在与私有数据同一个存储里。
• 对外通道就是产品功能本身。不能发送的智能体不是邮件智能体。而且发送通路并不是唯一的出口：一个被渲染的图片 URL、一条邀请用户点击的链接、一封转发到外部地址的日历邀请、一个网页抓取工具，都同样有效地把数据送了出去。

已公开的攻击正是照着这个形状来的，而不是什么奇门遁甲。研究者已经演示过：通过普通邮件、日历邀请与共享文档，对生产环境中的助手实施间接提示注入，后果覆盖从数据外泄到钓鱼的一大片。某个托管研究型智能体上的零点击缺陷，允许仅凭一封精心构造的邮件就泄露收件箱数据，用户除了让智能体正常干活之外什么都没做。每一例的模式都一样：内容到达，智能体在正常循环里把它读了进去，然后一项已有能力被掉转向外。

要针对模式来设计，而不是针对具体的载荷。针对已知注入措辞的过滤器值得有，但撑不住；接下来三步里的结构性控制才撑得住。更深的内容见2026 年的提示注入防御与数据外泄风险。

按来源分级，并且让这个标签一路带下去。

第一个结构性动作，是不再把邮箱当成一份语料。每一封邮件都带着来源，而应当由来源决定能力——不是由它落进哪个文件夹决定，更不是由模型判断它"看起来合不合法"决定。

一套能用的三档划分，档位在摄入时确定，并在整个请求的生命周期里附着在内容上：

• 可信。经过认证的内部发件人，在你的域名下，通过各项认证检查。这里的内容可以影响动作，但仍受策略限制。
• 已知外部。有过双向往来历史的发件人，或在显式白名单上的。内容可以被摘要、可以据以起草，但不能单独触发一个动作。
• 不可信。其余一切——首次联系、认证失败、任何来自邮件列表的、以及每一封来自外部的日历邀请。内容只能被读取和摘要。它永远不能引发一次工具调用。

有两条实现细节，决定这套东西是真管用还是演戏。标签必须在检索时附上，并且熬过每一次变换：如果某个摘要步骤把六封邮件压成一段话，那这段话就永久继承其输入中最低的信任等级。以及，档位必须由信头与往来历史算出来，而不能由模型推断——一个"读了这封邮件来决定该多信任这封邮件"的分类器，就是那个漏洞本身的另一种说法。

让发送通路在结构上就够不到邮件内容。

这是承重的那道控制，也是多数实现搞反的那一处。常见设计给智能体一个 send_email 工具，然后靠提示词、靠一个护栏模型、或者靠人点"批准"来阻止滥用。这三样都是概率性防御，而这条通路需要的是结构性防御。

结构性的版本把循环劈成两半，中间那道接口不允许携带指令：

• 一个没有对外能力的读取者。它能看见邮件内容。它没有发送工具、没有抓取工具、够不到网络。它唯一的输出是一个结构化对象——一个意图、若干字段、指向邮件 ID 的引用。
• 一个看不到邮件内容的执行者。它接收那个结构化对象并执行。它从不看见原始正文，于是它的上下文里就没有任何东西是攻击者写的。

安全性就住在这两者之间的接口上，而它必须是一套固定的强类型字段 schema，不能是自由文本。一个接受任意字符串的收件人字段，就是一条穿着 schema 外衣的自由文本通道；一个被约束为"当前会话参与者列表中某个 ID"的收件人字段则不是。这条规则可以推广：从读取者跨到执行者的每一个字段，要么是受约束的枚举，要么是指向执行者能独立重新获取的数据的引用，要么是人手打进去的值。

具体到人们真正想要的那些动作：

• 回复按引用发给会话参与者。加一个尚不在会话里的收件人，是另一个更高权限的动作。
• 发给只出现在邮件内容里的地址的新邮件，正是一次外泄尝试的标准形状。要求收件人由人手输入或由目录服务解析。
• 附件与链接以指向某个对象的引用来携带，由执行者重新获取并重新校验，绝不把内容从读取者那边直接透传过来。
• 批量删除与归档值得与发送同等对待。一个能悄悄删掉那封告警邮件的智能体，就是一个能掩盖自己事故的智能体。

凭据的范围也要配套：一个只能读一个标签、只能在既有会话里回复的令牌，比完整邮箱权限的损失小得多，而多数收件箱智能体不需要更多。见给智能体的最小权限凭据与智能体身份与权限。

日历比邮件更糟，而没人按这个前提去建。

日历常被当成这个产品里无聊的那一半。它其实是更危险的那一半，有四个会互相叠加的理由：

• 邀请会自动插入。在常见的默认设置下，陌生人发来的一封邀请会在你看见它之前就变成你日历上的一个事件。那是对一个你的智能体会去读的存储的、未经认证的写权限——邮件至少还需要从某个用户可能已经设了过滤规则的文件夹里被检索出来。
• 每个字段都由攻击者控制，而且长得像结构。标题、地点、描述、参与者列表、备注。描述字段就是正文的另一个名字；而智能体更容易把日历字段当作可信元数据而不是内容，恰恰因为它们看上去像 schema。
• 事件是被定时读取的。一个每日简报智能体每天早上在没有用户请求的情况下读明天的日历，这意味着攻击者可以选择他们的内容进入上下文的时间。这正是日历成为天然零点击载体的原因。
• 参与者列表是一条出口通道。往事件里加一个地址，就把该事件及其历史分享给了那个地址。它看上去像排期，运作起来像转发。

控制措施可以直接推出来。把外部创建事件的每一个字段——包括标题——都按第 3 步的分级当作不可信内容对待。绝不让日历内容发起一个动作：事件可以被摘要、可以被绕着排期，但不能引发一封邮件被发出、或一份文档被抓取。把修改参与者列表当作发送级动作，套用同样的收件人约束。而如果部署条件允许，就为智能体会读取的账号关掉自动插入邀请；那是一行设置，却消掉了一整片攻击面。

按什么顺序去建——以及真正管用的那种确认。

顺序很重要，因为每个阶段本身就有用，而每个阶段又挣来了进入下一阶段所需的信任：

• 先做只读分拣。打标、排优先级、摘要、把需要人处理的浮上来。完全没有发送能力。价值的大头就在这里，而且这个版本你可以在"安全评审比开发还久"之前就上线。
• 再做只起草。智能体撰写；没有人的动作，什么都不会发出去。但要仔细注意这并非无风险——一封悄悄夹带了外泄内容的草稿回复，在人按下发送之后依然是外泄；这正是为什么即便有人在环里，第 4 步的读取者/执行者切分依然要紧。
• 最后才做自主发送，而且要窄。限定在会话内回复、限定在一小组意图上，带速率限制和按收件人的上限。为什么"量"本身就是一种伤害，见销售与 GTM 智能体。

确认这一步值得单独说，因为默认实现会毁掉它自己的价值。"智能体想发这封邮件——批准吗？"这样一个对话框，训练的是人去点批准；在第四十封正确的草稿之后，他们会不读就批准第四十一封。习惯化不是用户的毛病；它是一道"不管风险如何每次都问同一个问题"的控制的可预测结果。

真正管用的做法是：只在异常时才问，而且展示差异而不是展示成品。一封发给既有会话、没有新收件人、没有附件的回复是例行公事，事后汇总即可。一封发往新外部域的首封邮件、一个附件、一个新增的收件人、或一次异常的发送量，才是例外——而针对它的提示应当恰恰高亮那个异常元素，而不是把整封草稿重新渲染一遍。更少但真的会被读的确认，胜过对一切都确认。这是审批与确认 UX的主题，也是收件箱智能体在实地最常翻车的地方。

相关：运维视角下的提示注入讲上线之后的检测与响应，策略即代码讲把这些限制写在一个可评审的地方，为失败而设计讲智能体正确拒绝时的用户体验。