在此页面上

将 AI 连接到电子邮件看起来像一个决定:授予权限,助手就可以行动。该屏幕并未描述数据可能被处理或保留的每个位置。权限、凭据保管、执行日志和模型输入是独立的事件。

Composio 提供 AI 代理和连接应用程序之间的基础设施。其工具管理身份验证并针对 Gmail、GitHub 和 Slack 等服务执行请求。对于使用基于 Composio 构建的代理的人来说,实际问题与其说是集成是否可以授权,不如说是授权后会发生什么。

本次阅读使用 Composio 的 隐私政策,生效日期 2025年11月18日,及其 服务条款,两者都读作 2026年10月9日。当前的条款页面没有显示生效日期,尽管其修改条款提到了一个。一个 旧条款网址 显示 2024 年 1 月 1 日;该日期不应悄悄地分配给当前页面。该分析还使用了 Composio 的 数据保留文档, 零数据保留指南, 令牌托管指南,和 数据处理附录,最后更新于2026年9月2日。

有两个人需要区分。Composio将其基础设施的开发者或购买组织称为其 客户。该开发人员连接的邮箱或工作区的所有者是 最终用户。两者可能对设置、合同和删除控制有不同的访问权限。大多数人会遇到连接;开发人员操作项目。

这种连接使Composio在交易中扮演了角色

隐私政策的收集部分涵盖用户提供的信息,包括“姓名、电子邮件地址”,以及访问平台时收集的技术信息:IP 地址、浏览器类型、操作系统、标识符和使用模式。它还提到了会话、性能、分析和某些第三方 cookie。这是帐户和设备层,与邮箱内容不同。

更重要的层面是身份验证。Composio的 令牌托管指南 声明,在其默认托管部署中,Composio持有提供商凭据。它代表个人交换或刷新凭据并验证工具请求。开发者的应用程序通常使用标识符和工具参数,而不是持有底层提供商令牌。Composio记录了静态和传输中的加密,以及连接账户API响应中的令牌屏蔽。

凭据可以保持屏蔽状态,而请求及其结果仍然通过Composio的执行服务。

这 数据处理附录,在附件2中,明确描述了身份验证凭据、代理从连接应用程序读取或写入的信息,以及工具调用元数据和有效载荷作为处理中涉及的数据类别。其示例包括通信、日历条目、文件和业务记录。它们还可能包含从未安装Composio的人的信息:通信对象、会议参与者和联系人。授予收件箱访问权限的人不能通过连接器屏幕向这些第三方授予单独的同意。

请求、结果和日志遵循不同的路径

该图遵循文档化的托管执行。模型不需要接收凭据,但开发人员可以随检索到的内容一起提供凭据。

托管连接授权、Composio凭证保管、第三方工具执行和可选数据保留路径。

图表:Composio 记录的授权、凭证保管、工具执行和保留路径。 · 查看原始封面插图

Person -> developer's agent -> Composio execution -> connected app
              ^                   |      ^               |
              |                   |      |    result       |
              +----- result ------+------+<--------------+
              |
              +-> chosen AI model (if the agent sends content)
                                   
                  Composio: execution logs by default
                  Optional: file staging, triggers, sandbox
                  Others: provider, model, developer's own logs

这 数据保留指南 表示执行日志包含识别工具和相关连接的元数据、开发人员提供的用户 ID、状态、时间和运行时。它还在存储内容下列出了“默认情况下,每个工具执行的请求参数和响应数据”。在邮件读取操作中,请求参数可能识别邮件或搜索;响应数据可能包含其内容。屏蔽的 OAuth 令牌不会从日志中删除这些内容。

根据该指南,执行和触发日志会保留“最长一年”。这是一个最长保留窗口,而不是声明每条记录都精确保留十二个月。广泛的隐私政策对个人和使用数据使用“仅在必要时”的短语。技术文档为执行日志类别提供了更有用的数字。

文件有另一个生命周期。Composio 描述了工具在临时对象存储中使用的或返回的暂存文件。下载 URL 通常在一个小时后过期,最长可配置为二十四小时;链接过期不表示底层文件被删除。暂存文件在“24 小时后”删除;某些非文件沙盒状态可能在大约十二小时不活动后清除。这些窗口涉及临时执行材料。它们不会将一年日志窗口转换为二十四小时规则。

隐私政策单独规定了 YouTube API 数据的最长三十天保留期和刷新或删除周期。将该 YouTube 特定的承诺解读为每个连接应用程序的保留规则是不准确的。

零保留涵盖了什么

Composio 具有零数据保留 (ZDR) 设置。 当前ZDR指南 表示受覆盖的工具调用和代理执行请求可以在不保留其参数、返回数据或执行日志中的错误文本的情况下运行。审计元数据仍然存在。该选项作为付费附加组件提供,并包含在企业版中。它不适用于业余计划的新激活。在除企业版之外的付费计划中,即使其他项目已启用 ZDR,新创建的项目也默认禁用 ZDR。

措辞还设定了一个界限:“ZDR仅适用于新调用。”开启它不会删除早期的执行负载。这些负载保留长达一年的标准窗口。此外,文档指出,“ZDR仅涵盖通过Composio托管应用程序的企业计划调用。”Instant Tools背后的托管账户可能受单独提供商的保留政策约束;触发器继续保留事件以供交付;文件处于暂存状态;沙盒有其自己的状态;搜索查询可能被缓存。即使在ZDR下,Composio仍保留审计日志和服务遥测。其提供的用户ID、账户关联和工具/时间信息仍然是重要的操作元数据。

因此,对于开发人员来说,问题是哪个项目发出了调用,它使用了哪种身份验证配置,ZDR 是否涵盖了该调用,以及哪些可选功能处理了其材料。对于最终用户来说,问题更难:授权 Gmail 的人可能永远看不到回答该问题的项目设置。

数据或操作 标准 Composio 云 ZDR for covered calls 对人的区分
OAuth 凭据 由 Composio 以托管模式持有和使用 托管身份验证仍需要 加密和屏蔽不意味着本地保管
工具请求和结果 默认记录有效载荷,包含审计元数据 从覆盖的新日志中省略的有效载荷 现有日志不会被追溯删除
执行和触发日志 最长一年 审计元数据保留;触发事件仍被处理和存储 内容和元数据有不同的规则
已上传或返回的文件 临时对象存储;24 小时后删除 文件暂存不在 ZDR 覆盖范围内 短时下载链接并非立即删除
模型和目标提供商 接收在执行过程中提供给他们的数据 受其自身政策管辖 一个供应商的开关不设定另一个供应商的保留策略

该表描述了Composio的机制,而不是基于它的每个代理。开发人员单独决定哪些结果到达模型以及他们自己的系统保留什么。

共享承诺有一个特定的主题

Composio 的隐私政策对 Google 用户数据做出了明确承诺。在第 3 节中,它声明不会“使用 Google 用户数据来构建或改进机器学习或 AI 模型”。它还限制了广告、销售和共享,同时允许为提供平台核心功能所必需的传输。这些是重要的限制,应按字面理解:该节明确涉及 Google 用户数据.

同样的政策规定,Google 数据用于集成服务。但这并不意味着没有服务会处理结果,或者 AI 代理在不接收相关内容的情况下也能工作。在 令牌托管指南,Composio 表示模型会看到工具定义以及应用程序或客户端选择提供给模型的结果。在 数据流文档,目的地提供商、执行基础设施、可选的第三方沙盒、配置的触发目的地和选定的模型提供商都可能作为参与者出现。提供商自己的隐私政策管辖该提供商内部发生的事情。

这种区别在Composio中变得更加清晰 合规指南,最后验证于2026年8月12日:“不要推断全面的无训练保证。”该指南指示需要关于训练和保留的端到端合同条款的客户转向企业版。这并非断言Composio会训练人们的Gmail消息;Google特定的禁令另有说明。这意味着已发布的材料不保证关于每个应用程序、模型提供商、托管账户或下游执行路径的无条件声明。

Composio 的 数据处理协议 对二次处理提供了单独的限制。它将开发人员客户描述为控制者,将Composio描述为处理者,将使用限制为服务提供和文档说明,并提供了子处理者框架。其公开页面称:“除非客户通过Composio仪表板接受,否则本DPA不具有约束力。”DPA可供Pro和企业开发人员客户接受。使用他人代理的消费者不应假定该消费者个人接受了DPA或选择了模型提供商。子处理者信息指向Composio的 信任中心;该列表可能会更改,并且与隐私政策中针对 Google 的特定语言是分开的。

这些条款授予许可;它们并未解决所有数据问题

这 服务条款,第8节,首先声明用户保留用户内容的所有权。然后,他们授予 Composio 对在平台或通过平台提交、发布或显示的用户内容的“全球性、非排他性、免版税、可再许可和可转让的许可”,用于“与平台和 Composio 业务相关的用途”。这些是广泛的法律许可,即使所有权仍归用户所有。对于涵盖的用户内容,该许可允许复制、分发、改编、显示和执行,以及再许可或转让。

重要的是不要将该条款扩展到其定义的范围之外。条款中的短语 用户内容 没有明确解释从外部账户读取的每个字节是否都算作使用服务的人提交或显示的内容。许可执行平台相关行为本身并不能证明邮件数据或 AI 训练的销售。隐私政策的 Google 条款以及(如果接受)DPA 对某些处理施加了更具体的限制。通用许可的范围仍然是一个值得与任何一个工具实际操作方式区分开来的问题。

第 9 条允许 Composio 自行决定“不事先通知或承担责任”地暂停或终止,并规定性质上在终止后仍然有效的条款将继续有效。第 13 条赋予 Composio 共同营销权,以识别客户,包括其名称和徽标。这指的是商业客户,不一定是指其处理的每个连接账户的个人。这两条条款都没有描述不同提供商持有的所有副本的自动删除时间表。

当前页面承诺通知重大变更,但未显示生效日期。因此,审查日期很重要。

删除是一个序列,而不是一个按钮

隐私政策列出了访问、更正、删除、撤回同意和获取个人数据副本的权利。第 8 节规定 support@composio.dev 作为请求的联系人;该部分未公布通用的周转时间。对于与 YouTube 相关的数据,它还描述了按请求立即删除。

开发者可以通过 Composio 的 v3.1 API。这会阻止连接用于进一步的 API 调用。同一参考提供了一个可选的 revoke_on_delete=true 参数以开始上游令牌撤销,默认为 false。因此,删除连接器记录和取消 Google、GitHub 或其他应用程序的授权是独立的操作。在提供商自己的设置中撤销提供商授权是一个有用的独立步骤。

组织管理员还可以使用 组织删除控制。Composio的帮助页面称其警告涵盖了永久删除项目、连接账户、密钥和日志。这与删除一个连接账户的范围不同。Composio建议在必要时单独处理上游授权。通过其他公司的产品连接的人可能没有Composio组织的管理员访问权限。

当DPA适用时,第2.5节要求Composio在服务结束后“删除或返回”个人数据,但受法律保留义务的约束。同时,技术ZDR页面解释说,关闭有效负载存储会影响新调用,而将以前的日志保留在其现有保留期内。这些机制都不能让最终用户直接控制已交付给模型提供商、外部应用程序或开发人员自己的日志存储的材料。向这些方提出的请求可能需要单独的程序。

对于决定是否授权连接的人来说,问题是具体的:谁持有凭据?哪些工具参数和结果被记录,在谁的项目设置下?连接撤销后还剩下什么?这些文档提供了部分旅程的答案,但没有一份文档是整个旅程。

当用户保留上下文时会发生什么变化

隐私优先的架构首先减少保管人的数量。它可以将个人工作的持久模型保存在该个人的设备上,并且只向选定的 AI 发送完成任务所需的最小上下文。个人选择助手和访问范围;日历查找不应成为无关模型搜索邮箱的权限。本地历史记录的保留和每个 AI 访问的撤销可以向所有者公开,而不是隐藏在开发人员仪表板中。

边界是具体的。第三方应用程序会看到发送给它的请求。云模型会看到发送给它的内容。如果启用了远程执行,则必须有人处理请求。本地优先设计不会消除这些交互。它改变了默认保留的内容、必须离开个人计算机的数量以及谁可以检查或终止授权。

该测试在普通会话结束时可观察。消息检索并使用后,中间人的执行日志中是否存在持久副本?下一个模型是获取整个消息还是有限的答案?当用户断开帐户时,他们能否看到已删除的内容、已停止访问的内容以及仍保留在其他地方的内容?这些是隐私政策应明确的界限。

来源审查:2026 年 10 月 9 日。引用的条款逐字摘自链接的 Composio 政策和技术文档。