PAYATHON 2026

Google Drive ‘All’ data store：覆盖整个工作区还是受创建者权限限制？

技术老齐

All 指工作区范围，实际结果受查询用户权限限制

在这里使用的 Google Drive 联合检索（data federation）连接器中，All 表示将所连接 Google Workspace 的所有云端硬盘纳入搜索范围。官方创建指南的表述是：“To add all drives in the workspace to the data store.” Google 官方创建指南

用户实际能检索到哪些文件，取决于查询身份和文件访问权限。正确配置身份认证与数据源访问控制后，系统会根据最终用户的身份，判断其是否有权访问结果中的文档。数据源访问控制说明

理解是否准确
每位用户可以检索自己有权访问的 Drive 内容基本正确，但仍受连接器范围、文件支持情况等限制
只能检索该用户与 data store 创建者都有权访问的内容不能作为这一连接器的通用规则
每位用户都能读取整个工作区的文件错误，All 不会向用户授予额外的文件权限

为什么创建者无权访问，第二个用户却能查到？

这个连接器通过 data federation 直接从 Google Drive 检索信息，不会将 Drive 内容复制到 Agent Search 的索引中。创建时，它使用 Google Workspace customer ID 连接相应的 Workspace。Google Drive 连接说明

因此，不能把它理解为“先读取创建者能访问的文件，再让其他人搜索这批文件”。假设文件在连接器支持的搜索范围内，账号 A 创建 data store，账号 B 发起查询：

  • A 无权访问、B 有权访问：B 可以检索到该文件，符合按最终用户权限控制结果的机制。
  • A 有权访问、B 无权访问：A 的权限不应让 B 获得该文件。
  • A、B 都有权访问：两人均可检索，但不保证任意自然语言问题都能命中文件。

题述测试支持这一判断：创建者的访问范围不是该配置的检索上限。验证时，还应确认 agent 返回了目标文件的引用或检索片段，以免把模型生成的回答误当成成功读取文件。

“drives in common”不能作为当前配置的通用解释。不过，单次测试既无法确定这句话最初适用的连接方式，也无法证明 Google 在某个版本修改过行为。没有对应的官方变更记录，就不宜给出具体的变更时间。

如何理解“将你的整个云端硬盘添加到 data store”

“你的整个云端硬盘”容易混淆两个问题：

  1. data store 的搜索范围有多大？
  2. 某个用户有权看到其中哪些内容？

All 决定搜索范围，查询用户的身份和文件权限决定其能看到哪些内容。结合官方定义，这段界面说明可以理解为：

将所连接 Workspace 的全部云端硬盘作为搜索范围，并按查询用户的访问权限返回结果。

这里的“添加”也不代表完整复制文件。联合检索连接器会向 Google Drive 发起查询，再将结果与其他数据源的结果合并。查询执行说明

如何核对实际配置

先检查应用是否识别了正确的最终用户。在浏览器里切换账号，并不能证明后端检索身份也已改变，还需要检查实际请求使用的认证凭据或连接器授权账号。Google 的设置文档要求配置身份提供方，以执行数据源访问控制。身份与访问控制配置

然后用两个独立会话做对照测试：

  1. 准备一个仅 A 可访问的文件、一个仅 B 可访问的文件，以及一个双方均可访问的文件。
  2. 在各文件中放入不同的独特检索词，分别以 A、B 的身份查询。
  3. 检查返回的文件链接、引用和检索片段，不能只看回答是否流畅。
  4. 核对 Drive 的共享设置，包括群组授权、共享云端硬盘成员资格和组织范围共享。

如果需求是“应用只能搜索某个团队目录”，应直接配置搜索范围。界面中的 Specific shared drive(s)、Specific shared folder(s) 可以用来指定范围；新版连接器还提供共享云端硬盘和文件夹的 Include、Exclude 过滤配置。已有 data store 会继续使用原有范围配置，调整前应核对实际设置。范围过滤配置

代码示例：分别检查两个账号能否读取目标文件元数据

可以使用 Drive API 的 files.get 辅助核对账号权限。下面的请求需要目标用户通过 OAuth 授权取得的 access token，例如包含 https://www.googleapis.com/auth/drive.readonly scope 的 token。files.get API 文档

DRIVE_ACCESS_TOKEN='USER_OAUTH_ACCESS_TOKEN'
DRIVE_FILE_ID='TARGET_FILE_ID'

curl --get \
  "https://www.googleapis.com/drive/v3/files/${DRIVE_FILE_ID}" \
  --header "Authorization: Bearer ${DRIVE_ACCESS_TOKEN}" \
  --data-urlencode 'supportsAllDrives=true' \
  --data-urlencode 'fields=id,name,mimeType'

保持 DRIVE_FILE_ID 不变，分别使用 A、B 的 token 执行请求。如果成功返回元数据，就能确认对应的用户凭据可以通过 Drive API 访问该文件的元数据。

这个请求没有测试 agent 的检索链路，也没有读取文件正文。如果请求失败，应根据错误响应检查 token、OAuth scope、文件 ID 和共享权限，不能仅凭失败就认定用户没有文件权限。supportsAllDrives=true 仅声明应用支持 My Drive 和 shared drives，不会扩大访问权限。

注意事项

有权访问文件，并不保证能够搜到。官方联合检索说明列出了文件归属域的限制；新版 Gemini Enterprise 设置页另有跨域文档功能入口。外部组织共享来的文件是否可检索，需要结合实际连接器和跨域配置确认，不能仅凭 All 判断。连接器限制与跨域设置

不要通过给 data store 创建者补齐所有文件权限来实现全员搜索。应先确保查询身份正确，再按业务需要配置检索范围和 Drive 文件权限。

备注：内容仅供参考。