如何查看哪些 AI 工具能访问您的 Google Workspace
您可以在管理控制台的 Security → Access and data control → API controls → App access control 中，查看每一个拥有 Google Workspace OAuth 访问权限的 AI 工具。该页面会列出您域中已获授权的所有第三方应用——包括 AI 助手、浏览器扩展程序和会议记录机器人——以及每个应用被授予的 Google 数据权限。
本指南将带您了解该路径、控制台实际显示的内容、其局限所在，以及如何在获取列表后保持其时效性。
我在 Google 管理控制台的哪里可以找到第三方应用访问权限？
- 以超级管理员身份，或拥有 Services 权限的管理员身份登录 admin.google.com。
- 前往 Menu → Security → Access and data control → API controls。
- 点击 Manage App Access（在某些控制台版本中标注为 App access control）。
您会看到一个分为两部分的列表：Configured apps（贵组织已明确设置访问级别的应用）和 Accessed apps（当前正在使用的所有应用，无论是否已配置）。对每个应用，您可以看到：
- 应用名称、发布者及 OAuth 客户端 ID。
- 是否带有 Google 的应用验证标志。
- 该应用请求的各项 Google 服务权限范围——Drive、Gmail、Calendar、Admin Directory 等——可按应用展开查看。
- 域中已授权该应用的用户数量。
- 可设置的访问级别：Trusted、Limited、Specific Google data 或 Blocked。
您还可以将完整列表导出为 CSV 文件，并可针对不同的组织单位（而非一次性针对整个域）设置不同的访问级别。
我如何辨别这些应用中哪些是 AI 工具？
Google 的控制台不会将任何应用标记为"AI"——无论是电子表格插件还是大语言模型助手，它都以相同方式列出每个已连接 OAuth 的应用。实际上，AI 工具会以以下形式出现：直接的 AI 供应商名称（OpenAI、Anthropic、Perplexity）、会议记录机器人（Otter.ai、Fireflies、Fathom）、写作助手（Grammarly、Jasper），或者是发布者名称完全看不出功能的细分插件（"GPT for Sheets and Docs"、"AI Email Writer"）。识别这些应用需要人工进行模式匹配：浏览应用和发布者名称，并检查请求的权限范围——如果某个您不认识的应用请求了 drive.readonly 或 gmail.readonly，无论其类别如何，都值得进一步留意。
我如何查看某个特定用户授权了哪些 AI 工具？
上述的域范围视图会告诉您某个应用有多少用户，但不会告诉您*具体是谁*，也不会告诉您授权的*时间*。为此：
- 前往 Menu → Directory → Users，打开该用户的账户。
- 打开其 Security 标签页。
- 滚动至 Connected applications。
该部分列出了该特定用户已授权的每一个第三方应用、access level（其可使用的权限范围），以及授权日期。拥有 User Security Management 权限的管理员可直接在该页面撤销任何这些授权。这是控制台中唯一显示应用*授权时间*的位置——但这意味着您需要逐个用户地检查，既无法批量导出，也无法筛选出"仅限 AI 工具"。
手动完成这项工作的实际局限是什么？
域范围的 App access control 界面汇总了统计数字，但缺少针对每个用户的详细信息；而针对每个用户的 Connected Applications 界面虽有详细信息，却没有批量视图。这两者都无法告诉您：
- 该访问权限是仍在使用中，还是曾被授予后就遭遗忘。
- 该应用实际用其可访问的数据做了什么——控制台显示的是它*能够*访问什么，而非它*已经*访问了什么。
- 这一情况随时间推移发生了怎样的变化，因为并没有关于新增授权或权限范围扩大的历史时间线记录。
- 在列出的应用中，哪些是 AI 工具——除非您自己认得出每一个供应商的名称。
对于只连接了少数几个应用的 Workspace 而言，手动逐一检查这两个界面是可行的。但一旦超过几十个应用、几百名用户，保持列表的时效性就不再是一次性任务，而会变成一项反复进行的工作——同样的信息，需要无限期地反复核查。而且这两个界面都需要拥有相应权限的管理员角色（域范围视图需要 Services 权限，单用户视图需要 User Security Management 权限）——即便一个 Workspace 拥有多名管理员，仍需要有专人定期检查这两个界面，而这并非自然而然会落到某个碰巧留意到的人身上的工作。
手动视图无法告诉您什么，8200.dev 又是如何解答这一问题的？
手动路径回答的是*什么能够访问数据*这一问题，却回答不了*谁使用了它、何时使用，以及是否仍有必要保留*——而这些问题才真正决定一个应用是否应当继续保有访问权限。8200.dev 的 Agent Guard 会在一个持续更新的统一视图中，盘点您所连接数据源中的每一个 AI 代理和已连接 OAuth 的应用，对每一项进行风险评分，并以通俗易懂的语言解释发现结果，而非仅仅呈现一串权限范围字符串。发现过程是只读的：连接 Google Workspace 时使用的是只读的 Drive 元数据权限范围，而上文所展示的更深层次 OAuth 应用清单，则需在组织启用 OAuth 应用审计后方可获取——该操作会以 Google 针对该特定视图所要求的额外只读 Admin SDK 权限范围重新进行授权；此过程本身不会自行更改任何访问权限，任何建议的操作都仅作为推荐，直至组织选择采纳并执行为止。
如需了解此方案如何延伸至 Google Workspace 以外，覆盖 Microsoft 365、Slack、GitHub 以及各 AI 供应商本身，请参阅完整连接器列表。