AI 助手服务整个群组时，究竟在使用谁的授权？

想象一个家庭助手：家长把学校邮件转给它，它便建立日历事项；另一位家长在家庭简报里看到提醒；助手还记住某人的饮食偏好，用于下周的菜单。演示很顺畅，但上线前真正要回答的是：每一步依据的是谁的授权？ 如果最初转发邮件的人退出家庭群组，另一位家长还能看到邮件摘录、日历描述和那条饮食偏好吗？

Google Labs 在 2026 年 9 月公布了面向家庭和群组的新版本 CC。Google 称，每个 CC 有独立账号，最多六名成员可协作，各人自行选择共享内容，助手区分群组记忆与个人记忆，对外行动或分享需要许可。这些是 Google 对实验产品的说明，不能据此认定所有边界情况都已解决。官方目前将其定位为美国地区、使用个人 Google 账号的成年用户可参与的实验。

对正在开发团队、家庭、课堂或客户协作助手的创始人，关键判断是：信息每跨过一道边界、产品每产生一次对外效果，都要有对应的权限决定；入群时一次笼统同意远远不够。 助手拥有自己的身份有利于追责，却不能因此混合所有成员的私人信息。本文给出六项发布约束、一个学校报名场景、一组失败测试，以及可直接复用的评审表。它适用于汇集多个人私有输入的产品；并不要求小团队复制 Google 的基础设施，也不能替代针对具体地区的法律判断。

独立账号说明“是谁”，不说明“能做什么”

Google 对 CC 的介绍中，一个值得注意的设计是助手拥有经过验证的独立账号。群组成员可以辨认是哪位“参与者”发了消息、改了事项；产品也能把权限和审计记录挂在这个身份上。更关键的是，Google 称 CC 只能看到成员自行选择共享的内容。创建群组的人，并不该因为拥有“管理员”身份，就把整个邮箱自动交给助手。

这里要分清两个术语。身份认证回答请求者是谁；授权回答这个请求者此刻能否对这份具体资源执行这个具体操作。OWASP 授权检查指南建议默认拒绝，并对每次请求核验权限。机器人有独立邮箱，仍可能被授予过大的权力；成员已登录，也不代表他能查看另一位成员上传的文件。

在产品模型里，应把助手当作一个单独的主体，只赋予有限能力，而不是把它当成邀请人的万能替身。至少记录：谁提供来源、来源对象是什么、共享给谁、谁发起操作、谁批准操作。几个人不同的时候，界面和日志也要如实显示，不能一律写成“群组所有者授权”。

日常小事就会用到这层区分。邮件本身可以保持私密，邮件中的活动时间却可以进入共享日历。简报可以提醒“周五之前交表”，不必转述表格里的健康信息。助手可以先填写报名草稿，最后提交则由有资格的家长确认。即使“一键全部共享”更容易开发，产品仍应提供这些范围更窄的结果。

先画清一项任务会穿过的五道边界

拿一个最具代表性的工作流，依次画出五道边界。第一道是接入：哪位成员主动交给助手哪份资料？第二道是提取：助手可以从中保存哪些事实？第三道是受众：哪些事实能进入简报、聊天、日历或搜索结果，给谁看？第四道是行动：谁能批准修改外部系统？第五道是保留：授权变化、成员退出或任务结束后，什么内容还可以留下？

它们彼此相关，却不能互相替代。允许读邮件，不等于允许把原文发给六个人。允许写草稿，不等于允许寄给学校。今天能显示一条信息，也不等于以后可以永久保存在记忆里。所谓“撤销授权”，如果只阻止新的读取，却让过去复制的摘要继续被其他成员检索，对用户而言是不完整的。

Google 的公告列出几种输入方式：选择持续共享的发件人、临时转发一封邮件、共享 Drive 文件或文件夹、把 CC 加到日历。风险各不相同。一次性转发天然对应一份对象；发件人规则会覆盖未来尚未看到的邮件；文件夹后来可能增加内容；日历连接会暴露时间、地点和参与者。界面与权限台账应把它们拆成不同的授权，而非统一显示为“已连接邮箱”。

NIST AI 风险管理框架的核心部分强调：在真实使用情境中明确人和 AI 的职责、隐私要求以及人工监督。它没有规定上述“五道边界”。这是本文给产品团队的操作化方法：让评审者能够追溯每一步由谁决定，依据哪份授权。

同意共享时，要说清范围、去向和期限

“连接邮箱”四个字掩盖了三个问题：范围——读哪些邮件；去向——提取出来的信息会出现在哪里；期限——只处理一次、持续处理某个发件人，还是长期连接整个服务。可信的授权界面应在接入前，用普通用户看得懂的话说明这三点。

Google 的 OAuth 政策要求使用其 API 的应用申请实现功能所需的最小权限，并按告知用户的用途使用数据。但平台的 API 权限并不等于完整的群组共享规则。应用即使只拿到 Gmail 的只读权限，也可能错误地把私人邮件内容放进群组简报。外部 scope 限制连接器能做什么；应用自身仍须按对象和用途控制谁能看到结果。

例如，界面可以写：“共享来自 school.example 的邮件，用于提取活动日期和用品要求；关闭前持续处理该发件人的新邮件；完整邮件仅你本人可见，除非你另行共享。”一次性模式可以写：“只使用这张邀请函建立群组活动，不把附件保存为群组记忆。”这些是建议的产品文案，不是 CC 实际界面的描述。

授权之后也要能找得到、改得动。用户应能查看哪些来源仍在启用、上次何时被使用、产生了哪些输出，以及如何停止未来处理。容易开启、难以定位的授权，控制权只是名义上的。如果连接器扩大了权限，或产品增加了新的输出位置，应重新呈现相关选择，不要把旧授权当成无限空白支票。

用一封学校邮件走完整条决策链

设想一个虚构产品，名叫 Household Desk。Maya 转发学校关于周六游泳课的邮件，里面有报名截止日期和 PDF 表格；附件还包含孩子的健康备注。她的伴侣 Lin 在同一个家庭群组。助手建议建立共享日历提醒，预填 PDF；它又从 Maya 另一条信息里看到“避免花生”，准备写进全家的饮食偏好。

接入阶段，Maya 的转发只允许助手为约定目的处理这一封邮件，不代表它可以扫描她邮箱里的其他内容。提取阶段，报名截止日期若面向全家，可以变成共享待办；健康备注则需要更严格的可见标签：填表可能用得上，但不该自动进入家庭简报。行动阶段，预填只是一份草稿；把 PDF 交到群组之外，需要有权决定的人另行批准。记忆阶段，饮食偏好应记录来自 Maya、允许谁看，以及何时复核或到期。

接着改变条件：Maya 撤回那封邮件并退出群组。日历事项、PDF 附件、提取出的截止日期、饮食偏好分别怎样处理？如果日历事项此前另经明确的群组授权，产品也许可以保留；仅依赖已撤回私人来源的原文和提取事实，则应删除或隐藏。具体留存选择取决于产品承诺及适用义务。上线前必须把依赖关系说清；如果从未记录来源与授权，事后新增一个 deleted_at 字段，也无法补回出处。

这个案例不是对 Google CC 实际行为的描述，而是一份共享助手的测试样本。它之所以有用，恰恰因为“任务完成”和“侵犯隐私”可能同时发生：家庭收到正确提醒，简报却泄露健康备注；或者表格未经审核已被提交。

群组记忆必须带着出处和可见标签

Google 在 CC 公告中称，助手能够区分整个家庭适用的信息与属于个人的信息。这个承诺重要，因为持久记忆会扩大一次披露的后果。在某段对话里看似无害的一句话，几周后可能出现在另一位成员的回答中。

因此，记忆条目不能只有一段文字，还要包含来源对象、提供者、提取时间、用途、受众、可信程度、复核日期和删除依赖。这里的出处，指能把保存的事实追溯到输入与授权。如果一条事实已经失去出处，就不该被提升为长期群组记忆。否则无法区分“Lin 明确告诉全家喜欢哪家餐馆”和“模型从 Maya 的私人收据里推测全家喜欢哪家餐馆”。

可以设四类记忆。个人事实默认只为本人服务；群组事实经明确同意后对成员可见；任务事实在某项工作完成或过期后退出；待核实推断只能供人确认，不能悄悄变成固定偏好。模型给出的高置信度，也不能替人决定这条信息该共享给谁。

OWASP 的 2025 年大模型风险清单分别列出敏感信息泄露、提示注入和过度自主行动。它们在群组记忆里可能串起来：恶意文件命令助手写入假的“家庭偏好”；私人事实随后被错误成员取出；工具又依据它执行操作。因此，外部文档的文字不能充当权限指令；记忆在使用前必须带标签；检索测试要换用不同成员的身份执行。

审批应绑定真实操作，而不是一句聊天回复

助手可以在对话中问“我来处理好吗”，但审批必须绑定到具体效果：目标服务、接收方或资源、要提交的数据字段、相关价格或承诺，以及草稿的准确版本。如果审批后助手改了关键字段，先前的同意就不该继续有效。

OWASP 关于过度自主行动的说明举例展示：拥有读信和转发能力的 Agent，可能被恶意来信引导做出不该做的事。普通家庭邮件里也可能混入与任务无关的指令。可靠的架构应在真正执行操作时，由常规程序再次核对权限，而不是相信模型说“这样做合适”。OWASP 的业务逻辑安全指南同样建议每次请求都在服务端重新检查资源归属和与安全有关的数值。

界面要分清三个状态：已提出、已批准、外部系统已确认。预填表单只是提出方案；家长针对固定版本的表单点击同意，才是批准；拿到学校系统的回执，才叫确认。助手写一句“完成了”不算证据。如果提交后学校门户超时，应显示状态未定、先核实再重试；盲目重试可能产生重复报名或付款。

影响较小的事项可以允许有限的长期授权，例如只向家庭待办表添加草稿提醒。向外部披露信息、付款、健康表格或不可逆修改，则更适合让具名的人核准确切操作。这是产品政策建议，不是适用于所有地区的统一法律规则；门槛要按实际业务后果调整。

撤销授权是一条流程，不能只是一个开关

成员会改变主意：孩子换学校、承包商离开客户群组、共同创始人退出，或者过去可信的发件人开始发送敏感内容。撤销应立即停止新的采集，使依赖该授权而尚未执行的审批失效，并触发对派生内容的检查。它还要能测试：撤销后，分别以留下的每个成员身份重试查询和操作。

系统需要区分撤回来源与群组成果的归属。Maya 撤回源邮件后，产品可能必须清理邮件摘录和仅据此生成的私人事实。但另经她同意、已经成为群组事项的日历事件，依据可能不同。不要只看数据类型就决定去留；应记录每个派生结果由哪项授权支撑。若一条任务记录混合私人和群组事实，应只用仍获授权的事实重建，或者先隐藏，交由人处理。

撤销 API 权限也只是其中一层。Google OAuth 政策谈到移除不再需要的权限与令牌；产品还须处理缓存文本、向量、摘要、已经发出的通知，以及已经发生的对外操作。有些效果无法收回。界面应明确区分“停止未来访问”“删除保存副本”和“过去已经发送”，只承诺能够验证的控制能力。

如果应用依赖邮箱变更通知，还可注意 Google [Gmail users.watch 文档](https://developers.google.com/workspace/gmail/api/reference/rest/v1/users/watch)：监听可以按标签过滤；不设过滤条件，就无法通过这个机制限定变更范围。API 过滤不能代替逐封邮件的产品权限判断，但可以少接入一部分不必要的事件。

可复用的单项工作流权限合同

上线前，让产品负责人、工程师和隐私评审者对每条工作流填写一张表。表格只是设计与复核工具，不能代替代码里的权限执行。下面仍使用虚构的学校报名场景。

每一行再附一份简短决策记录：负责人、当前行为、测试证据、尚存限制，以及上线、限量或暂缓结论。不要因为模型回答得得体，就把项目标成通过。真正的问题是：越权读取、泄露、错误写入记忆或未经批准的操作有没有被技术手段挡住。NIST 的生成式 AI 风险管理资料将风险管理视为贯穿生命周期的活动；这张表把原则落到共享 Agent 的发布讨论中。

测试那些演示流程不愿展示的组合

两个友好成员顺利完成任务，只能提供很弱的上线证据。还要测试新成员、已移除成员、撤回的来源、被修改的附件、转发邮件里的恶意指令，以及外部服务报出模糊超时的情况。加入这样一例：某人允许助手处理对象，却拒绝向群组共享从中得出的某个事实。再加入一例：API 凭据理论上能读取对象，但应用自己的受众规则必须拒绝这次访问。

准备两套判定依据。授权判据检查应用记录：来源、请求者、受众、当前授权、操作范围。结果判据检查权威状态：谁实际收到了简报、改了哪个日历、表格是否真的提交、哪些记忆还可检索。模型生成的解释两者都不算。这种区分能抓住一种危险错误：助手在聊天里礼貌地拒绝透露秘密，后台摘要任务却已经把秘密发给全组。

通过条件必须描述行为。例如：“Maya 撤回转发邮件后，Lin 不能通过聊天、搜索、每日简报或导出的日历描述，取得附件及未经批准的摘录。”然后逐个入口测试。如果产品无法删除过去已经送达的外部消息，就在界面说明限制，并验证不会再发送新的副本。

早期团队可以从少量人工审核的案例起步，不必先造复杂基准。固定场景和预期结果；连接器、提示词、记忆逻辑或成员管理变化后重跑；保存判定回执。真实事故或支持请求暴露新边界时，再补案例。目的在于验证对用户的承诺，而不是堆测试数量。

创始人的最终选择：上线、限量还是暂缓

小范围上线的条件是：每份测试来源都有看得见的授权；共享输出严格遵守受众标签；高影响操作的审批绑定准确效果；撤销能阻止未来访问；独立回执与界面说法一致。试点仍可限制连接器、成员数量和可执行操作。可靠的窄流程，比权限全靠提示词维持的“万能助手”更有用。 限量开放适用于价值确实存在，但一道边界尚不确定的情况。比如应用能创建草稿和提醒，却无法可靠确认第三方门户究竟收到了什么，那就让人手动提交。又如群组记忆尚不能准确撤销，就先做会话内记忆，或要求每条共享事实经人确认。明确告诉用户哪一步仍须他们审核。 暂缓上线适用于：一名成员能让助手透露另一名成员未共享的来源；撤回后，资料仍可通过次要入口检索；对外操作没有绑定审批就发生；或界面没有外部回执却显示“已完成”。模型话术再合理，这些也仍是产品失败。

Google 的 CC 公告带来的启发，不是每位创始人都该做家庭 Agent。一旦助手服务不止一个人，“有帮助”就必须落实到每个人、每份来源、每个受众和每次效果。人们能看懂它知道什么、为何知道、谁会看到、接下来能做什么，协作的便利才有可信的基础。

参考资料

• Google Labs：面向家庭与群组的新 CC
• NIST：AI 风险管理框架核心部分
• NIST：生成式 AI 风险管理资料
• OWASP：授权检查指南
• OWASP：业务逻辑安全指南
• OWASP：大模型应用十大风险
• OWASP：过度自主行动风险
• Google：OAuth 2.0 政策
• [Google：Gmail API users.watch 文档](https://developers.google.com/workspace/gmail/api/reference/rest/v1/users/watch)