智能体要读你的邮箱才好用：授权范围、二次用途与撤销后的残留
一、读取邮箱不是一项权限，是一组权限
据公开报道，有一家做旅行服务的公司新设了团队，推出旅行管理类智能体，产品从用户邮箱里的机票、酒店、餐厅确认邮件整理行程，并跟踪价格变化与余位一类的信号，采用邀请制的方式开放。报道里提到的投入规模、团队安排与开放节奏，本篇都不作为判断依据，也不评价这家公司的产品选择。值得单独写一篇文章的是它依赖的那一项能力：要读用户的邮箱。
这类功能在介绍里通常被写成一句话：连接你的邮箱。但工程上，邮箱接入从来不是一个开关，而是一组可以分别授予、分别吊销的能力。读哪些文件夹、能不能长期驻留做增量读取、能不能代发、能不能给邮件打标签或改写邮件本身，这四件事的组合决定实际暴露面，而它们经常被合并成一句同意就一起放开了。同意的颗粒度比同意的存在更重要，这是本篇的核心观点。
另一个容易被跳过的环节是退出。授权的时候界面只问一次，撤销的时候系统里可能已经生成了三样不属于原邮件的东西：解析出来的结构化记录、由这些记录累积成的偏好画像、以及已经交给下游第三方的副本。这三样都不在邮箱里，撤销授权动不了它们，所以撤销语义必须在授权之前就问清楚。
二、核心交付物之一：四维授权表
下面这张表的用途是把连接邮箱这一句拆开。左列是要问的维度，中间两列是给出最宽答案时的实际含义，右列是我们建议的可接受下限。任何一格答不上来，就不该把它当成已获授权来处理。
| 授权维度 | 最宽的做法 | 实际含义与风险 | 建议下限 |
|---|---|---|---|
| 读取范围 | 全邮箱所有文件夹与标签 | 确认邮件之外的私人通信、账单、其他平台的验证码都在可读面内 | 只限定的文件夹或标签，且写入授权说明 |
| 时间窗与增量 | 不限历史且长期驻留轮询 | 一次授权等于持续订阅，此后新到的每一封都被看见 | 限定回溯范围并设轮询终止条件，续期需重新确认 |
| 发送与代发 | 可任意发信 | 冒名沟通与对外承诺的责任落在使用方身上 | 不申请发送权限；确需通知时由我方原域名原账户发出 |
| 写入与改写 | 可加标签、移动、标记已读、改正文 | 修改邮件会改变用户自己的证据链与归档 | 只读；标签确有必要时单独申请且可单独撤销 |
四个维度里最危险的是第二和第四。读取范围是一次性的可见面，时间窗是持续的可见面；而写入权限带来的问题不在隐私，在完整性：一个第三方服务把邮件标成已读或者移动了位置，用户自己随后找不回判断依据，出事时无法区分是我的助手改的还是别人改的。
三、最小化的三种形态与各自己要付的代价
把四维收紧之后，实际能落地的形态只有三种，每种都要付能力损失，选形态之前先算这笔账。
- 只读且限定文件夹。代价是它只能看见被指定范围内的邮件，确认信散落在多个文件夹时会出现漏项，行程不完整却不会报错，属于静默失败。缓解办法是把已扫描范围显示在界面上，缺口提示用户补授权而不是后台自己扩大。
- 在本地或边缘侧解析，只上传结构化结果。代价是需要一个用户可控的执行环境，跨设备一致性、离线时更新中断都要自己处理。好处是原始正文不出门，对客解释的成本最低，也是三种里唯一能把可读面压到单封邮件的形态。
- 只授权用户把邮件转发到一个指定地址。代价是完全没有增量，每一封都要用户手动动作；但它不需要任何令牌，撤销就是停止转发，残留最少。这条适合低频场景，比如只做重要确认的归档，不适合盯价格变化这类需要持续观察的需求。
三种形态的排序依据不是安全性高低，而是数据不出门的距离：正文不出门、正文出门但只留结构化结果、正文与附件全部出门。距离越远，后面的留存与撤销问题越难办。
四、二次用途要问清的四件事与令牌的工程要求
服务承诺里一句不会写、但决定风险量级的问题是：我读到的邮件后来被用来做了什么。这里必须说清楚，本篇不推断任何一家公司是否把邮件内容用于模型训练，这是外部事实我们无法核实；要写的是一组应当被问出来并得到书面回答的问题。
四件事分别是：其一，读取到的正文与附件是否用于训练或其他改进目的；如果不用于训练，是否用于训练之外的分析，例如统计哪类发件人的价格会变。其二，这个账号的数据是否与其他用户的数据混合处理与混合存储，混合之后单独删除在技术上还做不做得到。其三，保留多久，是每次解析后只留结构化结果、正文即读即删，还是正文整体留存一段时间。其四，用户能否把这些数据导出带走，导出的是解析结果还是包含原始邮件。
这四问的答案会直接变成条款字段，而条款字段又要落到令牌设计上。我们要求接入邮箱类服务的令牌满足五条：有效期短且必须显式续期，长期令牌是默认失败的设计；每张令牌可单独吊销，不能用撤销账号来实现；权限作用域按授权对象隔离，同一个用户的多项授权不复用同一张令牌；作用域发生变更时不能沿用旧的同意记录，要重新走一次确认；令牌的每次使用都要落审计日志，但日志里不写邮件正文，只写动作、对象标识与摘要。最后一条经常被违反，原因是排查问题时把正文一起打进去最省事，这等于在另一个系统里复制了一份邮件。
五、核心交付物之二：撤销之后三类残留的核验清单
撤销授权应当有可验证的完成定义，否则撤销只是把开关拨回原位。三类残留要分别核验。
| 残留类型 | 它为什么不会被撤销带走 | 可核验方式 | 拿不到证据时的处理 |
|---|---|---|---|
| 已解析的结构化记录 | 记录在对方库里，不依附于邮箱 | 要求逐项列出并给出删除回执，回执要含条目范围 | 视为未删除，把它记入风险台账 |
| 由记录累积的画像与偏好 | 派生对象的所有权与归属在条款里常写不清 | 要求导出可解释字段：用过哪些类目、多久内更新 | 要求提供关闭个性化而不降级的选项 |
| 已共享给下游第三方的副本 | 数据已不在合同相对方控制内 | 要求提供下游清单与转达删除的时限 | 在授权前就把下游共享设为不可选 |
核验清单的关键在于证据形态：一句我们已经删除不是证据，带条目范围与时间戳的回执才是。回执拿不到时不要接受口头确认，把它按未删除处理并继续计入风险，这是唯一能向客户解释的口径。派生对象那一类还要额外问一句：如果画像与偏好是从多个来源合成的，删除其中一路之后，剩下那一路还留着什么结论。这一句在很多服务商的说明里是缺失的，而它决定了删除是否真的可执行。
六、连带问题、界面要素与我方作为接入方时的边界
邮件里不只有授权人自己。一封同行预订的确认信包含同行人姓名、证件号片段、行程时间与联系方式，这些人没有对任何第三方服务表示过同意。处理义务因此和自有数据不同：要按最小字段抽取，凡是不参与功能计算的信息在解析阶段就丢弃；不把同行人信息用于向本人之外的任何通知；对外说明里承认存在这类第三方信息并写明其处理方式，而不是只写一句我们尊重隐私。
如果要把这套授权做成产品功能，界面上要有四样东西：一张能看见的授权卡片，按维度显示授予了什么、没授予什么；逐条解释，写明这一项权限用来做什么、不给会少了哪个功能；一个一键撤销入口，且撤销后给出确认信息，说明哪些数据已按第五节处理；一份授权历史，让人能看出作用域什么时候变过、变大的那一步是谁点的。把授权状态藏进设置深处的结果，是没人记得自己给过什么，出事时才去查，查不到。
最后写我们自己作为接入方的边界，因为我们也做需要读邮件或读消息的服务。四条硬规矩：只取功能所需字段，其余不落地；原始正文解析完即删，留存期限写成配置而不是写在文档里；日志不写正文，只写动作与摘要；解析规则和保留期版本化，能够回答某个结论是在哪一版规则上算出来的。这四条在内部评审里属于洹拓的准入门禁，缺任一条就不接这个数据源。方便和暴露面从来是同一件事的两面，能把它拆成上面这些可核对的字段，才谈得上把它交给用户选择。