把 AI 智能体连接到邮箱和日历，确实可以省下不少琐碎工作。它能整理晨间简报、找到漏掉的附件、起草回复，也能在你反复翻看日程之前发现时间冲突。
与此同时，这项授权会向智能体打开一张生活地图：你和谁联系、正在筹划什么、什么时候会出现在哪里、哪些承诺最重要。如果它还能发送邮件或修改活动，一次理解偏差就可能离开私人工作区，影响其他人。
所以，真正要问的并不是「这个智能体安全吗」，而是：它能看见什么、能改变什么、什么时候必须停下来，以及断开以后还会留下什么？
本文提供一套具体的判断方法。产品功能和政策会变化，文中的产品示例以 2026 年 10 月 16 日可查到的公开资料为准。
把授权看成阶梯，不要看成一个开关
连接账户时，页面上可能只有一个同意按钮，背后却包含几种影响完全不同的能力。
| 权限等级 | 智能体可以做什么 | 适合首先尝试的任务 |
|---|---|---|
| 读取 | 获取邮件、活动和选定的元数据 | 汇总明日日程，找出等待回复的邮件 |
| 准备 | 创建草稿、活动提案或修改建议 | 起草回复，准备会议邀请供用户检查 |
| 写入 | 发送邮件，添加参与者，修改或取消活动 | 发送已批准的回复，调整一场指定会议 |
| 管理 | 修改规则、委托、共享、保留或账户设置 | 个人助理场景通常不需要开放 |
授权页面上的技术名称，不一定和这张表完全一致。例如，「修改」权限可能远不止生成草稿。展开权限详情，确认应用实际可以执行哪些操作，不要只凭标签判断。
对大多数人来说，合理的起点是「读取并准备」。先让智能体证明自己能够找对邮件、识别人名、理解日历规则，再决定是否让它对外沟通或改动共享记录。我们的个人 AI 智能体使用场景也遵循同一原则：先验证具体流程，再逐步扩大权限。
邮箱和日历暴露的信息比想象中更多
邮箱里的敏感信息不只存在于正文。具体能看到什么取决于连接方式，通常可能包括：
- 发件人、收件人和人际关系；
- 主题、附件和邮件引用的历史对话；
- 发票、行程确认、密码重置邮件和医疗往来；
- 联系方式、签名和保密声明；
- 指向私人文档或已登录服务的链接。
日历则可能包含参与者、活动标题、地点、视频会议链接、活动说明和周期规律。即使标题写得很含糊，只要和地址、参与者以及相关邮件放在一起，也可能暴露具体含义。
两个数据源结合后，影响会进一步扩大。能够同时搜索邮箱和日历的智能体，可能推断出招聘进度、即将开始的旅行、健康预约，或者两个人之间的关系。整合上下文正是这类功能有用的原因，也是「它只读取我的日历」不足以完成隐私判断的原因。
连接账户前，先定义一个真实任务。「帮我管理一切」没有边界，也无法判断权限是否合理；「整理需要我回复的邮件，并检查工作日历中的冲突」则有明确的数据范围、输出和停止点。
授权前需要回答的八个问题
1. 读取和发送能否分开？
查看产品是否分别控制读取邮件、生成草稿、发送邮件、查看活动和修改活动。如果一项摘要功能要求同时开放发送或删除权限，授权范围已经超过任务需要。
有些平台能直接申请较细的权限；另一些平台先获得较宽的服务商权限，再依靠产品内部规则限制行为。后一种情况意味着，你既要信任账户服务商的授权机制，也要信任智能体内部的执行策略。产品应该说清楚这层区别，而不是只展示一个友好的开关。
2. 能否限制到特定账户、文件夹或日历？
如果产品支持，可以先连接次要邮箱、项目标签或一份单独日历，不必一开始就开放包含多年个人记录的主账户。工作账户和个人账户还有不同责任。即使用户可以在技术上完成授权，雇主也可能禁止接入第三方服务。
只开放完成任务所需的最小数据范围。最小权限并非拒绝所有有用功能，重点是不给与目标结果无关的权限。
3. 确认界面是否展示具体动作？
「允许智能体协助处理邮件」不能算一次具体的发送授权。有效的确认至少要展示：
- 最终的收件人、抄送和密送对象；
- 主题、正文和附件；
- 这是新邮件还是对原邮件的回复；
- 将被修改的日历、时区、参与者和活动详情；
- 动作能否撤销。
确认结果还要绑定到这次操作本身。如果确认后又更换了收件人或附件，系统应该再次询问。OWASP 的提示注入防护指南同样建议根据用户权限校验工具调用，并在执行高影响动作前取得人工批准。
4. 操作记录能否让普通用户看懂？
一份实用的审计记录应该回答：智能体读取、建议和修改了什么；动作发生在什么时候；是哪条指令或例程触发了任务。如果用户无法把一串技术日志对应到具体邮件或活动，记录再完整也很难帮助纠错。
还要检查记录中是否包含失败和被拦截的操作，而不只是成功结果。了解记录会保留多久、能否导出。操作历史无法阻止所有错误，却能让修复和责任追溯成为可能。
5. 凭据是否与模型隔离？
与其把密码写进提示词，更合理的做法通常是采用 OAuth 或其他委托授权方式。关键在于：智能体是否通过受保护的工具边界获得有限令牌，还是可以直接读取并复述底层凭据。
凭据隔离也不能自动保证安全。智能体仍可能错误使用一个已经授权的会话。这项设计主要用于限制凭据泄露，并让撤销权限更可行。不要在普通对话中粘贴密码、恢复码或长期访问令牌。
6. 能否立刻停止任务并撤销权限？
在第一次处理敏感任务前，先找到以下控制入口：
- 停止当前任务或由用户接管；
- 在智能体产品中断开应用；
- 在邮箱或日历服务商处撤销连接；
- 关闭可能再次启动的定时例程。
如果智能体界面临时不可用，账户服务商提供的撤销功能是一层重要保障。撤销以后还应检查定时任务是否会安全停止，而不是不断要求新凭据，或改用权限更宽的浏览器会话继续工作。
7. 「删除」具体会删除什么？
断开连接和删除数据解决的是两个问题。断开以后，智能体不应再获取新数据，但下列内容仍可能存在：
- 引用了邮件或活动信息的历史对话；
- 从连接数据中提取的长期记忆；
- 远程计算环境中生成的文件；
- 任务结果和定时任务历史；
- 安全记录或审计日志；
- 按另一套保留周期清理的延迟备份。
逐层寻找对应的删除控制，并阅读当前隐私政策或数据保留说明。「删除对话」「忘记这件事」「清除任务数据」和「删除账户」可能影响不同的数据存储。如果产品没有解释其中差异，就不要把断开账户当成完整删除。
8. 产品如何处理不可信内容？
邮件和日历邀请来自其他人。即使它们进入了你授权的账户，智能体也应该把这些内容视为不可信输入。
攻击者可以在邮件、文档或网页中放入可见或隐藏的指令，诱导智能体把它当成用户命令。Google 在 Gemini in Chrome 安全说明中明确描述了这种风险：恶意内容可能试图让智能体泄露邮箱信息，或把内容发送到外部服务。Google 同时说明，现有防护不能保证覆盖所有风险。
可用的防护包括：把外部内容与用户指令隔离；限制每项工具的权限；在模型之外校验准备执行的动作；为敏感操作保留人工确认。单独依靠一种过滤器，无法让宽泛的账户权限变成零风险连接。
现有产品如何设计权限边界
几款产品已经提供了值得观察的控制方式，但厂商公开说明不能替代独立的安全验证。
Meta Muse。 Meta 表示，用户可以分别决定 Muse 只读邮件还是也能代为发送；凭据存放在 Muse 无法直接读取的安全存储中；发送邮件、购物等敏感动作需要用户确认。其发布说明还提到完整操作记录、应用断连和让 Muse 忘记特定信息的能力。这些都是评估产品时值得寻找的具体机制，但不能保证每项任务都会被正确理解。参见 Muse 发布说明。
OpenAI dots。 OpenAI 表示，dot 的云计算机默认与用户电脑分开，只有用户主动连接后才能使用本地设备。应用权限沿用 ChatGPT 的控制；内置规则和自定义规则决定动作可以直接执行、需要批准还是必须阻止。用户可以通过 Activity View 和计算机查看功能检查工作过程，一些敏感步骤始终由用户完成。OpenAI 也提醒用户，dots 仍可能出错，需要复核重要工作。参见 dots 产品与安全说明。
Google Gemini。 Google 的隐私说明显示，Gemini 任务可能处理 Connected Apps、已登录网站、远程浏览器会话和远程计算机文件中的信息。为了完成任务，必要信息可能与其他服务和第三方共享，用户可以在设置中管理任务数据。这说明一次账户连接可能涉及多个处理环境，并不只是把邮箱内容放进一个聊天窗口。参见 Gemini Apps Privacy Hub。
这里无意给产品贴上安全或不安全的标签。产品若要把风险说清楚，至少应交代明确的数据来源、分开的权限、可见的确认、能检查的操作过程，以及清楚的数据保留控制。
分阶段开放邮箱和日历权限
用户不必在完全不连接和完全自治之间二选一。更稳妥的方法是逐步增加权限。
第一阶段：只读取有限数据
如果产品支持，先连接一份敏感度较低的邮箱、标签或日历。让智能体生成每日摘要或冲突报告，然后检查它是否找对了内容、是否正确处理日期和时区，以及遇到不确定信息时会不会明确说明。
第二阶段：允许准备，不允许直接发布
让智能体生成草稿或提出日历修改建议。重点检查语气、收件人、引用历史、附件，以及私人背景是否被写进不该看到这些信息的人的邮件里。
第三阶段：每次对外动作都确认
只有当确认页面展示最终操作时，才开放发送或修改能力。试用阶段避免群发、首次联系人和不可逆删除。
第四阶段：自动运行一项窄任务
连续多次验证成功后，可以允许一项边界明确的例程，例如向固定成员发送已经批准的会议提醒。同时限制收件人、域名、运行时段和活动类型，并定期查看操作记录。
第五阶段：复查并移除闲置权限
权限很容易越积越多。定期检查连接的应用、仍在运行的例程、已经形成的记忆和任务文件，把不再服务于实际任务的授权移除。
这种做法不能消除所有风险，但可以在用户了解产品真实行为的过程中，控制一次错误造成的影响范围。
哪些情况下不应该连接
设置流程做得简单，不代表你应该立即授权。遇到以下情况可以先停下来：
- 产品要求的权限明显超过任务需要；
- 读取无法与发送、删除或管理权限分开；
- 账户包含客户、患者、员工或受保密义务保护的资料，而你没有权限交给第三方处理；
- 产品没有说明数据保留、模型训练用途或删除方式；
- 影响外部世界的动作不经过具体确认；
- 用户看不到操作过程，也无法立即停止；
- 邮件发错人、时间改错或漏掉附件后，你无法在造成影响前发现。
手动导出、转发指定邮件、使用专用日历或只读的次要账户，有时已经能提供足够上下文，不必暴露整个主账户。正确答案未必是「永远不连接」，也可能是「不要连接这个账户、不要开放这项权限，至少现在不要」。
权限边界本身就是产品能力
邮箱和日历连接之所以有价值，是因为它们让 AI 个人智能体能够跨越多次对话和现实事件保持连续性。它们也会把一个抽象的助理，变成在多人共享系统中采取行动的参与者。
因此，隐私不能被压缩成一枚锁形图标或一次授权。可信的产品设计需要让用户看懂权力边界：读取与写入分开，凭据受到隔离，具体动作会在执行前停下来，操作过程可以检查，访问权限可以撤销，留存数据也能按照清楚的规则找到并删除。
目标不应是获得尽可能多的权限，而是用足够完成明确任务的权限工作，同时让用户始终看得见那条不能越过的线。