飞书文档已经设置了“禁止下载/导出/打印”，是否意味着用户、AI Agent 和第三方应用都无法把内容带走？
不一定。
在一次经过授权的企业环境复测中，飞书管理后台的“验证权限范围”明确显示某成员无权下载、导出和打印文档；但使用同一成员身份，通过飞书 CLI 调用开放平台的云文档导出接口，仍然成功导出了普通云文档和多维表格。
问题不在于 CLI 有什么特殊的“绕过能力”。CLI 只是调用公开 API。真正的问题是：飞书文档成员权限、文档安全设置、应用 Scope、访问凭证和租户策略不是同一层权限；其中任何一层仍然放行，内容就可能从另一个出口离开飞书。
本文只讨论权限模型和企业防护，不公开真实文档链接、访问凭证或租户信息。不同版本、套餐和租户策略的实际行为可能不同，建议在自有测试文档中完成复核。
先说结论：禁止下载不是一个全局权限开关
飞书帮助中心把“谁可以复制内容、创建副本、打印或下载文档”归入文档安全设置。这个设置很容易让管理员形成一种直觉：只要后台显示“禁止”，所有下载路径都应该被封住。
但开放平台还有一套独立的 API 授权体系。调用云文档 API 时，系统至少需要同时判断五件事：
| 权限层 | 它决定什么 | 常见误区 |
|---|---|---|
| 文档成员权限 | 当前用户或应用能否阅读、编辑或管理目标文档 | 有阅读权限不等于只有阅读能力 |
| 文档安全设置 | 网页端和客户端是否允许复制、创建副本、打印或下载 | 把界面限制理解成所有 API 的统一限制 |
| 应用 API Scope | 应用可以调用哪些云文档、文件、表格和知识库接口 | 把 readonly 理解成“绝对不能下载” |
| 访问身份与数据范围 | 请求使用 user_access_token 还是 tenant_access_token，能访问哪些资源 | 只检查员工权限，不检查应用身份和用户授权 |
| 租户安全策略 | DLP、密级、策略中心等能力是否覆盖 API 和 AI 工具 | 默认认为客户端策略会自动传递给开放平台 |
因此，“禁止下载”是否真正有效，不能只看管理后台里的一个结果。必须把文档、应用、身份、接口和租户策略放在同一条链路里检查。
飞书 API 是怎样把云文档导出的
飞书开放平台的云文档导出不是一个单接口动作，而是一条异步链路：
- 调用创建导出任务，提交文档 token、文档类型和目标文件格式，获得任务 ID。
- 调用查询导出任务结果，等待任务完成并获得导出文件 token。
- 调用下载导出文件，把生成的 Word、Excel、PDF 或 CSV 文件保存到本地。
知识库链接还多一层转换。浏览器地址里的 /wiki/... 是知识库节点 token，不一定是底层文档 token。调用导出接口前，需要先取得节点对应的 obj_token 和 obj_type，再根据底层类型选择导出格式。
飞书 CLI 的 drive +inspect 和 drive +export，本质上只是把“解析知识库节点、创建任务、轮询结果、下载文件”封装成了更容易使用的命令。换成 SDK、MCP 工具、自动化脚本或 AI Agent，走的仍然是同一组开放平台能力。
实测结果：docx 和 bitable 都能导出
为了排除单一文档类型的偶然性，我们在同一授权环境中复测了两种知识库文档：
| 测试对象 | 知识库底层类型 | 导出格式 | 导出结果 |
|---|---|---|---|
| 某需求文档 | docx | Word（DOCX） | 成功，约 214 KB |
| 某运维统计表 | bitable | Excel（XLSX） | 成功，约 4.6 MB |
复测时同时满足以下条件：
- 管理后台验证该成员的“下载/导出/打印”结果为禁止；
- 该成员对目标文档拥有阅读权限；
- 飞书应用已经获得可调用相关云文档接口的 Scope；
- CLI 使用该成员完成的用户授权调用 API；
- 导出过程中没有收到“禁止下载/导出”策略的拦截提示。
这组结果不能证明所有飞书租户都存在相同行为，但足以说明：企业不能仅凭网页端的“禁止下载”状态，推断开放平台 API 也一定被阻断。
为什么会出现这种差异
1. 文档访问权和内容传播权不是同一个判断
文档成员权限回答的是“这个身份能不能看到文档”；下载、导出、复制和创建副本回答的是“看到之后能不能把内容带走”。在客户端里，两者通常由同一个分享面板呈现，很容易被理解成一套权限。
到了开放平台，系统还要判断应用 Scope 和访问凭证。即使页面按钮被隐藏或禁用，API 是否放行仍然取决于服务端接口有没有读取同一条安全策略。
2. readonly 不代表“不能导出”
这是最容易误配的一点。
飞书当前的权限命名中，一些只读 Scope 本身就包含下载或导出语义。例如：
drive:export:readonly的能力就是导出云文档；drive:file:readonly包含查看和下载云空间文件；- 部分文档或表格的只读权限描述中包含“查看、评论和导出”。
所以，把 drive:drive 简单降级为 drive:drive:readonly，不能作为阻断导出的可靠方案。管理员必须查看每个 Scope 的完整能力描述以及它关联的 API，而不是只看权限名称最后有没有 readonly。
3. 用户身份和应用身份会形成不同的数据边界
使用 user_access_token 时，应用通常代表已经授权的员工访问其可见资源；使用 tenant_access_token 时，请求代表应用身份，还会受到应用数据范围、资源归属和文档协作者关系影响。
同一个导出接口，在两种身份下可能得到不同结果。因此排查时必须记录：谁授权了应用、请求使用什么 token、目标文档属于谁、应用是否被添加为协作者，以及租户策略是否覆盖该身份。
4. 知识库链接隐藏了真实资源类型
一个 /wiki/... 链接背后可能是新版文档、电子表格、多维表格或其他资源。管理员看到的是同一个知识库入口，API 实际处理的却是不同资源和不同 Scope。
这意味着测试不能只选一篇普通文档。至少要覆盖 docx、sheet 和 bitable，否则容易把某一种资源的行为误判为整个知识库的行为。
5. API 级策略可能依赖额外的租户能力
我们向飞书支持反馈后得到的答复是：把文档安全策略进一步作用到 API，需要使用“策略中心 addon”相关能力。
这条信息需要每个企业结合自己的飞书版本和合同再次确认。真正应该问清楚的不是“我们有没有禁止下载”，而是：当前套餐中的禁止下载策略，是否覆盖用户身份 API、应用身份 API、AI 助手、MCP 和导出任务接口。
为什么 Agent、MCP 和企业 Harness 会放大这个问题
过去，调用云文档 API 需要开发人员写代码。现在，飞书 CLI、MCP 和 AI Agent 把接口能力变成了自然语言可以触发的工具。
这没有创造新的权限，却显著降低了权限被组合使用的成本：
- Agent 可以先解析知识库链接，再识别底层类型；
- 根据类型自动选择 Word、Excel、PDF 或 CSV；
- 自动轮询导出任务并获取文件；
- 把文件继续交给邮件、网盘、知识库或其他模型处理；
- 整个过程不再需要用户逐步点击下载按钮。
所以，企业 Harness 的安全边界不能只定义“模型能看到什么”，还必须定义：
- 当前任务可以加载哪些工具；
- 每个工具可以使用哪一种身份；
- 哪些文档只允许读取，哪些允许产生本地文件；
- 导出、上传、发送和对外分享是否需要人工确认；
- 生成的文件保存在哪里、保留多久、谁可以再次读取；
- 每次操作是否有可追溯的审计证据。
我在商业化项目的 Loop Engineering 实践里把 Harness 定义为权限、验证和恢复的执行边界。这个案例进一步说明：如果底层 SaaS 的策略与 API 没有对齐，Harness 就必须补上自己的工具授权和输出门禁。
哪些企业最需要立即自查
如果同时满足以下任意几项，就不应继续把“禁止下载”当成完整的数据防泄漏方案：
- 用飞书文档或飞书知识库保存合同、财务、人事、客户、研发或运维数据；
- 已部署 OpenClaw、MCP、企业 Agent、RPA 或其他 AI 办公工具；
- 员工曾为第三方应用授予云文档相关权限；
- 自建应用拥有 Drive、Docs、Sheets、Bitable 或 Wiki 的下载/导出 Scope；
- 不清楚当前请求使用用户身份还是应用身份；
- 只检查了文档分享面板，没有盘点应用权限和存量授权；
- 导出的文件可以被 Agent 继续上传、发送或写入其他存储；
- 没有针对 API 导出的独立审计和告警。
如何安全地复测飞书文档权限
不要直接拿真实高敏文件做实验。建立一份包含虚构数据的测试文档，然后按下面的顺序验证：
- 在管理后台对测试成员设置禁止下载、导出和打印，并用权限验证工具记录结果。
- 记录测试成员对文档的成员权限，以及文档自身的复制、下载和分享设置。
- 导出相关应用的 Scope 清单，标记所有包含“下载”“导出”“文件内容”的权限。
- 区分调用使用的是
user_access_token还是tenant_access_token，并记录应用的数据范围。 - 分别测试普通文档、电子表格和多维表格，确认不同资源类型的行为。
- 只在受控环境中尝试创建导出任务，不把产物发送到任何外部系统。
- 撤销用户授权和应用 Scope 后再次测试，确认旧 token 是否立即失效。
- 检查飞书审计日志、Agent 工具日志和本地文件目录，确认整个过程能否被追踪。
如果页面禁止下载，但 API 仍然成功创建导出任务并下载文件，就说明当前策略没有覆盖完整链路。
立即止血：不要只把权限改成 readonly
当天可以完成
- 移除不必要的导出 Scope。 重点检查
drive:export:readonly、drive:file:readonly，以及描述中明确包含“导出”的文档、电子表格和多维表格权限。 - 撤销存量用户授权。 只修改应用的新版本配置不够，还要确认已经签发的用户授权和 token 是否失效。
- 暂停高风险工具。 对可以生成本地文件、上传网盘、发送邮件或推送消息的 Agent 工具临时关闭，或增加人工确认。
- 缩小高敏文档可见范围。 API 无法访问用户本身看不到的文档，因此成员权限仍然是最直接的一道边界。
一周内应该完成
- 建立应用 Scope 台账。 记录应用负责人、权限用途、访问身份、数据范围、最后使用时间和复核日期。
- 拆分读取与导出能力。 不要让同一个默认工具同时拥有搜索、读取、导出和外发权限。
- 给 Harness 增加输出门禁。 导出文件、发送外部消息、上传第三方存储应当是独立的高风险动作。
- 验证策略中心或 DLP 的 API 覆盖范围。 要求供应商明确回答具体接口和身份，而不是只给出“支持防泄漏”的产品描述。
长期应该制度化
把这类测试变成权限回归测试：每当飞书版本、应用 Scope、Agent 工具或租户安全策略发生变化，就自动验证“允许读取但禁止导出”的测试用例。安全策略只有被持续验证，才能算真正存在。
向飞书或内部管理员确认这 7 个问题
- 当前“禁止下载/导出/打印”是否覆盖
/drive/v1/export_tasks？ - 用户身份和应用身份调用导出接口时，策略结果是否一致？
- 哪些 Scope 可以创建导出任务、下载导出产物或下载附件？
readonly权限中哪些仍然包含下载或导出能力？- 撤销应用权限或用户授权后，已有 token 多久失效？
- 策略中心、DLP 和密级能力分别覆盖客户端、API、AI 助手和 MCP 的哪些路径？
- 管理员能否在审计日志中定位创建导出任务、下载导出文件和文件外发行为？
如果这七个问题没有明确答案，企业就还没有真正掌握飞书文档的数据出口。
最后：AI 安全问题，往往先是权限工程问题
“飞书文档禁止下载”不是一个覆盖所有场景的安全结论，它只是权限链路中的一个配置。
到了 Agent 和 MCP 时代，真正有效的边界是五层能力的交集：文档成员权限、文档安全设置、应用 Scope、访问身份和租户级策略。 任何一层仍然允许读取、导出或外发，AI 都可能把这些能力组合成一条完整的数据路径。
先盘点权限，再接入工具；先验证 API，再相信界面。这比单纯讨论模型是否安全，更接近企业 AI 落地的真实问题。