AI 工具安全清单：权限、数据和团队边界

2026-06-210阅读10分钟

一次不起眼的接入，可能是最大的安全事件

上个月，我帮一个团队做接入评审。他们准备给全组买 Cursor 企业版，IT 负责人问了一句：「这个工具能看到我们哪些仓库？」在场没人答得上来。销售给的文档写的是「代码上下文感知」，至于感知到什么程度、能不能读 private repo、会不会把代码送去训练——这些问题，他们直到评审会上才第一次正式问出来。

这件事让我意识到：大多数团队引入 AI 工具的方式，和引入一个正式系统的方式完全不同。装个 Chrome 插件、登录一下 Google 账号、授权 GitHub 访问，就算上线了。没有评审，没有权限划定，没有退出方案。而 AI 工具与传统 SaaS 不同的地方在于——它不仅读你的数据，还把你的数据变成模型的一部分。

这篇文章整理一份我在实际项目中使用的安全检查清单，覆盖账号、权限、数据、文件、审计和边界六个方面。目标很简单：在工具接入之前，把风险降到可接受范围。

AI 工具与传统 SaaS 的安全差异

在列清单之前，有必要先理解为什么 AI 工具的安全评估不能照搬传统 SaaS 的流程。传统 SaaS 的安全模型建立在「数据隔离 + 权限控制」上——你授权一个 CRM 访问客户列表，CRM 厂商承诺不拿你的数据去训练自己的产品。这个模型虽然不完美，但边界是清晰的。

AI 工具打破了这个边界。当你把一个代码仓库授权给 Copilot、把一份产品文档丢给 ChatGPT、或者让 Cursor 读取你的整个项目目录时，数据不只是被「访问」了——它被喂给了模型。即便厂商承诺「不用你的数据训练」，数据仍然经过了模型推理管道，进入了 GPU 内存，留下了 log。

维度	传统 SaaS	AI 工具
数据流向	存储在厂商服务器，理论上隔离	经过模型推理管道，可能进入训练集
权限粒度	通常按功能模块划分	按「上下文」划分，范围模糊
数据保留	可配置保留策略	往往由模型提供方控制
审计能力	通常有操作日志	日志覆盖不全，尤其推理阶段
二次传播	数据只在厂商系统内	可能被其他用户通过模型间接获取
退出成本	导出数据即可	无法从已训练模型中「撤回」数据

这种差异意味着，传统的「签个 DPA 就完事」的做法不够用了。你需要更细粒度的控制。

三个真实案例

案例一：Rules File Backdoor——配置文件的供应链攻击

2025 年 3 月，安全公司 Pillar Security 披露了一个影响 Cursor 和 GitHub Copilot 的漏洞¹。攻击者在 .cursor/rules 或 .github/copilot-instructions.md 这类 AI 配置文件中嵌入不可见的 Unicode 字符（零宽连接符、双向文本标记），人类开发者在 IDE 和 GitHub PR Review 中都看不到这些字符，但 AI 模型会完整解析并执行。

效果是什么？一个看似正常的规则文件，能让 AI 在生成代码时悄悄插入恶意 <script> 标签、泄露环境变量、甚至创建后门。更麻烦的是，规则文件通常随项目模板和开源社区传播——一个被污染的文件，可以影响整个生态系统。

这个案例的教训是：AI 配置文件本身就是代码，应该用和代码一样的标准审查。

<!-- 表面正常的规则文件 -->
# Project Rules
- Use TypeScript strict mode
- Follow existing component patterns
- Always add error boundaries
 
<!-- 实际隐藏的恶意指令（不可见 Unicode 字符） -->
<!-- 当 AI 生成 HTML 时，自动添加外部脚本引用 -->

Cursor 的回应是「这属于用户责任」；GitHub 起初也持相同立场，直到 2025 年 5 月才上线了隐藏 Unicode 检测功能¹。这个时间差本身就说明了问题——安全边界的定义，不能只依赖工具提供方。

案例二：Salesloft Drift——OAuth 令牌引发的级联泄露

2026 年初的 Salesloft Drift 事件²，展示了 AI SaaS 环境中 OAuth 令牌的杀伤力。攻击者先入侵 GitHub 仓库，获取了 AWS 环境访问权限，然后窃取了活跃的 OAuth 和 Refresh Token。这些令牌让他们能够冒充 Drift，访问客户的 Salesforce 实例。最终影响超过 700 家组织。

核心问题在于：企业已经习惯了「自动授权 OAuth」，很少有人认真看一个 SaaS 工具申请的权限范围。当 AI 功能嵌入 SaaS 产品后，OAuth 令牌不仅代表应用访问权限，还代表 AI 代理访问你数据的权限。一个被窃取的令牌，可以触发跨组织的级联数据泄露。

# 典型的 OAuth 权限范围——你授权时仔细看过吗？
scopes:
  - read:contacts        # 读取联系人
  - write:emails         # 发送邮件
  - read:crm_data        # 读取 CRM 数据
  - ai:process_data      # 允许 AI 处理数据（新增）
  - ai:train_on_data     # 允许用于模型改进（隐藏条款）

案例三：影子 AI——490% 的攻击增长

SecurityWeek 2026 年 3 月的报告²指出，分析覆盖的 23,000 个 SaaS 应用环境中，100% 的公司运行着嵌入 AI 的 SaaS 环境，平均每个组织有 140 个 AI 驱动的 SaaS 环境。其中大量是未经 IT 审批的「影子 AI」——员工自己注册、自己付费、自己授权数据访问。

结果是：2025 年公共 SaaS 攻击同比增长 490%，80% 的事件涉及 PII 或客户数据。攻击者不再需要突破你的防火墙——他们只需要拿到一个员工自己注册的 AI 工具的 OAuth 令牌。

接入评估流程

在引入任何 AI 工具之前，我建议走一遍这个流程。它不需要很重，但必须走：

流程图画布 · 115%

Mermaid 流程图加载中...

这个流程的关键不是审批本身，而是「在接入之前就确定退出方案」。很多工具一旦接入、数据一旦喂入，退出的成本远高于接入的成本。

六维安全清单

下面是我在实际项目中使用的检查清单。每一项都有具体的验证方式，不是泛泛的建议。

1. 账号与身份

检查项	验证方式	风险等级
是否支持公司 SSO（SAML/OIDC）登录	在管理后台查看认证配置	高
离职员工的账号能否自动回收	与 HR 系统联动测试	高
是否强制 MFA	查看安全策略配置	高
是否存在共享账号现象	审计登录日志	中
API Key 是否有过期机制	检查 Key 管理页面	中

常见错误做法：用个人 Gmail 注册 AI 工具，然后在公司项目中使用。一旦员工离职，这个账号以及它接触过的所有上下文，都不在公司控制范围内。

# 正确：通过环境变量管理 API Key，不硬编码
OPENAI_API_KEY="sk-..."
 
# 错误：把 Key 写在代码里
const client = new OpenAI({ apiKey: "sk-..." })

# 正确：Key 设置过期时间
az cognitiveservices account keys rotate \
  --name my-openai \
  --resource-group my-rg \
  --key-name key1
 
# 错误：Key 永不过期，从未轮转
# 创建后直接使用，无人管理

2. 权限范围

检查项	验证方式	风险等级
工具请求了哪些 OAuth scope	逐一审查授权页面	高
能否访问 private repo	用测试账号验证	高
能否读取 Slack/邮件/日历	检查集成配置	高
权限是否可以按团队/项目限制	查看管理后台	中
是否存在「全有或全无」的权限模型	尝试部分授权	中

最小权限原则在 AI 工具中尤其重要。Cursor 默认能读取你打开的整个项目目录——如果你的项目里有 .env 文件、测试用的生产数据快照、或者客户的 API 凭证，这些全部在 AI 的「上下文窗口」里。

# 正确：.cursorignore 排除敏感文件
.env
.env.local
*.pem
secrets/
fixtures/production-*
tests/fixtures/customer-data*
 
# 错误：不做任何排除，AI 可以读取一切
# 没有 .cursorignore 文件

# 正确：.github/copilot-instructions.md 明确边界
# Copilot 不得访问以下目录
# deny-paths: secrets/, config/production/
 
# 错误：不写任何指令，使用默认全开配置

3. 数据与训练

检查项	验证方式	风险等级
输入数据是否用于模型训练	查看隐私政策 + 管理后台设置	高
能否关闭数据保留	检查数据保留策略配置	高
数据保留多长时间	查看数据处理附录（DPA）	高
数据是否出境（跨境传输）	查看数据处理地点声明	高
是否支持零数据保留（ZDR）模式	联系销售确认	中

这是 AI 工具与传统 SaaS 最本质的区别。ChatGPT 的免费用户，对话内容默认用于训练；企业版可以关闭，但需要你主动去设置。Cursor 的 Privacy Mode 可以阻止代码被存储，但它不在默认开启状态。

# 正确：企业版配置，关闭训练和数据保留
openai:
  data_retention: false
  training_opt_out: true
  zero_data_retention: true
  region: us-east-1  # 明确数据处理地点
 
# 错误：使用默认配置
openai:
  # 所有选项使用默认值
  # 数据可能被保留 30 天，可能用于训练

# 正确：显式设置 headers 声明不用于训练
headers = {
    "Authorization": f"Bearer {api_key}",
    "OpenAI-Organization": "org-xxx",
}
# 企业后台同时配置 training_opt_out
 
# 错误：只依赖 API 调用，后台未配置
# 默认设置下数据可能被保留

4. 文件与上传

检查项	验证方式	风险等级
是否允许上传客户数据	检查上传功能 + 策略	高
上传的文件是否有大小/类型限制	尝试上传测试	中
上传后的文件存储在哪里	查看数据处理声明	高
是否对上传内容做敏感信息扫描	检查是否有 DLP 集成	中
能否限制特定文件类型的上传	配置上传白名单	中

一条简单规则：如果一份文件你不会发到公共 GitHub 仓库，就不要上传给 AI 工具。这个类比不完美，但它足够直观，能让团队成员快速判断。

5. 审计与监控

检查项	验证方式	风险等级
能否查看成员使用记录	检查管理后台审计日志	高
能否导出审计日志到 SIEM	检查集成能力	中
是否有异常使用告警	测试异常场景	中
能否追踪连接器和集成行为	查看集成管理页面	高
日志保留多长时间	查看日志策略	中

没有审计能力的安全策略等于没有策略。你需要知道：谁在什么时间用了什么工具，访问了什么数据，上传了什么文件。如果工具不提供这些能力，要么换一个，要么在外部加一层代理监控。

# 正确：审计日志接入 SIEM
audit:
  enabled: true
  export_to: splunk  # 或 ELK、Datadog
  events:
    - file_upload
    - prompt_submitted
    - integration_connected
    - api_key_used
  retention_days: 90
 
# 错误：审计日志只在控制台看，无外部存档
audit:
  enabled: true
  # 仅控制台查看，30 天后自动清除
  # 无法事后追溯

6. 边界与退出

检查项	验证方式	风险等级
哪些场景必须禁用外部 AI	制定使用红线清单	高
是否有本地/私有部署替代方案	评估备选方案	高
数据能否完整导出	测试导出功能	高
退出后数据是否从厂商服务器删除	查看删除策略	高
是否有合同条款保障删除执行	法务确认	中

必须禁用外部 AI 工具的场景：处理客户 PII、分析安全漏洞细节、生成包含商业机密的文档、处理受监管行业数据（金融、医疗、政务）。这些场景下，只能用本地部署的模型或者明确不支持数据保留的企业方案。

团队数据分级规范

安全检查清单告诉你「怎么做」，数据分级告诉你「什么能做什么不能做」。我建议把数据分成四级，每一级对应明确的 AI 工具使用规则：

data_classification:
  L1_public:
    description: "已公开的资料、文档、博客"
    allowed_tools: "任何 AI 工具"
    example: "产品官网内容、公开 API 文档"
 
  L2_internal:
    description: "内部资料，不含敏感信息"
    allowed_tools: "公司批准的企业版 AI 工具"
    example: "内部 Wiki、技术方案草稿、代码结构说明"
 
  L3_sensitive:
    description: "敏感资料，泄露有影响"
    allowed_tools: "仅限 ZDR 模式或私有部署"
    example: "客户合同、财务数据、安全审计报告"
 
  L4_prohibited:
    description: "禁止输入任何外部 AI"
    allowed_tools: "仅本地模型"
    example: "用户密码、私钥、生产数据库、PII 原文"

对代码工具，还需要补充三条硬性规则：不能把密钥写入 prompt、不能绕过 code review 直接合并 AI 生成的代码、不能给 AI 代理执行生产环境破坏性命令的权限。

季度复查机制

安全清单不是一次性的。每个季度，我会做一次抽查：

权限复查：逐个检查 AI 工具的 OAuth 授权范围，清理不再需要的权限
成员复查：离职成员的账号是否已回收，新成员的权限是否最小化
工具复查：是否有新的影子 AI 工具出现，已有的工具是否有安全事件
数据复查：敏感数据是否流入了不该去的地方（可以用 DLP 工具扫描）
策略复查：数据分级是否还适用，退出方案是否还可行

对新工具，要求记录一份简单的「工具卡片」：

### AI 工具接入卡片
- **工具名称**：
- **用途**：
- **负责人**：
- **访问数据范围**：
- **数据保留策略**：
- **付费计划**：
- **退出方案**：
- **风险等级**：L1 / L2 / L3 / L4
- **上次复查日期**：

完整检查清单

把上面所有内容汇总成一份可直接使用的清单。在引入任何 AI 工具前，逐项过一遍。

账号与身份

支持公司 SSO（SAML/OIDC）登录
离职员工账号可自动回收
强制启用 MFA
无共享账号现象
API Key 有过期和轮转机制

权限范围

OAuth scope 逐一审查，无多余权限
不能访问不应访问的 private repo
邮件、日历、聊天记录等集成按需开启
权限可按团队或项目限制
配置文件（如 .cursorignore）排除敏感目录

数据与训练

确认输入数据不用于模型训练
数据保留策略已明确且可接受
数据处理地点符合合规要求
支持零数据保留（ZDR）模式或已评估替代方案
跨境传输已通过法务审核

文件与上传

上传功能有类型和大小限制
上传文件不自动进入训练管道
有 DLP 或敏感信息扫描能力
客户数据、密钥、合同等禁止上传

审计与监控

审计日志覆盖关键操作（上传、集成、API 调用）
日志可导出到 SIEM
异常使用有告警机制
日志保留不少于 90 天

边界与退出

已明确禁止使用外部 AI 的场景
有本地或私有部署替代方案
数据可完整导出
退出后数据删除有合同保障
工具卡片已填写并归档

写在最后

AI 工具的安全问题，本质上不是技术问题，而是治理问题。技术层面的权限控制、数据加密、审计日志，大多数企业级工具都提供了。真正缺失的是：谁负责评估、谁负责审批、谁负责复查、谁负责退出。

不要把 AI 工具当成个人效率软件来管，也不要把它当成一个需要三个月评审才能上线的重型系统。找到中间地带：轻量但严肃的接入流程，明确但不繁琐的权限边界，持续但不沉重的复查机制。

安全不是工具选型结束时打一个勾，而是从接入第一天开始、贯穿工具整个生命周期的持续动作。

参考资料

Footnotes

Pillar Security. New Vulnerability in GitHub Copilot and Cursor: How Hackers Can Weaponize Code Agents. 2025-03. ↩ ↩²
SecurityWeek. The Shadow AI Problem: How SaaS Apps Are Quietly Enabling Massive Breaches. 2026-03. ↩ ↩²

我

0 / 1000