Destructive Command Guard、ルールベースのhooksでエージェントの危険なコマンドを阻止、1日でGitHub Starsが約500増加

AI coding agentがターミナルを直接操作できるようになったことで、リスクは「誤ったコードの生成」から、未コミットの内容の削除、Git履歴の書き換え、インフラストラクチャの破壊にまで広がっている。最近GitHubで急速に注目を集めているDestructive Command Guard（dcg）は、ツール呼び出しとshell実行の間にチェック機構を配置する。Claude Code、Codex CLI、Gemini CLI、Copilot CLI、Cursorなどの製品が提供するhooksを通じて、コマンドを事前に解析し、許可または拒否の結果を返す。

このプロジェクトはRustで実装されており、危険な再帰的削除、`git reset --hard`、ディスクのフォーマットなどの操作をデフォルトで阻止する。モジュール式のルールパックは、PostgreSQL、Redis、Docker、Kubernetes、Terraform、AWS、GCP、Azure、GitHub Actions、シークレット管理サービスにも対応している。また、heredocや`python -c`などの埋め込みスクリプトもスキャンし、実際に実行されるコマンドと、`grep`、ドキュメント、テストデータ内に文字列として現れるだけのものを区別しようとする。Codexに対しては、dcgがそのhookプロトコルに従って簡潔な構造化拒否メッセージを出力し、余分なフィールドによって防御機能自体が無効になる事態を防ぐ。

Git Observatoryはdcgを7月26日の異常成長プロジェクトとして取り上げ、1日で約497 Stars増加したと観測した。GitHubページには現在、約5,400 Starsと表示されている。これは採用状況を示すシグナルであり、安全性や有効性を証明するものではない。ルールベースのシステムは、エンコードされた処理、間接的な呼び出し、新しいツールの組み合わせで構成される破壊経路を見逃す可能性がある一方、正当な運用作業を誤って阻止することもある。また、`DCG_BYPASS=1`、ワンタイム許可コード、永続的なallowlistはいずれも判定を迂回できる。エンジニアリングチームはdcgを追加のブレーキとして位置付け、最小権限、ワークスペースの分離、イミュータブルバックアップ、人による承認を引き続き維持すべきだ。今後注目すべき点は、公開されたfalse positive率、敵対的テスト、そして各エージェントがhookによる拒否結果に実際どの程度従うかである。