Skip to content
skillsafebeta
← Report library
Purpose / Documents

Lark Wiki Skill Security Audit

What the author says it does (original text)

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

Independent security check

Do not install or run it yet

Files checked
14
Risks found
4
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.No risks found
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.Risks found: 2
High risk

Node deletion cascades through the entire subtree by default

Source references: 2
What we found

node-delete is irreversible and include-children defaults to true. Confirming “delete this node” and supplying --yes can therefore delete all descendants as well; the command does not require an explicit cascade choice.

Why this matters

Deleting a page with children may permanently remove the entire lower hierarchy and its content. A wrongly resolved node or an unnoticed default can make the loss much larger than the apparent target.

Supported. Real deletion is gated by `--yes`, but `--include-children` defaults to true, so confirming deletion of one node also irreversibly deletes its entire subtree by default; no separate cascade confirmation is required. Users can require the node and descendant count to be shown first and mandate `--include-children=false` unless subtree deletion was explicitly approved, which lifts direct children to the parent.

references/lark-wiki-node-delete.md:3In the instructions
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>`
Show 1 other places
references/lark-wiki-node-delete.md:29In the instructions
|------|------|----------|---------|-------------|| `--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` |
High risk

Early stopping during name-based space deletion can hide later same-name spaces

Source references: 6
What we found

Name resolution stops pagination as soon as one exact match has accumulated. The documentation acknowledges that this can miss same-name spaces on later pages. The user then selects a space_id from an incomplete candidate set, while deletion permanently removes the space and all nodes.

Why this matters

Where duplicate names exist, a user may believe the candidates are complete and approve the wrong space, irreversibly deleting the entire wiki and its nodes. Candidate confirmation cannot correct for the intended candidate never being displayed.

Supported. Pagination stops after the first accumulated exact name match, and the documentation acknowledges that later same-name spaces may be missed. Requiring the user to choose a displayed space_id prevents automatic selection, but it does not let the user compare hidden duplicates; a wrong choice irreversibly deletes the space and all nodes. Users can require exhaustive pagination for name-based deletion, or explicitly request continued paging and compare description, type, and visibility before confirming.

references/lark-wiki-delete-space.md:143In the instructions
#### 翻页与匹配策略**边翻边匹配**：每拿一页就在已累计的 items 上对 `name` 做精确匹配（区分大小写、保留空格），满足任一条件即停止翻页：- (A) **累计精确匹配 ≥ 1 条** → 停止翻页，已找到目标- (B) **`has_more=false`**（已翻完所有页）→ 停止翻页结束后：1. 如果累计精确匹配 ≥ 1：把**所有**精确匹配作为候选列给用户2. 如果精确匹配 = 0（此时必然已走到 `has_more=false`，已收集全量 items）：在全量 items 上做**宽松匹配**（`name` trim 空格 + 大小写不敏感 + 子串包含），作为候选3. 宽松匹配也 0 条：停下来问用户是不是名字拼错、或者调用方没权限看到这个空间；**不要**自己改名字重试
Show 5 other places
references/lark-wiki-delete-space.md:158In the instructions
#### 早停的小边界早停（条件 A）意味着**可能漏掉**位于更后面页的同名空间。这种重名 corner case 由下面的"用户确认"兜底：LLM 展示候选时应照抄 `name + space_id`，用户如果觉得不是自己想删的那一个，可以要求继续翻页。#### 确认流程（硬约束）**无论精确还是模糊，无论命中 1 条还是多条，发起删除前都必须先把候选列给用户**，由用户明确回选一个 `space_id`。不要因为"只命中一条"就跳过确认直接删。
references/lark-wiki-delete-space.md:193In the instructions
> [!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:145In the instructions
**边翻边匹配**：每拿一页就在已累计的 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:5In the instructions
删除一个飞书知识空间（知识库）。OpenAPI 对应 `DELETE /open-apis/wiki/v2/spaces/:space_id`。- **不可逆**：该操作会将知识空间连同其下所有节点彻底删除，执行前必须反复确认- **同步 / 异步两种返回**：
references/lark-wiki-delete-space.md:187In the instructions
用户明确选定 `space_id` 后：```bashlark-cli wiki +delete-space --space-id <RESOLVED_SPACE_ID> --yes```> [!IMPORTANT]> 删库不可逆。关键不变量：**发给服务端的 `--space-id` 必须是用户在上一轮对话里明确指认过的那一个**，不是 LLM 单方面"从匹配结果自动选"。
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 2
Medium risk

Adding administrators or removing members has no enforced confirmation gate

Source references: 3
What we found

member-add can grant admin, described as full space administration, and member-remove can revoke an existing grant; both explicitly lack a --yes confirmation. Although the Skill resolves member types first, a mistaken same-name person, group, space, or role would still cause an immediate permission change.

Why this matters

An unintended administrator could read, modify, or manage the entire space. An incorrect removal could interrupt a legitimate user’s or administrator’s access. Removal is reversible only if the original member ID, type, and role are known.

Supported. Member-add can grant admin (full space administration) without a `--yes` gate, and member removal likewise has no confirmation gate. A mistaken resolution of a same-name person, group, space, or role would immediately change access. Removal is reversible only if the original grant tuple is known. Users can require a preview and explicit confirmation of the space ID, member identity, type, and role, using dry-run/member-list first.

references/lark-wiki-member-add.md:3In the instructions
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.
Show 2 other places
references/lark-wiki-member-add.md:35In the instructions
|------|------|----------|---------|-------------|| `--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:3In the instructions
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.
Medium risk

Creating a node as bot also grants full_access to the current CLI user

Source references: 2
What we found

When --as bot is used, the CLI does more than create the resource: it attempts to grant management access on the new node to the “current CLI user.” This permission change is bundled into creation rather than exposed as a separate opt-in or confirmation step.

Why this matters

If the locally authenticated CLI user is not the intended recipient, that account may gain management control over the new node. Creation can also succeed while the grant fails, producing a partially completed result that downstream handling may misunderstand.

Supported, specifically when creating a node with `--as bot`. After creation, the CLI automatically attempts to grant the local “current CLI user” full_access to the new node; this is not exposed as a separate option or confirmation. The identified user gains management access, and a failed grant does not undo node creation. Users can ask for an opt-out, verify which person the stored open_id identifies, or restrict creation to user identity when the bundled grant is unwanted.

references/lark-wiki-node-create.md:59In the instructions
- `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` 表示该资源已授予“可管理权限”>
Show 1 other places
references/lark-wiki-node-create.md:128In the instructions
  - 同时需要 `my_library` 和父节点时：会展示三步调用链- **bot 自动授权**：若使用 `--as bot`，结果还会额外带上 `permission_grant`，用于说明是否已自动为当前 CLI 用户授予新建节点的可管理权限- **输出结果**：成功后会返回 `resolved_space_id`、`resolved_by`、`node_token`、`obj_token`、`obj_type`、`node_type`、`title` 等字段，便于后续继续操作- **结构限制**：返回 `131003` 表示触发了知识空间总节点数、目录深度或单个父节点直属子节点数等结构限制。这不是瞬时错误，禁止使用相同参数重试。根据上游错误信息选择更浅或其他父节点、重新组织现有节点，或清理/改用其他知识空间；不要在无法确认具体限制时盲目增加中间层级。
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

7 instruction sections

This Skill uses lark-cli to manage Lark wiki spaces, nodes, and members. It explicitly prefers user identity because an omitted identity may resolve from auto to bot and expose a different resource scope.

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

List operations fetch only one page by default. Continued pagination requires --page-all and is capped at ten pages by default. Member or node inventories may therefore be incomplete, although has_more and page_token indicate remaining data.

View source
references/lark-wiki-member-list.md:30In the instructions
| 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:66In the instructions
`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.

Wiki-space deletion has an explicit human confirmation flow: candidates must be shown and the user must select a specific space_id, after which the command still requires --yes. Deletion permanently removes the space and all its nodes.

View source
SKILL.md:34In the instructions
  - 只知名称：`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:5In the instructions
删除一个飞书知识空间（知识库）。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>` 继续查

Moving a node from Wiki to Drive changes its location and inherited permission model. The documentation requires confirming the source node, destination, and acting identity before execution.

View source
references/lark-wiki-move-to-drive.md:107In the instructions
## 权限与影响- CLI 写操作预检查使用 `space:document:move`，任务轮询使用 `wiki:space:read`。- 调用方必须能移动源 Wiki 节点并写入目标 Drive 文件夹。- 成功后源节点会从 Wiki 树中消失，目标文档改用 Drive 目标位置的权限模型；原 Wiki 层级继承权限不再保留。- 省略 `--folder-token` 时，“根目录”属于当前 `--as` 身份，user 与 bot 的可见资源范围可能不同。> [!CAUTION]> 这是会改变文档归属和权限继承的**写入操作**。执行前必须确认源 Wiki 节点、目标 Drive 位置和调用身份。
Start here · InstructionsSKILL.md
lark-wiki
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.

File reference map

References: 24
Files making referencesReferenced content
Lines show actual file references, not execution order. Select a node to highlight its connections and inspect the files and source locations. Dashed lines include files that still need locating.
Files and check records14 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included
  • references/lark-wiki-delete-space.mdFull text included
  • references/lark-wiki-member-add.mdFull text included
  • references/lark-wiki-member-list.mdFull text included
  • references/lark-wiki-member-remove.mdFull text included
  • references/lark-wiki-move-to-drive.mdFull text included
  • references/lark-wiki-move.mdFull text included
  • references/lark-wiki-node-copy.mdFull text included
  • references/lark-wiki-node-create.mdFull text included
  • references/lark-wiki-node-delete.mdFull text included
  • references/lark-wiki-node-get.mdFull text included
  • references/lark-wiki-node-list.mdFull text included
  • references/lark-wiki-space-create.mdFull text included
  • references/lark-wiki-space-list.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
  • references/lark-wiki-delete-space.mdSupporting file
  • references/lark-wiki-member-add.mdSupporting file
  • references/lark-wiki-member-list.mdSupporting file
  • references/lark-wiki-member-remove.mdSupporting file
  • references/lark-wiki-move-to-drive.mdSupporting file
  • references/lark-wiki-move.mdSupporting file
  • references/lark-wiki-node-copy.mdSupporting file
  • references/lark-wiki-node-create.mdSupporting file
  • references/lark-wiki-node-delete.mdSupporting file
  • references/lark-wiki-node-get.mdSupporting file
  • references/lark-wiki-node-list.mdSupporting file
  • references/lark-wiki-space-create.mdSupporting file
  • references/lark-wiki-space-list.mdSupporting file

Operations mentioned in code and instructions

Connect to websites
SKILL.md:37In the instructions
  - 用户明确选定后再执行 `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:87In the instructions
  "obj_type": "docx",  "url": "https://example.feishu.cn/docx/doxcnXXX"}
references/lark-wiki-node-get.md:20In the instructions
|------|------|----------|---------|-------------|| `--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 …
Run commands
SKILL.md:89In the instructions
```bashlark-cli schema wiki.<resource>.<method>   # 调用原生 API 前必须先查看 --data / --params 参数结构，不要猜测字段格式
references/lark-wiki-delete-space.md:14In the instructions
```bash# 同步或异步删除一个知识空间（必须显式加 --yes 确认）
references/lark-wiki-delete-space.md:122In the instructions
```bashlark-cli wiki +node-get \
Lines read
1,397
File checksum (to compare versions)
12bc12534ea597dac705314015281aedf3e1ec1ed06ed41a8f378712570e9f0a