在此页面上
个人上下文引擎很有用，因为它可以记住比单个聊天更多的内容。这也是上下文引擎和连接助手之间的界限值得仔细关注的原因。
将 Gmail 连接到 Zortex 和将 AI 助手连接到 Zortex 是两个不同的授权。Google 决定应用程序可以访问哪些 Google API 和记录。Zortex 的授权和策略决定了特定的 AI 集成可以从本地上下文系统接收什么。助手的自身条款随后管理其已接收的信息。
提供商的 API 授权、Zortex 检索授权和接收 AI 的保留策略管理三个不同的步骤。
从收件人开始
任何AI集成的第一个问题是：谁将收到结果？本地运行的助手和托管助手的数据路径不完全相同。两者都可以使用MCP连接，但云支持的主机可能会将返回的内容传输给其模型提供商进行处理。
这 应用程序隐私政策 对此有明确说明。允许的搜索结果、元数据和选定内容可以到达助理主机。本地同步并不意味着后续处理是本地的。主机及其提供商可能具有单独的保留、安全和训练条款。
我们不声称 Zortex 可以擦除独立选择的 AI 提供商已保留的信息。我们不将助手标记为安全，仅仅因为其徽标出现在连接菜单中。
检查授权，而不是营销描述
Zortex 网关包含每个应用的访问控制。授权可以指定哪些保管库路径或记录类型在范围内，以及可以返回多少详细信息。实现区分内容的参考、摘要、压缩和原始形式。其检索范围过滤发生在上下文引擎为该被授权者组装候选之前。
这很有意义：请求项目摘要不应悄无声息地变成允许搜索所有来源中的所有记录。它本身也不够。授予“所有路径、所有类型和原始内容”的权限极其广泛，无论界面如何优雅地呈现它。
在评估连接时，我们使用的问题是具体的：
- 身份： 是哪个应用或主机发出的请求，以及哪个权限授予属于它？
- 目的： 什么任务现在需要这些信息？
- 范围： 有哪些来源、记录类型和内容形式可用？
- 转移： 响应是保留在此设备上还是进入单独提供商的系统？
- 退出： 授权如何撤销，谁可以删除已传输的副本？
这五项检查确定了接收方、目的、权限范围、传输路径以及停止进一步访问的方式。第三方保留仍受接收服务管辖。
网关旨在强制执行什么
MCP 请求在接收上下文之前到达集成边界。适用的访问控制可以通过路径和记录类型缩小候选检索范围。然后，结果具有内容形式上限。网关公开授权信息，以便连接的客户端可以检查其有效范围。
Assistant request
|
v
App identity + active grant
|
v
Source/kind scope --> Relevant local retrieval --> Content-form limit
|
v
Assistant host
(provider terms apply)
数据处理边界的解释图；实际访问取决于服务和权限。
这 生成的几何封面 可作为矢量插图。
接收引用与接收其底层内容之间仍然存在重要区别。引用仍然可以揭示标题或关联。简短的摘要可以包含个人的姓名。限制形式可以减少暴露，但不能等同于保证没有敏感信息越过边界。
区分行动与答案
询问“我们决定了什么？”的助手与要求 Zortex 发送或修改内容的助手不同。底层的 Google 权限设置了外部 API 功能：例如，日历声明是只读的，而 Gmail 和云端硬盘声明包含更广泛的范围。Zortex 的操作处理和授权策略仍必须管理特定请求可以执行的操作。
有用的审查问题不仅仅是助手“是否有访问权限”。而是它是否有正确的访问权限 对于这项任务，以这种形式，在这一刻。支持的操作取决于特定的主机、当前授权和请求的操作。
披露后的责任
Zortex 承诺不出售 Google 用户数据，不将其用于定向广告，也不将其用于训练通用模型。该承诺涵盖 Zortex 自身的处理和适用的传输；它不会自动重写独立选择的提供商的条款。我们的集成必须与我们的 Google 数据承诺保持一致，用户也应审查他们选择的提供商。
撤销 Zortex 授权可以阻止通过该授权进行的未来披露。它不会撤回已交付给托管模型的答案。用户可能还需要使用该提供商的删除控制。
窄的、可审查的访问权限始于可识别的来源、主机和内容形式。 应用程序隐私政策 记录披露、撤销和保留规则。
来源：产品实施和 应用程序隐私政策，于2026年10月9日审查。
