跳转到正文
skillsafebeta
← 报告库
用途分类 / 文档处理

Lark Wiki Skill 安全审计

作者说它能做什么（原文）

飞书知识库：管理知识空间、空间成员和文档节点。创建和查询知识空间、查看和管理空间成员、管理节点层级结构、在知识库中组织文档和快捷方式。当用户需要在知识库中查找或创建文档、浏览知识空间结构、查看或管理空间成员、移动或复制节点时使用。当用户给出 doubao.com 的 /wiki/ URL/token 时，也应直接使用本 skill，不要因为域名不是飞书而回退到 WebFetch；路由依据是 URL 路径模式和 token，而不是域名。不负责：上传文件到知识库节点下（走 lark-drive）、编辑文档/表格/Base 内容（走 lark-doc / lark-sheets / lark-base）。

第三方安全检查结论

先别安装或运行

已检查文件
14
发现的风险
4
会不会运行危险命令？检查是否下载程序后直接运行、让他人远程控制电脑，或藏起要运行的命令。未发现风险
会不会泄露文件和密钥？检查是否发送含密码或密钥的文件，以及代码里是否直接写了密钥。未发现风险
会不会删除文件或一直在后台运行？检查是否大范围删除文件、改写磁盘，或设置自动启动。发现 2 项风险
高风险

节点删除默认级联删除整个子树

原文依据：2 处
发现了什么

node-delete 是不可逆操作，而 include-children 的默认值为 true。因此仅确认“删除这个节点”并带上 --yes，可能同时删除其所有后代节点；命令并不要求用户显式选择是否级联。

为什么需要注意

一个有子节点的页面被删除时，整棵下级目录及内容可能永久丢失。节点解析错误或用户不了解默认值时，损失范围会远大于表面目标。

成立。真实删除受 `--yes` 保护，但 `--include-children` 默认为 true，因此确认删除一个节点时会默认不可逆地删除整个子树；命令不要求另行确认级联范围。用户可要求执行前解析并展示节点及其后代数量，并在未明确批准级联时强制传 `--include-children=false`，使直接子节点提升到父节点。

references/lark-wiki-node-delete.md:3来自说明文档
Delete a wiki node (or pull a cloud doc out of Wiki). OpenAPI: `DELETE /open-apis/wiki/v2/spaces/:space_id/nodes/:node_token`.> ⚠️ **High-risk write & irreversible** — deletes the node and (by default) its whole subtree. Requires explicit `--yes`; without it the CLI returns a `confirmation_required` error and nothing is deleted.- **Sync / async**: an empty `task_id` means the delete completed synchronously (`ready=true`). A non-empty `task_id` triggers bounded polling; if the window elapses the output carries `timed_out=true` and a `next_command`:  `lark-cli drive +task_result --scenario wiki_delete_node --task-id <TASK_ID> --as <user|bot>`
查看另外 1 个位置
references/lark-wiki-node-delete.md:29来自说明文档
|------|------|----------|---------|-------------|| `--node-token` | string | **Yes** | — | `node_token`, cloud-doc `obj_token`, or a Lark URL embedding one; URL paths also imply `--obj-type` || `--obj-type` | enum | Conditional | — | Required for a raw token (URL inputs auto-infer). `wiki` = the token is a `node_token`; otherwise the cloud-doc type || `--space-id` | string | No | — | Auto-resolved via `get_node` when omitted (extra lookup; pass it to skip) || `--include-children` | bool | No | `true` | Cascade-delete the subtree (default). `--include-children=false` lifts direct children up to the parent || `--yes` | bool | Yes (real delete) | — | Confirm the high-risk operation. Without it the CLI returns `confirmation_required` || `--as` | enum | No | `auto` | Identity `user`/`bot`; wiki is user-centric → pass `--as user` |
高风险

按名称删库的早停策略可能隐藏后续同名空间

原文依据：6 处
发现了什么

名称解析在累计出现一条精确匹配后立即停止翻页，文档承认这可能漏掉后续页的同名空间。随后用户只能从不完整候选中选择 space_id，而删除会永久移除整个空间及所有节点。

为什么需要注意

在存在同名空间时，用户可能误以为候选完整并确认错误的空间，导致整库及其节点不可恢复地删除。一般的候选确认无法纠正从未展示的正确候选。

成立。精确名称首次命中后即停止翻页，文档明确承认可能漏掉后续同名空间。虽然删除前必须由用户从已展示候选中明确选择 space_id，这能防止代理自动删除，却不能让用户比较未展示的同名项；选错后会不可逆删除整个空间及全部节点。用户可要求名称删除始终遍历完所有页，或在确认前主动要求继续翻页并核对描述、类型和可见性。

references/lark-wiki-delete-space.md:143来自说明文档
#### 翻页与匹配策略**边翻边匹配**：每拿一页就在已累计的 items 上对 `name` 做精确匹配（区分大小写、保留空格），满足任一条件即停止翻页：- (A) **累计精确匹配 ≥ 1 条** → 停止翻页，已找到目标- (B) **`has_more=false`**（已翻完所有页）→ 停止翻页结束后：1. 如果累计精确匹配 ≥ 1：把**所有**精确匹配作为候选列给用户2. 如果精确匹配 = 0（此时必然已走到 `has_more=false`，已收集全量 items）：在全量 items 上做**宽松匹配**（`name` trim 空格 + 大小写不敏感 + 子串包含），作为候选3. 宽松匹配也 0 条：停下来问用户是不是名字拼错、或者调用方没权限看到这个空间；**不要**自己改名字重试
查看另外 5 个位置
references/lark-wiki-delete-space.md:158来自说明文档
#### 早停的小边界早停（条件 A）意味着**可能漏掉**位于更后面页的同名空间。这种重名 corner case 由下面的"用户确认"兜底：LLM 展示候选时应照抄 `name + space_id`，用户如果觉得不是自己想删的那一个，可以要求继续翻页。#### 确认流程（硬约束）**无论精确还是模糊，无论命中 1 条还是多条，发起删除前都必须先把候选列给用户**，由用户明确回选一个 `space_id`。不要因为"只命中一条"就跳过确认直接删。
references/lark-wiki-delete-space.md:193来自说明文档
> [!IMPORTANT]> 删库不可逆。关键不变量：**发给服务端的 `--space-id` 必须是用户在上一轮对话里明确指认过的那一个**，不是 LLM 单方面"从匹配结果自动选"。## 风险等级- Risk：**`high-risk-write`**- 框架会强制要求 `--yes` 确认；不传 `--yes` 时命令会直接返回 `unsafe_operation_blocked` 错误，不会真的发请求> [!CAUTION]> `wiki +delete-space` 是**不可逆的写入操作**。执行前务必与用户再次确认 `--space-id`，并清楚该空间下的所有节点都会一并被删除。
references/lark-wiki-delete-space.md:145来自说明文档
**边翻边匹配**：每拿一页就在已累计的 items 上对 `name` 做精确匹配（区分大小写、保留空格），满足任一条件即停止翻页：- (A) **累计精确匹配 ≥ 1 条** → 停止翻页，已找到目标- (B) **`has_more=false`**（已翻完所有页）→ 停止翻页结束后：1. 如果累计精确匹配 ≥ 1：把**所有**精确匹配作为候选列给用户2. 如果精确匹配 = 0（此时必然已走到 `has_more=false`，已收集全量 items）：在全量 items 上做**宽松匹配**（`name` trim 空格 + 大小写不敏感 + 子串包含），作为候选3. 宽松匹配也 0 条：停下来问用户是不是名字拼错、或者调用方没权限看到这个空间；**不要**自己改名字重试
references/lark-wiki-delete-space.md:5来自说明文档
删除一个飞书知识空间（知识库）。OpenAPI 对应 `DELETE /open-apis/wiki/v2/spaces/:space_id`。- **不可逆**：该操作会将知识空间连同其下所有节点彻底删除，执行前必须反复确认- **同步 / 异步两种返回**：
references/lark-wiki-delete-space.md:187来自说明文档
用户明确选定 `space_id` 后：```bashlark-cli wiki +delete-space --space-id <RESOLVED_SPACE_ID> --yes```> [!IMPORTANT]> 删库不可逆。关键不变量：**发给服务端的 `--space-id` 必须是用户在上一轮对话里明确指认过的那一个**，不是 LLM 单方面"从匹配结果自动选"。
会不会绕过安全保护？检查是否跳过网站安全验证、开放过多文件权限，或取消操作前的确认。发现 2 项风险
中风险

添加管理员或移除成员没有强制确认门槛

原文依据：3 处
发现了什么

member-add 可授予 admin（完整空间管理权），member-remove 可撤销现有授权，但两者都明确没有 --yes 确认。即使 Skill 要求先解析成员类型，错误选中的同名人员、群组、空间或角色仍会立即改变权限。

为什么需要注意

错误添加管理员可能让非预期人员读取、修改或管理整个知识空间；错误移除可能中断合法用户或管理员的访问。移除虽可恢复，但需要知道原始 member_id、类型和角色。

成立。添加成员可直接授予 admin（完整空间管理权），而该写操作没有 `--yes` 门槛；移除成员同样没有确认门槛。若代理解析错同名用户、群、空间或角色，权限会立即改变。移除虽可通过重新添加恢复，但恢复仍依赖准确保存原授权三元组。用户可要求执行前展示并确认 space_id、成员标识、类型和角色，并先用 dry-run/member-list 核对。

references/lark-wiki-member-add.md:3来自说明文档
Add a member to a wiki space. OpenAPI: `POST /open-apis/wiki/v2/spaces/:space_id/members`. Shortcut over the raw `wiki members create` — adds enum hints, optional `--need-notification`, `my_library` resolution, and a flattened single-member output envelope.> The underlying `members.create` API is flagged `danger: true` in the schema browser, but adding a member is **not** confirmation-gated (no `--yes`). To revert, call [`+member-remove`](lark-wiki-member-remove.md) with the same `(member_id, member_type, member_role)` tuple.
查看另外 2 个位置
references/lark-wiki-member-add.md:35来自说明文档
|------|------|----------|---------|-------------|| `--space-id` | string | **Yes** | — | Wiki space ID; use `my_library` for the personal document library (user only) || `--member-id` | string | **Yes** | — | Member ID; interpretation is decided by `--member-type` || `--member-type` | enum | **Yes** | — | `openchat` / `userid` / `email` / `opendepartmentid` / `openid` / `unionid` / `appid` || `--member-role` | enum | **Yes** | — | `admin` (full space administration) / `member` (collaborator) || `--need-notification` | bool | No | unset | Send an in-app notification after the grant. **Omitting the flag sends no `need_notification` query at all** — passing `--need-notification=false` is the explicit opt-out || `--as` | enum | No | `auto` | Identity `user`/`bot`; wiki is user-centric → pass `--as user` |
references/lark-wiki-member-remove.md:3来自说明文档
Remove a member from a wiki space. OpenAPI: `DELETE /open-apis/wiki/v2/spaces/:space_id/members/:member_id`. Unlike most DELETEs, this endpoint **requires a body** carrying `member_type` and `member_role` — the `:member_id` path segment alone is ambiguous without both.> The underlying `members.delete` API is flagged `danger: true` in the schema browser, but the operation is recoverable — call [`+member-add`](lark-wiki-member-add.md) with the same `(member_id, member_type, member_role)` to restore. No `--yes` gate.
中风险

以 bot 创建节点会附带向当前 CLI 用户授予 full_access

原文依据：2 处
发现了什么

当使用 --as bot 创建节点时，CLI 不仅创建资源，还会尝试把该节点的可管理权限自动授予“当前 CLI 用户”。这是一项与创建操作捆绑的权限变更，没有显示为单独的可选参数或独立确认步骤。

为什么需要注意

如果本机登录的 CLI 用户不是用户预期的接收者，该账号可能获得管理新节点的能力。创建成功但授权失败时还会产生部分完成状态，后续处理可能误判权限。

成立，但仅在明确使用 `--as bot` 创建节点时触发。CLI 会在创建成功后自动尝试把新节点的 full_access 授予本地“当前 CLI 用户”；这不是独立参数，也未显示单独确认。影响是该用户获得管理该节点的权限，失败不会回滚已创建节点。用户可要求作者提供禁用自动授权的选项，并在运行前核实本地 open_id 对应谁；若不需要此附带授权，可限制使用 user 身份。

references/lark-wiki-node-create.md:59来自说明文档
- `title`：节点标题- `permission_grant`（可选）：仅 `--as bot` 时返回，说明是否已自动为当前 CLI 用户授予可管理权限> [!IMPORTANT]> 如果节点是**以应用身份（bot）创建**的，如 `lark-cli wiki +node-create --as bot`，在创建成功后 CLI 会**尝试为当前 CLI 用户自动授予该知识库节点的 `full_access`（可管理权限）**。>> 以应用身份创建时，结果里会额外返回 `permission_grant` 字段，明确说明授权结果：> - `status = granted`：当前 CLI 用户已获得该知识库节点的可管理权限> - `status = skipped`：本地没有可用的当前用户 `open_id`，因此不会自动授权；可提示用户先完成 `lark-cli auth login`，再让 AI / agent 继续使用应用身份（bot）授予当前用户权限> - `status = failed`：节点已创建成功，但自动授权用户失败；会带上失败原因，并提示稍后重试或继续使用 bot 身份处理该节点>> `permission_grant.perm = full_access` 表示该资源已授予“可管理权限”>
查看另外 1 个位置
references/lark-wiki-node-create.md:128来自说明文档
  - 同时需要 `my_library` 和父节点时：会展示三步调用链- **bot 自动授权**：若使用 `--as bot`，结果还会额外带上 `permission_grant`，用于说明是否已自动为当前 CLI 用户授予新建节点的可管理权限- **输出结果**：成功后会返回 `resolved_space_id`、`resolved_by`、`node_token`、`obj_token`、`obj_type`、`node_type`、`title` 等字段，便于后续继续操作- **结构限制**：返回 `131003` 表示触发了知识空间总节点数、目录深度或单个父节点直属子节点数等结构限制。这不是瞬时错误，禁止使用相同参数重试。根据上游错误信息选择更浅或其他父节点、重新组织现有节点，或清理/改用其他知识空间；不要在无法确认具体限制时盲目增加中间层级。
会不会误导 AI 或隐藏内容？检查工作说明是否要求 AI 忽略你的指令、干扰检查结果，或夹带看不见的文字。未发现风险
会不会偷偷改推广链接或收款方？检查是否强制替换推广链接或收款对象，同时要求隐瞒更改。未发现风险

Skill 逻辑拆解

7 个说明模块

此 Skill 通过 lark-cli 管理飞书知识空间、节点和成员；它明确优先使用用户身份，因为省略身份时 auto 常被解析为 bot，看到的资源范围可能不同。

查看原文
SKILL.md:21来自说明文档
## 身份选择：优先使用 user 身份知识空间和节点都是用户的个人资源，**策略上应优先显式使用 `--as user`**（CLI 的 `--as` 默认值为 `auto`，不带 `--as` 时常被解析成 `bot`，列出的是应用所属空间而非用户的）。仅当用户明确要求“应用 / bot 视角”时才用 `--as bot`（仍受上面的成员管理硬限制约束）。

读取列表默认只取一页；只有显式使用 --page-all 才会继续分页，而且默认最多十页。因此成员或节点盘点结果可能不完整，但输出会通过 has_more 和 page_token 表示尚有后续数据。

查看原文
references/lark-wiki-member-list.md:30来自说明文档
| Flag | Type | Required | Default | Description ||------|------|----------|---------|-------------|| `--space-id` | string | **Yes** | — | Wiki space ID; use `my_library` for the personal document library (user only) || `--page-size` | int | No | 50 | Page size, 1-50 || `--page-token` | string | No | — | Page cursor; implies single-page fetch (no auto-pagination) || `--page-all` | bool | No | `false` | Automatically paginate through all pages (capped by `--page-limit`) || `--page-limit` | int | No | 10 | Max pages with `--page-all` (0 = unlimited) || `--format` | enum | No | `json` | `json` / `pretty` / `table` / `csv` / `ndjson` || `--as` | enum | No | `auto` | Identity `user`/`bot`; wiki is user-centric → pass `--as user` |
references/lark-wiki-member-list.md:66来自说明文档
`type` (`user` / `chat` / `department`) is included when the server returns it. When the default single-page fetch (or `--page-all` capped by `--page-limit`) does not exhaust the upstream cursor, `has_more=true` and `page_token=<cursor>` so the caller can resume.

知识空间删除有明确的人工确认流程：先展示候选空间并让用户选择具体 space_id，然后命令还要求 --yes；删除会连同全部节点永久执行。

查看原文
SKILL.md:34来自说明文档
  - 只知名称：`lark-cli wiki spaces list --format json`，边翻页边收集 items 并按 `name` 精确匹配；**一旦任一页累计到至少 1 条精确匹配就停止翻页**。只有当翻完所有页（`has_more=false`）仍无精确匹配时，才对已收集的全量 items 做宽松匹配（`name` trim 空格、大小写不敏感、子串包含）。  - **关键安全约束**：无论精确还是模糊，**无论命中 1 条还是多条，发起删除前都必须把候选（`name` + `space_id` + `description` + `space_type`）列给用户，由用户明确选定一个 `space_id` 再执行**。不要因为"只命中一条"就自动执行删除。  - 命中 0 条：停下来问用户是名称拼错了还是调用方无权限；**不要**自行改名字重试。  - 用户明确选定后再执行 `lark-cli wiki +delete-space --space-id <ID> --yes`（高风险写操作，必须显式 `--yes`）。  - 反例：不要把 wiki URL / 名称直接当 `--space-id`（如 `--space-id "https://.../wiki/<wiki_token>"`）；务必先用 `wiki +node-get` 解析出 `data.space_id` 再传。
references/lark-wiki-delete-space.md:5来自说明文档
删除一个飞书知识空间（知识库）。OpenAPI 对应 `DELETE /open-apis/wiki/v2/spaces/:space_id`。- **不可逆**：该操作会将知识空间连同其下所有节点彻底删除，执行前必须反复确认- **同步 / 异步两种返回**：  - 如果接口直接返回空 `task_id`，说明删除同步完成，shortcut 立即返回 `ready=true`  - 如果接口返回非空 `task_id`，shortcut 会先对任务做有限轮询；轮询窗口内仍未完成会输出 `next_command`，引导调用方使用 `lark-cli drive +task_result --scenario wiki_delete_space --task-id <TASK_ID>` 继续查

节点在 Wiki 与 Drive 之间移动会改变资源位置及权限继承；文档要求在执行前确认源节点、目标位置和调用身份。

查看原文
references/lark-wiki-move-to-drive.md:107来自说明文档
## 权限与影响- CLI 写操作预检查使用 `space:document:move`，任务轮询使用 `wiki:space:read`。- 调用方必须能移动源 Wiki 节点并写入目标 Drive 文件夹。- 成功后源节点会从 Wiki 树中消失，目标文档改用 Drive 目标位置的权限模型；原 Wiki 层级继承权限不再保留。- 省略 `--folder-token` 时，“根目录”属于当前 `--as` 身份，user 与 bot 的可见资源范围可能不同。> [!CAUTION]> 这是会改变文档归属和权限继承的**写入操作**。执行前必须确认源 Wiki 节点、目标 Drive 位置和调用身份。
从这里开始 · 工作说明SKILL.md
lark-wiki
连线表示工作说明包含的模块，不是实际运行顺序。点击模块可查看原文。

文件引用关系图

24 处引用
哪些文件发起引用引用了什么
连线表示真实的文件引用，不是运行顺序。点击节点可高亮相关连线，并查看具体文件和原文位置。虚线表示还有文件需要定位。
文件与检查记录14 个文件

检查范围与遗漏

逐文件查看涉及的内容

下方列出本次涉及的原文范围；纳入检查不代表已查清所有问题。

  • SKILL.md已纳入全文
  • references/lark-wiki-delete-space.md已纳入全文
  • references/lark-wiki-member-add.md已纳入全文
  • references/lark-wiki-member-list.md已纳入全文
  • references/lark-wiki-member-remove.md已纳入全文
  • references/lark-wiki-move-to-drive.md已纳入全文
  • references/lark-wiki-move.md已纳入全文
  • references/lark-wiki-node-copy.md已纳入全文
  • references/lark-wiki-node-create.md已纳入全文
  • references/lark-wiki-node-delete.md已纳入全文
  • references/lark-wiki-node-get.md已纳入全文
  • references/lark-wiki-node-list.md已纳入全文
  • references/lark-wiki-space-create.md已纳入全文
  • references/lark-wiki-space-list.md已纳入全文

这份报告只针对上方版本。我们看了拿到的代码和说明文件，没有实际运行 Skill，也没有检查它另外安装的软件包。因此，这不是“保证安全”的承诺；换了版本或使用环境，结果也可能不同。

  • SKILL.md工作说明
  • references/lark-wiki-delete-space.md配套文件
  • references/lark-wiki-member-add.md配套文件
  • references/lark-wiki-member-list.md配套文件
  • references/lark-wiki-member-remove.md配套文件
  • references/lark-wiki-move-to-drive.md配套文件
  • references/lark-wiki-move.md配套文件
  • references/lark-wiki-node-copy.md配套文件
  • references/lark-wiki-node-create.md配套文件
  • references/lark-wiki-node-delete.md配套文件
  • references/lark-wiki-node-get.md配套文件
  • references/lark-wiki-node-list.md配套文件
  • references/lark-wiki-space-create.md配套文件
  • references/lark-wiki-space-list.md配套文件

代码和说明中提到的操作

连接外部网站
SKILL.md:37来自说明文档
  - 用户明确选定后再执行 `lark-cli wiki +delete-space --space-id <ID> --yes`（高风险写操作，必须显式 `--yes`）。  - 反例：不要把 wiki URL / 名称直接当 `--space-id`（如 `--space-id "https://.../wiki/<wiki_token>"`）；务必先用 `wiki +node-get` 解析出 `data.space_id` 再传。- 用户要在知识库中创建新节点，优先使用 `lark-cli wiki +node-create`。
references/lark-wiki-move-to-drive.md:87来自说明文档
  "obj_type": "docx",  "url": "https://example.feishu.cn/docx/doxcnXXX"}
references/lark-wiki-node-get.md:20来自说明文档
|------|------|----------|---------|-------------|| `--node-token` | string | **Yes** | — | `node_token`, cloud-doc `obj_token`, or a Lark URL embedding one (e.g. `https://feishu.cn/wiki/<token>` or `https://feishu.cn/docx/<token>`). Matches the `--node-token` naming used by sibling `+node-delete` / `+node-copy` / `+move`. || `--token` | string | — (deprecated) | — | Deprecated original name; still accepted for backward compatibility but emits a `Flag --token has been deprecated, use --node-token instead` warning on stderr. New scripts should use `--node-token …
运行命令
SKILL.md:89来自说明文档
```bashlark-cli schema wiki.<resource>.<method>   # 调用原生 API 前必须先查看 --data / --params 参数结构，不要猜测字段格式
references/lark-wiki-delete-space.md:14来自说明文档
```bash# 同步或异步删除一个知识空间（必须显式加 --yes 确认）
references/lark-wiki-delete-space.md:122来自说明文档
```bashlark-cli wiki +node-get \
读取了多少行
1,397
文件校验值（用于核对版本）
12bc12534ea597dac705314015281aedf3e1ec1ed06ed41a8f378712570e9f0a