skill-admission-gate

凡自治之物 · LGD 治理学 · 创造术家族 ｜ 评测协议：skill-quality-gate

English

When to use

Call this when you need to review a third-party skill, install a skill of unknown provenance, run pre-release security screening on an in-house skill, perform a supply-chain security assessment, or produce evidence that "this package is untampered and risk-assessed".

Usage

Entry script (run inside the skill directory): scan_skill.py.

Workflow

1. Trigger: identify a skill-admission-gate task (see When to use).
2. Execute: run scan_skill.py per Usage.
3. Verify: check script output / exit code against expectations.
4. Deliver: present results / artifacts to the user.

Executable implementation of the LGD Three Laws: registered (package fingerprint) · evidenced (scan evidence on record) · gated (verdicts and accepted risks must be signed). Rule set 1.0.0 · stdlib only · offline-runnable · no API key.

I. Why it is needed

The security problem of the skill ecosystem is not "are there malicious packages" but "there is no admission gate":

• Skills can execute arbitrary code, access the filesystem and make network requests — their permission surface equals a local program;
• Yet their distribution often looks like "a block of documentation" — review intuition fails;
• Once installed, it runs on your machine as you.

Conclusion: skills need a deterministic, traceable, re-auditable security checkpoint, not "looks fine".

II. When to use it

III. How to use

Single-skill review:

python scripts/scan_skill.py <skill-dir> [--json out.json]

Batch review (scan a skill root):

python scripts/scan_skill.py <skill-root> --batch --json batch-result.json

Output example:

skill: my-skill
verdict: WARN | BLOCK 0 | WARN 2 | accepted 0 | 6 files scanned
package fingerprint: cd23896eee940857
  [WARN] EXF-04 script.py:41  requests.post("https://api.example.com/collect", ...)

Exit codes: 0 = no BLOCK; 1 = BLOCK (usable as CI gate).

IV. Rule set (v1.0.0)

Verdict: any BLOCK hit → overall BLOCK; only WARN → WARN; none → PASS.

V. Accepted-risk mechanism (key design)

False positives are inevitable — e.g. a local-vault skill "reading " is its job, not exfiltration.

But "accepting a risk" must not be silent ignoring: it must be traceable and signed. Drop .admission-allow.json in the reviewed dir:

{
  "schema": "skill-admission-allow/1.0",
  "skill": "dpapi-local-vault",
  "note": "This skill's function is a local credential vault; accessing that dir is its declared use.",
  "allow": [
    {
      "rule": "EXF-02",
      "reason": "Reading/writing <local-vault> is its sole declared use; keys never leave plaintext or the machine.",
      "approved_by": "XLGD",
      "date": "2026-09-12",
      "mitigation": "This skill makes no network requests."
    }
  ]
}

After declaration the rule moves to ACCEPTED (still appears in the report, no verdict impact) — this is "gated + evidenced".

VI. Evidence produced ("evidenced")

Every review outputs:

Uses: release ledger, dispute forensics, version-regression comparison (fingerprint changed → re-review required).

VII. Boundaries & honesty

• Pattern matching has limits: this tool checks known patterns; it stops crude and common tricks but cannot replace human code audit; coverage of heavy obfuscation, logic backdoors and dependency-chain poisoning is weak.
• No sandbox execution: static review only; no dynamic behavior analysis.
• Rules evolve: verdicts depend on rule_version; align rule versions when comparing across versions.
• No security guarantee: PASS means "no hit against this rule set", not "secure".

VIII. Mapping to LGD

skill-admission-gate v1.0.1 · © XLGD · SynomosAI · 2026-09-12

中文

何时用

• 当需要审查第三方 skill、安装来源不明的技能、给自研技能做发布前安检、做供应链安全评估、或需要出具"该包未被篡改且已评估风险"的证据时调用。

用法

入口脚本（在技能目录下执行）：scan_skill.py。

流程

1. 触发：识别skill-admission-gate相关任务（见「何时用」）。
2. 执行：按「用法」运行scan_skill.py。
3. 校验：核对脚本输出/退出码是否符合预期。
4. 交付：向用户呈现结果/产物。

LGD 三律的可执行实现：有籍（包指纹）· 有证（扫描证据留痕）· 有门禁（判定与已接受风险须署名）。 规则版本 1.0.0 ｜ 纯标准库 ｜ 离线可跑 ｜ 无需 API key

一、为什么需要它

技能生态的安全问题不是"有没有恶意包"，而是"没有上架闸门"：

• 技能可以执行任意代码、访问文件系统、发起网络请求——权限面等同于一个本地程序；
• 但其分发形式常看起来像"一段说明文档"，审查直觉失效；
• 一旦装上，它就在你的机器上以你的身份运行。

结论：技能需要一个确定性、可留痕、可复核的安检环节，而不是靠"看起来没问题"。

二、什么时候用

三、怎么用

单技能审查

python scripts/scan_skill.py <技能目录> [--json out.json]

批量审查（扫一个技能根目录）

python scripts/scan_skill.py <技能根目录> --batch --json batch-result.json

输出示例：

技能: my-skill
判定: WARN ｜ BLOCK 0 ｜ WARN 2 ｜ 已接受 0 ｜ 扫描 6 文件
包指纹: cd23896eee940857
  [WARN] EXF-04 script.py:41  requests.post("https://api.example.com/collect", ...)

退出码：0 = 非 BLOCK；1 = BLOCK（可用于 CI 阻断）。

四、规则集（v1.0.0）

判定口径：命中任一 BLOCK → 整体 BLOCK；仅命中 WARN → WARN；无命中 → PASS。

五、已接受风险机制（关键设计）

误报是必然的——例如本地保险库技能"读 <local-vault>"是其本职，不是外泄。

但"接受风险"不能靠静默忽略，必须留痕、必须署名。 在被审目录放 .admission-allow.json：

{
  "schema": "skill-admission-allow/1.0",
  "skill": "dpapi-local-vault",
  "note": "本技能功能即本地凭据保险库，访问该目录是其声明用途。",
  "allow": [
    {
      "rule": "EXF-02",
      "reason": "读写 <local-vault> 是其唯一且声明的用途；密钥不落明文、不出本机。",
      "approved_by": "XLGD",
      "date": "2026-09-12",
      "mitigation": "本技能不发起任何网络请求。"
    }
  ]
}

声明后该规则转入 ACCEPTED 分类（仍出现在报告里，但不影响判定）——这就是"有门禁 + 有证"。

六、产出的证据（"有证"）

每次审查都输出：

用途：上架台账、争议取证、版本回归比对（新版本指纹变了 → 须重审）。

七、边界与诚实声明

• 模式匹配有极限：本工具查的是已知模式，能拦住粗糙与常见手法，不能替代人工代码审计；对高度混淆、逻辑后门、依赖链投毒（第三方库）覆盖不足。
• 不做沙箱执行：只做静态审查，不运行动态行为分析。
• 规则会演进：判定依赖 rule_version；跨版本比较结论时须对齐规则版本。
• 不构成安全保证：PASS 表示"未命中本规则集"，不等于"安全"。

八、与 LGD 的对应

证据与安全声明

• 证据：TBD（暂无评测/徽章链接；产生后在此更新实际链接）
• 版本：1.0.1
• 安全：未做独立安全扫描（TBD），结论待补；补全前不作推荐背书。