# ClawScan 通过不等于生产授权：用安全边际与反演思维守住插件边界

> 扫描通过只是入场券，不是生产授权书

```text
[读者] 平台与 Skill 开发者、安全工程师
[痛点] 插件过审即上线，运行时越权无人兜底
[现在读] A.I.G 接入 ClawHub，过审误解正在扩散
[读完] 用安全边际与反演思维设计上线防线
```

```text
[旧方案] 扫描通过即发布插件
    |
    v
[新需求] 插件能调工具、读文件、拉依赖、发外网
    |
    v
[冲突] 扫描只覆盖已知样本与当前版本
    |
    v
[后果] 运行时被诱导越权，密钥外泄
```

我是老李，这几年一直在做平台侧的插件与工具治理。团队里最常见的动作，是把自研 Skill 打包、提审、看绿灯，然后点发布。绿灯亮起的那一刻，所有人都默认“安全了”。

这次变化来自外部。OpenClaw 官方博客宣布，腾讯朱雀实验室开源的 A.I.G 加入 ClawHub 安全审核，上传的 Skill 和插件会经它检查，被判定恶意的会被警告或下架。按官方说明，扫描器把说明与脚本、依赖、数据流统一处理，覆盖指令劫持、记忆污染等九类风险。

官方还披露了一组很漂亮的数字：以混元 Hy4 preview 为底座，在 MalSkillBench 7944 个样本上 F1 为 97.3%、误报率 5.5%，在 13 个受测系统中居首。需要看清楚的是，这是一套离线基准上的检测能力，不是线上运行时的安全概率。

扫描通过，到底证明了什么？

我们该把它当安全证明，还是当风险筛选？

如果通过之后仍被突破，代价由谁承担？

# 01、故事

现场是这样的：一个自研 Skill，功能是读工作区文件、生成摘要，再调用一个整理笔记的工具。那次任务是把它和另外两个插件一起上架到 ClawHub，并且保证它不会读到不该读的文件。

当时的方案很朴素：打包、提审、等结果。A.I.G 接入之后，审核项变多了，大家反而更放心——“官方都扫过了”。

变化在于权限。这个插件要读文件、要联网、要调工具。扫描面对的是一个静态快照，而插件在运行时要面对真实输入、真实依赖、真实会话。

冲突就在这里：扫描管的是“这个包像不像坏的”，运行时管的是“它现在能做什么”。前者是判断，后者是边界。把判断当边界用，迟早出事。

> 一纸过关易
> 一墙失守快
> 过审非授权
> 边界须自守

# 02、问题

旧方案失效得很直接：过审不等于授权，扫描分数不等于放行许可。

业务影响是三个层面。用户层面，工作区文件、会话记忆、凭据可能被读取或外传；平台层面，一旦发生越权，审核体系的可信度会被反噬；工程层面，出了事只能紧急下架，缺少可回滚、可撤销的预案。

技术表现也很具体：运行时动态拉取依赖、被用户输入诱导调用高权限工具、密钥出现在不该出现的上下文里、跨租户或跨项目读到别人的数据。这些都不是“包长什么样”的问题，而是“运行时被允许做什么”的问题。

可验证的完成标准，我给自己定了五条：上架前有说明、脚本、依赖与外传路径的审计证据；依赖锁定版本与签名，更新后重新扫描；文件、网络、凭据、工具权限按项目隔离，敏感动作二次确认；有沙箱灰度与越权、异常外联监控；能在分钟内下架并撤销密钥。

> 旧法已失效
> 新险在运行
> 影响可量化
> 标准要可验

# 03、原理

这一篇只需要两个模型，它们都来自芒格。

安全边际：给未知故障保留限制与缓冲，不把一次成功视为永久安全。放到插件上，就是即使这次扫描通过，也要假设下一次运行时可能出错，所以权限要留余量、动作要能回滚、凭据要能撤销。

反演思维：先假设审核失败，再倒推最可能被突破的路径。不要问“它为什么是安全的”，要问“如果它明天被攻破，会从哪进来”。答案通常是动态依赖、诱导工具调用、密钥暴露、跨租户访问这四条。

反直觉判断：扫描器的检测能力越强，越容易诱使团队削减权限边界。因为绿灯给了确定感，而最小权限带来的是持续成本。可扫描器覆盖的是已知样本、当前规则与当前版本，运行时仍然会被新出现的动态依赖、新的诱导话术、新的供应链版本绕过。

第二个反直觉判断：97.3% 的 F1 不是部署后的安全概率。它是离线样本集上的检测指标，反映的是“在 7944 个已知样本上判得准不准”，和“你的插件在生产里会不会被突破”是两个问题，也不能和官方另一套测试的结果混算。把基准指标当成上线许可，是把方法当结论。

> 强者易生骄
> 样本非现实
> 先设败之局
> 再留余之量

# 04、架构

```text
[输入] 待上架 Skill/插件包
    |
    v
[模块] ClawScan / A.I.G 扫描审核层
    |
    v
[数据/状态] 依赖锁、权限清单、审计证据
    |
    v
[处理] 沙箱灰度 + 运行时监控 + 敏感动作二次确认
    |
    v
[输出] 放行 / 降级 / 下架并撤销凭据
```

边界：这套分层只解决“已知风险被看见”和“未知风险被限制”。它不承诺插件绝对安全，也不承诺扫描能覆盖未来版本的依赖与新的诱导手法。

收益：明显恶意的包被挡在入口，运行时的高危动作被权限与确认拦住，出事时有一条可执行的下架与撤销路径。

代价：上架流程变长，需要维护权限清单、依赖锁定和审计证据；灰度阶段需要额外的观察资源；二次确认会略微影响体验。

适用条件：任何能调用工具、访问文件或网络的插件都适用；纯展示型、无副作用、无外部访问的插件可以适度裁剪，但不能因为“它很简单”就跳过依赖溯源。

> 分层设关隘
> 状态握在手
> 有权亦有限
> 可控方可放

# 05、实战一次

V1 的目标很小：在提审之前，本地跑一遍“上架前审计清单”，把证据落盘。

环境与依赖：Linux 环境，Python 3.11，脚本只用标准库；A.I.G/ClawScan 的扫描环节按官方仓库与当前官方文档执行。以下脚本为本文设计的清单校验器，未在当前环境实测，以下为预期结果。

先写清单文件：

```json
{
  "name": "note-summarizer",
  "entry": "skill.py",
  "dependencies": [
    {"name": "requests", "version": "2.32.3", "sha256": "<package-hash>"}
  ],
  "egress_allowlist": ["api.example.com"],
  "filesystem": {
    "read": ["./workspace"],
    "write": ["./workspace/out"]
  },
  "tools": [
    {"name": "read_file", "sensitive": true, "confirm": true}
  ]
}
```

再写校验器：

```python
import hashlib
import json
import pathlib
import sys

ROOT = pathlib.Path(__file__).resolve().parent
MANIFEST = ROOT / "skill-manifest.json"

def sha256(path: pathlib.Path) -> str:
    h = hashlib.sha256()
    h.update(path.read_bytes())
    return h.hexdigest()

def main() -> int:
    manifest = json.loads(MANIFEST.read_text(encoding="utf-8"))
    problems = []

    deps = manifest.get("dependencies", [])
    for dep in deps:
        if not dep.get("version") or not dep.get("sha256"):
            problems.append(f"依赖未锁版本或缺哈希: {dep.get('name')}")

    egress = manifest.get("egress_allowlist", [])
    if not egress:
        problems.append("未声明外联白名单")

    fs = manifest.get("filesystem", {})
    for key in ("read", "write"):
        scope = fs.get(key, [])
        if scope == "*" or (isinstance(scope, list) and "*" in scope):
            problems.append(f"文件权限过宽: {key}")

    for tool in manifest.get("tools", []):
        if tool.get("sensitive") and not tool.get("confirm"):
            problems.append(f"敏感工具缺少二次确认: {tool.get('name')}")

    entry = manifest.get("entry")
    evidence = {
        "skill": manifest.get("name"),
        "entry": entry,
        "entry_sha256": sha256(ROOT / entry) if entry else None,
        "dependency_count": len(deps),
        "egress_allowlist": egress,
        "problems": problems,
    }
    print(json.dumps(evidence, ensure_ascii=False, indent=2))
    return 1 if problems else 0

if __name__ == "__main__":
    sys.exit(main())
```

启动与验证：

```bash
python audit_manifest.py
```

当清单齐备时，预期输出如下（示例输出）：

```json
{
  "skill": "note-summarizer",
  "entry": "skill.py",
  "entry_sha256": "<entry-hash>",
  "dependency_count": 1,
  "egress_allowlist": ["api.example.com"],
  "problems": []
}
```

把清单里 `version` 删掉、或把 `filesystem.read` 改成 `"*"`，退出码会变成 1，`problems` 里出现对应条目。V1 到此只解决了“证据有没有”的问题，运行时会不会被绕过，它一概不管。

> 先跑通一步
> 再谈稳与安
> 最小可验证
> 证据留痕迹

# 06、排查

第一条诊断链。

现象：Skill 在沙箱里表现正常，进入灰度后出现异常外联，目标域名不在白名单里。

怀疑：扫描只针对上架时的静态快照，运行时动态拉取的依赖没被覆盖。

检查：比对提审时记录的依赖哈希与运行时实际加载的模块。

证据（示例日志格式）：

```log
[audit] skill=note-summarizer entry_sha256=<entry-hash>
[audit] deps_locked=1 deps_loaded=2
[audit] loaded=remote://cdn.example.net/helper-v2.js not_in_manifest=true
[egress] blocked host=cdn.example.net reason=not_in_allowlist
```

根因：动态依赖未被扫描与清单覆盖，运行时因此获得了一段未经检查的代码。

修复：依赖锁定版本与哈希，加载前校验签名；外联按白名单拦截；清单更新后重新扫描再灰度。

**错误尝试：** 起初我们认为“扫描已经到 97.3% 的 F1，放行没问题”，于是跳过了依赖锁定。这个判断是错的——F1 是离线样本集上的检测能力，不是部署后的安全概率，它既不能覆盖运行时新拉取的代码，也不能和官方另一套测试混算成一句“更安全了”。

第二条诊断链。

现象：Skill 自身没做坏事，但被一段用户输入诱导调用了删除类工具，删掉了工作区文件。

怀疑：指令劫持在运行时才被触发，静态扫描看不到这段交互。

检查：查审计日志里的工具调用序列与会话来源。

证据（示例记录）：

```json
{
  "session": "s-2f31",
  "skill": "note-summarizer",
  "tool": "delete_file",
  "confirm": false,
  "credential_scope": "shared-project",
  "trigger": "user_input_embedded_instruction"
}
```

根因：检测规则针对已知样本，而权限边界缺失，敏感动作没有二次确认，凭据还是跨项目共享的。

修复：按项目隔离文件、网络、凭据与工具权限；敏感动作强制二次确认；跨租户访问一律拒绝。

> 现象引怀疑
> 证据定根因
> 错试须记录
> 修复要闭环

# 07、优化

根因一：动态依赖不在扫描视野内。修改方式是固定依赖版本、签名及供应链来源，任何更新都触发重新扫描后才能灰度。原因是扫描只对当前版本负责，版本一变结论就失效；新行为是加载前校验哈希与签名，失败即拒绝启动；验证方式是把未纳入清单的远程依赖作为负样本，观察是否被拦。

根因二：敏感动作没有边界与确认。修改方式是按项目隔离文件、网络、凭据和工具权限，敏感动作二次确认。原因是扫描判断“像不像坏”，权限决定“最多能坏到哪”；新行为是越权调用直接被拒，凭据只在单项目作用域内有效；验证方式是构造诱导指令，观察是否仍能触发删除或外发。

根因三：出事之后缺乏止损手段。修改方式是灰度沙箱运行、监控越权与异常外联，并保留立即下架与撤销密钥的能力。原因是安全边际要求给未知故障留缓冲；新行为是异常出现时可快速切断；验证方式是演练一次下架与撤销流程，确认生效时间与影响范围。

边界与验证方法：用恶意指令、记忆污染、动态下载、正常插件四类做正负样本，分别统计误报、漏报与沙箱拦截率。这里只写方法，不写未实测的数字。

> 根因既已明
> 改法自有据
> 新行为可测
> 取舍要写清

# 08、演进

```text
[同一输入] 待上架 Skill 包
    |
    +--[V1] 扫描通过即放行 / 代价：运行时无兜底
    |
    +--[V2] 扫描 + 权限最小化 + 沙箱灰度 + 可撤销
    |
[Trade-off]
得到：运行时伤害被限制、出事可止损
失去：上架速度、清单维护与灰度观察成本
适用边界：能调工具、读文件、连外网的插件必须走 V2
```

正确性上，V1 把“检测结果”当“授权结论”，V2 把检测当筛选、把权限当边界，两者在动态依赖与诱导调用场景下结论完全不同。

稳定性上，V1 一旦运行时有新依赖或新话术就失稳；V2 依赖锁定与白名单让行为可预期，但引入了清单漂移的维护风险。

复杂度上，V1 是一条流水线，V2 是四条（审计、锁定、隔离、灰度监控），运维成本明显上升。

成本上，V1 省的是流程时间，代价是事故时的被动；V2 花的是持续人力，换的是可控的损害上限。

适用范围上，V1 只适合无副作用、无外部访问的展示型插件；V2 是所有能产生副作用的插件的默认选项。

遗留问题很明确：误报与漏报仍会存在，正负样本的统计口径需要长期维护；跨租户隔离的粒度是否足够，需要在真实多租户场景里继续验证。

> 同一输入下
> 两版各取舍
> 得失常相伴
> 边界定适用

# 09、洞见

## 9.1 扫描是筛子，不是闸门

反直觉判断：审核越严，团队越容易在权限上偷懒。因为严格审核带来了“已经安全”的心理账户，而权限最小化是持续成本。正确做法是把扫描放在入口做筛选，把权限放在运行时做闸门，两者职责不重叠。

## 9.2 97.3% 不是部署后的安全概率

反直觉判断：一个漂亮的基准数字，最容易在评审会上被当成上线许可。F1 97.3%、误报率 5.5% 是在 MalSkillBench 7944 个样本上、针对已知规则与当前版本的结果，它回答的是“判得准不准”，不是“上线会不会被突破”，也不能与官方另一套测试混算。

## 9.3 最小权限决定伤害的上限

反演思维的落点不是“怎么防住”，而是“万一没防住，最多能坏多少”。插件扫描负责发现风险，最小权限负责限制伤害，后者才是安全边际在工程上的具体形态。

## 9.4 可撤销比可检测更接近底线能力

反直觉判断：大家愿意投在检测能力上，却不愿意投在撤销能力上。但当未知故障发生时，分钟级的立刻下架与密钥撤销，往往比多一个检测规则更能控制损失，也更容易被验证。

> 洞见出证据
> 判断有边界
> 反直觉常在
> 常识须重审

# 10、系统落地

原来有的：一条提审流水线，以及一个“通过即发布”的默认动作。

本篇新增的：上架前的审计清单与证据落盘；依赖锁定、签名与供应链溯源；文件、网络、凭据、工具权限的项目级隔离与敏感动作二次确认；灰度沙箱运行与越权、异常外联监控；正负样本的验证口径。

现在能做的：在提审之前就拿到一份可核对的证据；在运行时把高危动作挡住；在异常出现时快速下架并撤销凭据，而不是等事故发生后再讨论。

还缺的：跨租户隔离的细粒度验证；清单漂移的自动检测；正负样本统计口径的长期维护；以及“撤销动作本身会不会误伤其他插件”的演练。

下一步演进方向：把审计证据接入发布流程，让它成为准入的一部分而不是附件；把权限清单与运行时实际行为做持续比对，出现偏差即告警；把正负样本集当作回归测试长期跑，让误报与漏报有可追踪的趋势线。

> 原有加新增
> 能力可交付
> 缺口仍存在
> 演进不停步

# 11、小结

```text
Q1 → 扫描通过证明的是：在已知样本与当前版本上，这个包没有触发已知风险模式
Q2 → 它应被当作风险筛选，而非安全证明；安全证明来自权限边界与可撤销能力
Q3 → 代价由发布方与平台共同承担，因此必须提前准备止损手段
状态 → 可交付：审计证据 + 依赖锁定 + 权限隔离 + 沙箱灰度 + 可撤销预案
```

> 一问一答案
> 状态可交付
> 能力有边界
> 下一步再走

# 12、作业

## 12.1 理解题：为什么说 97.3% 的 F1 不是部署后的安全概率？

参考答案：该指标来自 MalSkillBench 7944 个样本的离线评测，衡量的是针对已知样本、检测规则与当前版本的判定质量。生产环境面对的是动态依赖、诱导工具调用、密钥暴露与跨租户访问等运行时问题，二者不是同一个问题；它也不能与官方另一套测试的结果混算。

## 12.2 实战题：写一份插件上架前的审计清单，至少覆盖四类证据。

参考答案：一是说明与脚本的入口哈希；二是依赖的名称、锁定版本与哈希（含供应链来源）；三是数据外传路径与白名单域名；四是文件、网络、凭据、工具权限的声明，并对敏感工具标注二次确认。清单落盘为可核对的 JSON 证据，更新后重新扫描。

## 12.3 排障题：插件在沙箱正常，灰度后出现白名单之外的异常外联，怎么排查？

参考答案：先比对提审时记录的依赖哈希与运行时实际加载的模块，确认是否加载了清单外的远程代码；再查外联拦截日志确认目标域名与触发时机；根因通常是动态依赖未纳入扫描覆盖。修复是依赖锁定与签名校验、外联白名单拦截、清单更新后重新扫描再灰度。注意不要把基准 F1 当作放行依据。

## 12.4 架构判断题：既然扫描已经覆盖九类风险，是否可以直接省掉权限隔离以提升上架效率？

参考答案：不建议。扫描覆盖的是已知样本与当前版本，隔离解决的是伤害上限问题。省掉隔离会让运行时越权、密钥暴露和跨租户访问失去兜底，也无法在事故时快速止损。效率应通过清单模板化、流程自动化来提升，而不是通过削减边界。

> 理解辨真伪
> 实战练闭环
> 排障重证据
> 架构判取舍

# 13、思考

回到最初那个冲突：扫描通过，和插件能不能上线，是两件事。前者是一次基于已知样本与当前版本的判断，后者是一个需要在运行时承担后果的授权决定。

芒格的两个模型在这件事上的落点非常清楚。安全边际要求我们给未知故障留限制与缓冲，所以权限要最小、依赖要锁定、动作要能撤销；反演思维要求我们先假设审核失败，所以要先问“最可能从哪被突破”，再去补那条路径。

真正可复用的工程判断只有一句：把检测交给扫描器，把伤害上限握在自己手里。绿灯亮起时，该做的事不是点发布，而是确认边界是否已经画好。

> 扫描找风险
> 权限限伤害
> 一证定边界
> 一役见真章

我是老李，这几年一直在做平台侧的插件与工具治理。团队里最常见的动作，是把自研 Skill 打包、提审、看绿灯，然后点发布。绿灯亮起的那一刻，所有人都默认“安全了”。

技术思考问题22：OpenClaw过审就敢放权？

A.I.G 接入 ClawHub 审核是一道重要防线，但扫描通过不等于生产授权。用安全边际与反演思维，为插件补上最小权限、沙箱灰度与可撤销预案。

架构师

安全

人工智能

架构设计

扫描通过仅证明已知样本与当前版本无风险，非生产授权。权限边界与可撤销能力才是安全核心，需依赖锁定、审计证据、运行时监控兜底。

回归测试

代码解释

数据流

OpenClaw

Linux

JSON

热销域名限时优惠，新客首年免费！


domain

CDN免费试用


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

技术思考问题22：OpenClaw过审就敢放权？-腾讯云开发者社区-腾讯云

技术思考问题22：OpenClaw过审就敢放权？

技术思考问题22：OpenClaw过审就敢放权？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐