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 to the entire subtree by default

Source references: 2
What we found

`+node-delete` defaults `--include-children` to `true`. Although `--yes` is required, the instructions do not require listing descendants or separately confirming the cascade, so “delete this page” can delete the page and every child page.

Why this matters

The document hierarchy and content below the selected node may be irreversibly deleted, far beyond the single node the user identified.

The documented command semantics support this risk: deletion is irreversible and `--include-children` defaults to `true`, so confirming deletion of one page without understanding the cascade may also delete its subtree. `--yes` blocks an unconfirmed request, but the shown guidance does not require listing descendants or separately confirming the cascade. A user can ask the author to show affected descendants and require distinct confirmation for `include_children=true`.

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

Name-based space deletion may hide later duplicate names due to early pagination stop

Source references: 3
What we found

Name resolution stops paging after the first accumulated exact match, and the documentation acknowledges that later spaces with the same name may be missed. Although the user selects a `space_id`, an incomplete list can make the sole displayed candidate appear definitive.

Why this matters

The user may confirm the wrong `space_id`, after which the entire space and all its nodes are irreversibly deleted.

The documentation expressly acknowledges that pagination stops after the first accumulated exact match and may omit same-named spaces on later pages. Mandatory candidate display and explicit `space_id` selection substantially reduce automatic deletion risk, but the user is still choosing from a potentially incomplete set and may infer uniqueness incorrectly. Users can require complete pagination for name-based deletion, or a clear incomplete-results warning with an option to continue searching.

references/lark-wiki-delete-space.md:143In the instructionsOpen original file
#### 翻页与匹配策略**边翻边匹配**：每拿一页就在已累计的 items 上对 `name` 做精确匹配（区分大小写、保留空格），满足任一条件即停止翻页：- (A) **累计精确匹配 ≥ 1 条** → 停止翻页，已找到目标- (B) **`has_more=false`**（已翻完所有页）→ 停止翻页结束后：1. 如果累计精确匹配 ≥ 1：把**所有**精确匹配作为候选列给用户2. 如果精确匹配 = 0（此时必然已走到 `has_more=false`，已收集全量 items）：在全量 items 上做**宽松匹配**（`name` trim 空格 + 大小写不敏感 + 子串包含），作为候选3. 宽松匹配也 0 条：停下来问用户是不是名字拼错、或者调用方没权限看到这个空间；**不要**自己改名字重试> 不做更激进的归一化（比如去括号、去版本号尾缀），那些容易把 "客户台账（归档）" 误命中到 "客户台账"。#### 早停的小边界早停（条件 A）意味着**可能漏掉**位于更后面页的同名空间。这种重名 corner case 由下面的"用户确认"兜底：LLM 展示候选时应照抄 `name + space_id`，用户如果觉得不是自己想删的那一个，可以要求继续翻页。
Show 2 other places
references/lark-wiki-delete-space.md:193In the instructionsOpen original file
> [!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:162In the instructionsOpen original file
#### 确认流程（硬约束）**无论精确还是模糊，无论命中 1 条还是多条，发起删除前都必须先把候选列给用户**，由用户明确回选一个 `space_id`。不要因为"只命中一条"就跳过确认直接删。列候选时至少包含以下字段，方便用户分辨：- `name`（原始值，不做归一化）- `space_id`- `space_type`（`team` / `person` 等）- `description`（若有）- `visibility`（若有）
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

Bot-created nodes automatically grant management access to the current CLI user

Source references: 2
What we found

When a node is created as a bot, the CLI attempts to grant `full_access` to the “current CLI user.” This is an additional permission change beyond node creation, with no separate approval or displayed `open_id`.

Why this matters

The person represented by local authentication may receive management access even when the user authorized only bot-based creation; a mismatched local account could extend control to an unintended person.

This is an active permission change beyond creation: after a successful `--as bot` creation, the CLI attempts to grant the current CLI user `full_access` to the new node, without a separate confirmation or a displayed target `open_id` in the shown flow. The effect is limited to that user and new node; it skips when no user ID is available, reports failure, and forbids automatic owner transfer. Users can ask that the target account be shown and the grant be opt-in.

references/lark-wiki-node-create.md:61In the instructionsOpen original file
> [!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:59In the instructionsOpen original file
- `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` 表示该资源已授予“可管理权限”>> **不要擅自执行 owner 转移。** 如果用户需要把 owner 转给自己，必须单独确认。
Medium risk

Member and administrator access can be granted or revoked without a confirmation gate

Source references: 5
What we found

Both member addition and removal use APIs marked dangerous but have no `--yes` gate. Addition permits the `admin` role, which grants full space administration. The instructions resolve IDs but do not require showing the resolved space, identity, member, and role for user confirmation.

Why this matters

A mistaken name match, account context, or role can grant full administration to the wrong party or immediately revoke a legitimate member or administrator.

Adding and removing members are real account-permission changes, and the documentation explicitly says these dangerous APIs have no `--yes` gate. Addition can grant `admin`, described as full space administration. Although the main instructions require resolving the target type and ID first, and removal must match the original grant, the shown rules do not require displaying and confirming the space, caller identity, member, and role before execution. Users can restrict use to dry-run and require full target confirmation for every grant, revocation, or role change.

references/lark-wiki-member-add.md:33In the instructionsOpen original file
| Flag | Type | Required | Default | Description ||------|------|----------|---------|-------------|| `--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` |
Show 4 other places
references/lark-wiki-member-remove.md:3In the instructionsOpen original file
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.
SKILL.md:72In the instructionsOpen original file
- 调用 `lark-cli wiki +member-add` 前，先把自然语言里的“人 / 群 / 部门 / 应用”解析成正确的 `--member-id`，不要猜格式。- 用户场景默认优先 `--member-type=openid`：用 `lark-cli contact +search-user --query "<姓名/邮箱/手机号>" --format json` 获取 `open_id`。- 群组场景使用 `--member-type=openchat`：用 `lark-cli im +chat-search --query "<群名关键词>" --format json` 获取 `chat_id`。- 应用场景使用 `--member-type=appid`：`--member-id` 传应用 ID，格式通常为 `cli_xxx`。- `userid` / `unionid` 只在下游明确要求时才使用；先拿到 `open_id`，再调用 `lark-cli api GET /open-apis/contact/v3/users/<open_id> --params '{"user_id_type":"open_id"}' --format json` 读取 `user_id` / `union_id`。- 部门场景使用 `--member-type=opendepartmentid`：当前 CLI 没有 shortcut，需调用 `lark-cli api POST /open-apis/contact/v3/departments/search --as user --params '{"department_id_type":"open_department_id"}' --data '{"query":"<部门名>"}'` 获取 `open_department_id`。- 只有在目标类型和身份都已确认可行后，才调用 `lark-cli wiki +member-add`。对于部门场景，这意味着必须是 `--as user`。
references/lark-wiki-member-add.md:3In the instructionsOpen original file
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.
references/lark-wiki-member-add.md:35In the instructionsOpen original file
|------|------|----------|---------|-------------|| `--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` |
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 the installed `lark-cli` to call Lark Wiki APIs as a user or bot, including querying, creating, moving, copying, and deleting spaces/nodes and managing members; these operations affect live cloud resources.

View source
SKILL.md:4In the instructionsOpen original file
version: 1.0.3description: "飞书知识库：管理知识空间、空间成员和文档节点。创建和查询知识空间、查看和管理空间成员、管理节点层级结构、在知识库中组织文档和快捷方式。当用户需要在知识库中查找或创建文档、浏览知识空间结构、查看或管理空间成员、移动或复制节点时使用。当用户给出 doubao.com 的 /wiki/ URL/token 时，也应直接使用本 skill，不要因为域名不是飞书而回退到 WebFetch；路由依据是 URL 路径模式和 token，而不是域名。不负责：上传文件到知识库节点下（走 lark-drive）、编辑文档/表格/Base 内容（走 lark-doc / lark-sheets / lark-base）。"metadata:  requires:    bins: ["lark-cli"]  cliHelp: "lark-cli wiki --help"---
SKILL.md:89In the instructionsOpen original file
```bashlark-cli schema wiki.<resource>.<method>   # 调用原生 API 前必须先查看 --data / --params 参数结构，不要猜测字段格式lark-cli wiki <resource> <method> [flags]  # 调用 API```

The Skill prefers explicit user identity because omitting `--as` may resolve to bot identity; this determines which resources are visible, which personal library is used, and whose account context receives writes.

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

The Skill includes irreversible deletion, permission grants/revocations, and moves that change document location and inherited permissions. Space and node deletion have a `--yes` gate, while member changes do not.

View source
references/lark-wiki-delete-space.md:5In the instructionsOpen original file
删除一个飞书知识空间（知识库）。OpenAPI 对应 `DELETE /open-apis/wiki/v2/spaces/:space_id`。- **不可逆**：该操作会将知识空间连同其下所有节点彻底删除，执行前必须反复确认- **同步 / 异步两种返回**：
references/lark-wiki-member-add.md:3In the instructionsOpen original file
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.
references/lark-wiki-move-to-drive.md:109In the instructionsOpen original file
- 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 instructionsOpen original file
  - 用户明确选定后再执行 `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 instructionsOpen original file
  "obj_type": "docx",  "url": "https://example.feishu.cn/docx/doxcnXXX"}
references/lark-wiki-node-get.md:20In the instructionsOpen original file
|------|------|----------|---------|-------------|| `--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 instructionsOpen original file
```bashlark-cli schema wiki.<resource>.<method>   # 调用原生 API 前必须先查看 --data / --params 参数结构，不要猜测字段格式
references/lark-wiki-delete-space.md:14In the instructionsOpen original file
```bash# 同步或异步删除一个知识空间（必须显式加 --yes 确认）
references/lark-wiki-delete-space.md:122In the instructionsOpen original file
```bashlark-cli wiki +node-get \
Lines read
1,397
File checksum (to compare versions)
c78c8c1d9d2ffa9c8481657490392a6b82d808ad6872c629794325965ac7b5eb