每天一个开源项目#36 dcg：3.3K Stars 的 AI 命令安全闸门，亚毫秒拦截灾难操作

每天一个开源项目#36 dcg：3.3K Stars 的 AI 命令安全闸门，亚毫秒拦截灾难操作

GitHub Trending 日榜第 1/17 · 数据快照：2026-07-13 · 3,372 Stars · 124 Forks · 主语言 Rust · 许可证 自定义 MIT（带 OpenAI/Anthropic 限制条款）

项目地址：Dicklesworthstone/destructive_command_guard

📋 项目概览

项目	信息
项目名	dcg（Destructive Command Guard）
一句话定位	在 AI 编码代理执行 Shell/Git 命令前，拦截可能破坏代码、数据与基础设施的操作
Trending 排名	第 1 名（当日共抓取 17 个项目）
Stars / Forks	3,372 / 124（Trending 快照）
Open Issues/PRs	10（GitHub 该字段包含 Issue 与 PR）
主语言	Rust 88.2%，Shell 8.6%，PowerShell 3.0%，Python 0.2%
当前版本	v0.6.5（2026-07-03 发布；主分支 Cargo.toml 同为 0.6.5）
技术栈	Rust 2024、regex/fancy-regex、Aho-Corasick、memchr、ast-grep、tree-sitter、Serde
兼容对象	Claude Code、Codex CLI、Gemini CLI、Copilot CLI/Chat、Cursor、Hermes Agent、Grok 等
许可证判断	GitHub API 为 NOASSERTION；实际 LICENSE 是带额外排除条款的修改版 MIT，不应等同标准 MIT/OSI 开源许可

🔥 为什么值得关注

AI 编码代理正在从"生成建议"走向"直接操作终端"。一旦代理获得 Shell 权限，错误的 git reset --hard、rm -rf、DROP TABLE 或 kubectl delete namespace 就不再只是回答质量问题，而是会在数秒内变成不可逆的数据损失。dcg 把安全控制点放在模型输出与命令执行之间：命令真正进入 Shell 前，先经过本地规则引擎，再由 Hook 协议返回允许、警告或拒绝。

它比简单的命令黑名单更值得研究。项目不仅识别直接输入，还会深入 heredoc、python -c、node -e、PowerShell 编码命令与嵌套 Shell，结合上下文消毒、路径归一化、双正则引擎和 AST 结构匹配降低绕过与误报。对每次终端调用都必须执行的安全 Hook 来说，"覆盖面"与"延迟"同样关键，dcg 因而专门设计了快速拒绝路径和硬超时预算。

不过，dcg 更准确的定位是高价值安全护栏，而非操作系统级沙箱。Hook 未覆盖的执行路径、代理先写脚本再运行、默认 fail-open、人工绕过以及错误配置仍可能留下缺口。它适合作为 Agent 安全的第一道门，而不是唯一一道门。

🏗️ 核心特性

1. 从 Git 扩展到完整工程基础设施的规则包

README 宣称提供 50+ Security Packs；对 2026-07-13 主分支源码做静态扫描，可识别 91 个生产规则包 ID、26 个类别（已排除测试夹具 ID）。覆盖范围包括：

• Git 与文件系统：reset --hard、强制清理、递归删除、覆盖式恢复；
• 数据库：PostgreSQL、MySQL、MongoDB、Redis、SQLite、Supabase；
• 云与容器：AWS、GCP、Azure、Docker、Podman、Compose；
• Kubernetes 与 IaC：kubectl、Helm、Kustomize、Terraform、Pulumi、Ansible；
• 消息、存储、密钥、监控、DNS、CDN、CI/CD、支付与 API Gateway。

规则并非全部"一刀切"。每条模式可带 Critical / High / Medium / Low 严重级别，默认分别映射到拒绝、警告或仅记录；安全变体、dry-run 参数和显式 allowlist 可优先放行。

# ~/.config/dcg/config.toml
[packs]
enabled = [
  "database.postgresql",
  "kubernetes.kubectl",
  "cloud.aws",
  "containers.docker",
]

2. 不只看命令表面：检测内联脚本与嵌套执行

单纯匹配 rm -rf 很容易被下面的形式绕过：

python -c "import shutil; shutil.rmtree('src')"
node -e "require('fs').rmSync('src', {recursive: true, force: true})"
bash -c 'git reset --hard HEAD~3'

dcg 的 heredoc/inline-script 管线先用 RegexSet 和 quote-aware scanner 判断是否值得深查，再提取脚本内容，最后通过 ast-grep/tree-sitter 对 Bash、Python、JavaScript、TypeScript、Ruby、Go、PHP 等语言进行结构匹配。PowerShell -EncodedCommand、cmd /c、Invoke-Expression、管道到解释器等入口也有专门触发器。

3. 低延迟热路径：先筛选，再做昂贵匹配

每条普通命令若都遍历全部规则，会让代理交互明显变慢。dcg 的优化策略是：

1. 用 memchr/关键字门控做 SIMD 友好的快速搜索；
2. 不含已启用规则包关键词的命令直接走快速允许路径；
3. 正则延迟编译，避免初始化整个规则库；
4. 约 85% 模式交给线性时间 regex，需要前后查找的约 15% 才交给 fancy_regex；
5. 回溯步数限制为 100,000，Hook 总评估预算默认上限为 200ms。

README 将产品描述为"sub-millisecond latency"，并给出一次 git reset --hard 的 explain 示例总耗时 12.9μs；这属于项目方示例而非本文独立基准。源码中的设计目标是：heredoc 非匹配触发检查低于 10μs、匹配低于 100μs，复杂 AST 分析才进入毫秒级路径。

4. 上下文感知，避免把"文本"误判为"执行"

这类工具最大的可用性风险是误报。比如：

grep "rm -rf" audit.log
git commit -m "document git reset --hard risk"

命令中虽然出现危险片段，但只是搜索词或提交信息。dcg 会先识别已知安全参数位置并遮罩，再做路径归一化与规则匹配；规则包还可定义 safe pattern，使"预览、只读、dry-run"先于 destructive pattern 生效。这说明它的核心并非黑名单数量，而是执行语义、参数位置与上下文顺序。

5. 多代理协议适配，而非假设所有 Hook 都长得一样

不同 Agent 的拒绝协议并不统一：Claude/Codex 使用 hookSpecificOutput，Hermes 使用 decision: block，Grok 使用 decision: deny，Gemini、Copilot、Cursor 又有各自输入字段。dcg 会检测调用方与载荷形状，输出对应的最小 JSON，且把面向人的富文本提示写到 stderr，避免污染机器读取的 stdout。

这一点很实用：安全规则只维护一份，协议差异集中在 Hook 适配层，减少"规则能匹配，但客户端不承认拒绝结果"的集成失败。

6. 不只实时拦截，还能进入 CI 与审计流程

• dcg test：只评估命令，不执行；退出码 0/1 可接入脚本；
• dcg explain：展示归一化结果、命中规则、阶段耗时和安全替代建议；
• dcg scan：扫描仓库内容，可输出 JSON、Markdown 或 SARIF 2.1.0；
• 历史与模拟：记录决策，分析规则影响；
• allow-once：短期、目录范围内的例外，可设单次使用；
• 外部 YAML 规则包：让组织维护私有策略。

🔬 技术架构深度解析

整体数据流

Agent 生成终端调用
        │
        ▼
┌────────────────────────────┐
│ Hook 输入/协议识别          │  Claude / Codex / Gemini / Hermes / Grok ...
└─────────────┬──────────────┘
              ▼
┌────────────────────────────┐
│ 配置合并与 Agent Profile    │  env > 显式文件 > 项目 > 用户 > 系统 > 默认值
└─────────────┬──────────────┘
              ▼
┌────────────────────────────┐
│ 显式 block / allow override │  block 优先于 allow
└─────────────┬──────────────┘
              ▼
┌────────────────────────────┐
│ Heredoc / Inline Trigger    │  无触发：进入普通快路径
│ 提取 → AST/回退模式扫描      │  有触发：深入嵌套脚本
└─────────────┬──────────────┘
              ▼
┌────────────────────────────┐
│ Pack-aware Quick Reject     │  关键字不相关则快速允许
└─────────────┬──────────────┘
              ▼
┌────────────────────────────┐
│ 上下文遮罩 + 命令归一化      │  降低文本参数误报与路径绕过
└─────────────┬──────────────┘
              ▼
┌────────────────────────────┐
│ Safe Patterns → Deny Rules  │  线性 regex / 有界回溯 regex
└─────────────┬──────────────┘
              ▼
       Allow / Warn / Deny
              │
              ▼
协议专用 JSON(stdout) + 人类提示(stderr) + 可选审计记录

三层检测为何合理

层级	主要技术	目标	设计取舍
L1 触发层	RegexSet、memchr、quote-aware scanner	高召回、极低延迟	可接受少量假阳性，因为只触发下一层
L2 提取层	有界扫描、解码、嵌套 Shell 处理	找到真正会执行的脚本主体	对输入大小、递归与时间设上限
L3 语义层	ast-grep + tree-sitter + fallback patterns	识别 shutil.rmtree、fs.rmSync 等结构	更准确但更昂贵，仅对可疑输入启用

这是一种典型的安全检测漏斗：让便宜阶段负责排除绝大多数正常请求，把计算预算集中到少量可疑输入。相比"所有命令都做完整 AST"，它更适合每次 Shell 调用必经的 Hook 场景。

双正则引擎的工程价值

Rust regex 保证线性时间，但不支持 lookahead/lookbehind；fancy_regex 功能更强，却存在回溯开销。dcg 通过语法特征自动选择引擎：普通模式走线性引擎，高级模式才走回溯引擎，并把最大回溯步数压到 100,000。这样既保留复杂规则表达力，又降低正则拒绝服务和尾延迟风险。

代码规模与测试信号

基于 2026-07-13 主分支 10552f4 的静态统计：

指标	数值	解读
Rust 文件	265	包含 src、tests、bench/fuzz 等
Rust 总行数	186,011	已不是简单 Hook 脚本，而是完整安全工具链
src Rust 行数	150,241	规则包、Hook 协议、扫描、输出、审计占比高
tests 目录	82 个 Rust 文件 / 33,200 行	有大量 bypass、回归、协议与 E2E 用例
#[test]/#[tokio::test] 静态计数	4,203	规则密集型项目对回归覆盖投入很高
Git 提交	1,761	项目约半年内迭代非常频繁

这些是源码静态计数，不等同于本文实际执行了 4,203 个测试或验证了覆盖率徽章；但它们足以说明项目的技术深度远高于"几个正则加一个 Hook"。

安全边界与关键风险

1. 默认 fail-open ：解析错误、超时或资源限制通常会允许命令继续，以避免阻断正常工作；高安全环境应评估 general.fail_closed = true。
2. 不是沙箱：dcg 依赖 Agent 调用 Hook。绕过 Hook 的执行接口、代理写入后再调用脚本、直接系统调用都不是完整隔离。
3. 协议覆盖可能有盲区 ：README 明确提示 Codex 的某些 unified_exec 路径可能尚未被 Hook 拦截。
4. 规则与 allowlist 都需要治理：过宽 allowlist 会掏空规则价值；过严规则会导致用户习惯性绕过。
5. 许可证不是标准 MIT：LICENSE 增加对 OpenAI、Anthropic 及关联方的排除与再分发限制，因此更准确的称呼是"源码可见/源码开放项目"，企业采用前应做法务审查。

📖 README 核心内容摘要

README 的核心主张可以压缩为五点：

1. 问题定义：AI Agent 偶发执行灾难性命令，传统事后恢复无法保护未提交工作或外部基础设施。
2. 前置拦截：dcg 作为 PreToolUse/BeforeTool Hook，在命令进入 Shell 前返回拒绝决策。
3. 高性能与低误报并重：关键字快筛、延迟编译、上下文识别、双正则引擎、heredoc/AST 深扫共同工作。
4. 跨工具统一策略：一套规则覆盖主流编码 Agent，并为各客户端输出其能正确执行的拒绝协议。
5. 可解释、可扩展、可审计：规则包、项目配置、Agent Profile、allow-once、scan/SARIF、explain 与历史记录形成完整运维闭环。

README 还特别强调两种设计哲学：一是默认 fail-open，宁可在分析异常时不中断工作流；二是"安全替代建议"，阻止危险命令后同时提示 stash、dry-run、限定路径等更安全做法。前者提升可用性但降低强制边界，后者则能减少用户直接关闭安全工具的冲动。

值得留意的版本信号是：最新正式 Release 为 v0.6.5，但 7 月 11 日主分支提交信息已经开始记录 v0.6.6 Hook 协议变化，说明下一个版本正在准备中；本文不把未正式发布内容当成稳定版本能力。

🚀 快速上手指南

1. 安装

README 的一键安装方式如下：

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" | bash -s -- --easy-mode

该脚本会检测平台、下载预编译二进制、校验 SHA256、配置已识别的 Agent Hook 并更新 PATH。更谨慎的生产环境建议先下载、审阅，再执行：

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" -o /tmp/install-dcg.sh
less /tmp/install-dcg.sh
bash /tmp/install-dcg.sh --easy-mode

也可从源码构建：

git clone https://github.com/Dicklesworthstone/destructive_command_guard.git
cd destructive_command_guard
cargo build --release
cp target/release/dcg ~/.local/bin/

2. 先用测试模式验证，不执行真实命令

# 应返回 block/deny，但不会执行 rm
 dcg test "rm -rf ./build"

# JSON 结果便于 CI 解析
 dcg test --format json "kubectl delete namespace prod" | jq .decision

# 查看完整决策链与替代建议
 dcg explain "git reset --hard HEAD~3"

上面命令前的空格只用于阅读排版；复制时可以去掉。dcg test 的退出码约定为：0 表示允许，1 表示阻止。

3. 启用与你的技术栈相关的规则包

# ~/.config/dcg/config.toml
[packs]
enabled = [
  "database.postgresql",
  "containers.docker",
  "kubernetes.kubectl",
  "infrastructure.terraform",
]

[general]
# 高安全环境可考虑；启用前务必测试误阻断与客户端协议
fail_closed = true

然后逐条验证常用命令：

dcg test --with-packs containers.docker,database.postgresql "docker system prune"
dcg test --with-packs containers.docker,database.postgresql "psql -c 'DROP TABLE users'"
dcg explain "docker system prune"

4. 上线前的最小验收清单

• 运行 dcg doctor，确认二进制、配置和 Hook 状态；
• 对"应阻止、应允许、应警告"三组命令执行 dcg test；
• 在真实 Agent 中触发一个无害但应被拦截的测试命令，确认客户端确实终止执行；
• 检查项目级 .dcg.toml 与用户级配置是否发生意外覆盖；
• 对 CI 使用 dcg scan --format sarif，对 Agent 实时执行保留 Hook；
• 定期审计 allowlist、临时例外和决策历史。

📊 增长速度与社区热度

核心指标

指标	快照值	评估
Trending 排名	#1 / 17	当日曝光度最高
Stars	3,372	对创建约 186 天的安全基础设施项目而言增长快
Forks	124	Fork/Star ≈ 3.68%，已有明确二次开发兴趣
Open Issues/PRs	10	待处理量不高，但不能单独代表维护质量
Watchers	10	主动订阅规模仍小，热度主要体现在 Star
Releases	29	半年内发布密度高
Tags	43	版本与迭代节点频繁
Commits	1,761	工程推进速度非常高
最新正式版	v0.6.5（2026-07-03）	距快照 10 天
最近推送	2026-07-11	快照前 2 天仍活跃

仓库创建于 2026-01-07。按快照 3,372 Stars 与约 186.1 天计算，生命周期基线约 18.1 Stars/天。这只能描述从创建至今的平均速度，不能代替真实的当日增量；预抓取数据没有保留"今日新增 Stars"，因此本文不根据 Trending 第 1 名反推或虚构单日增长。

发布节奏同样强：6 月 25 日一天连续发布 v0.6.1、v0.6.2、v0.6.3，6 月 27 日发布 v0.6.4，7 月 3 日发布 v0.6.5。7 月 11 日又集中修复 Codex/Copilot Hook 协议、Windows 安装与 AST 超时回退，说明当前热度和多 Agent 兼容扩张高度相关。

社区结构则存在明显集中度：GitHub contributors 接口当前只返回 2 名贡献者，主要作者 1,752 次贡献，Dependabot 8 次；按接口数据计算，人工开发几乎全部集中在单一维护者。这带来快速决策与高迭代效率，也构成 bus factor 风险。采用方应锁定版本、保留回滚方案，并关注协议兼容改动。

当日完整 Trending 榜单

预抓取快照仅包含完整仓库顺序，没有保留其余项目的 Stars、语言和当日增量，因此这里只忠实展示排名，不补造缺失字段。

排名	仓库	排名	仓库
1	Dicklesworthstone/destructive_command_guard	10	k1tbyte/Wand-Enhancer
2	wonderwhy-er/DesktopCommanderMCP	11	pingdotgg/t3code
3	HKUDS/Vibe-Trading	12	virattt/ai-hedge-fund
4	PrefectHQ/prefect	13	chen08209/FlClash
5	Shubhamsaboo/awesome-llm-apps	14	davila7/claude-code-templates
6	anthropics/claude-cookbooks	15	par274/sharpemu
7	home-assistant/core	16	malisper/pgrust
8	Crosstalk-Solutions/project-nomad	17	Nutlope/hallmark
9	ColeMurray/background-agents

🎯 适用场景

场景	推荐度	原因与建议
个人使用 Claude/Codex/Cursor 编程	高	低成本保护未提交代码；先验证 Hook 是否真正生效
团队共享 Agent 开发环境	高	可用系统/用户/项目多层配置统一规则，并记录决策历史
生产数据库与云平台运维	中高	规则覆盖广，但必须叠加最小权限、审批、备份与云侧策略
CI 中扫描危险命令片段	高	scan 与 SARIF 适合代码审查和安全门禁
需要绝对隔离的高风险执行	低（单独使用）	Hook 不是容器、VM、seccomp 或 IAM 边界，必须配合沙箱
OpenAI/Anthropic 及其关联方内部采用	法务先行	LICENSE 明确设置限制，不可按标准 MIT 处理

💡 总结

dcg 把一个看似简单的"危险命令黑名单"做成了完整的 Agent 命令安全层：协议适配解决接入问题，快速拒绝与双正则引擎解决延迟问题，heredoc/AST 深扫解决绕过问题，规则包与配置层级解决扩展问题，explain/scan/历史记录解决运营问题。3.3K Stars、半年 29 个 Release 和 1,761 次提交，说明"AI Agent 执行安全"正在从边缘需求变成独立工具类别。

它最值得借鉴的不是某条正则，而是安全检测漏斗和工程边界意识：便宜规则覆盖大多数请求，昂贵语义分析只处理可疑输入；机器协议与人类提示分流；出现异常时明确选择 fail-open 或 fail-closed。与此同时，用户必须正视 Hook 盲区、单维护者集中度与非标准许可证。正确用法是把 dcg 放在 Shell 前，再把最小权限、版本控制、备份、容器隔离和人工审批放在它后面。