Repo del giorno: Destructive Command Guard, il freno d'emergenza per gli agenti AI

🛡️ Cos'è dcg: un guardrail pre-esecuzione, non una sandbox

Destructive Command Guard è un binario Rust che si aggancia al meccanismo di hook degli agenti di coding: quando l'agente sta per lanciare un comando shell, dcg lo riceve prima dell'esecuzione, lo analizza e decide — permetti in silenzio, oppure blocca con un messaggio che spiega il perché e suggerisce la strada sicura. Il problema che risolve è concreto: i modelli ogni tanto eseguono comandi catastrofici come `git reset --hard`, `rm -rf ./src` o `DROP TABLE users`, distruggendo ore di lavoro non committato in pochi secondi.

Il progetto è nato a gennaio 2026 come script Python dell'autore, poi riscritto in Rust con Darin Gordon e cresciuto fino alla v0.6.8 attuale: oltre 1.700 commit, binari firmati (SHA256 obbligatorio, minisign, Sigstore) e una filosofia dichiarata — è un guardrail, non un confine di sicurezza totale. La distinzione conta e ci torno più avanti: un hook filtra le intenzioni, una sandbox limita il raggio del danno.

repo       Dicklesworthstone/destructive_command_guard
stelle     ~4.500 · fork 169 · linguaggio Rust · licenza custom
autori     Jeffrey Emanuel (concept + pack system) · Darin Gordon (port Rust)
cosa       hook pre-esecuzione: blocca i comandi distruttivi degli agenti
harness    Claude Code · Codex CLI · Gemini CLI · Copilot CLI · Cursor · altri
extra      50+ security pack opzionali · latenza sub-millisecondo

⚙️ Come funziona: tre livelli e un budget di 200 millisecondi

La parte che mi ha convinto a segnalarlo è l'ingegneria della latenza. Un guard che rallenta ogni comando verrebbe disinstallato in un pomeriggio, quindi dcg usa una pipeline a tre livelli: un primo screening con espressioni regolari compilate scarta in meno di 100 microsecondi tutto ciò che non contiene trigger sospetti — la stragrande maggioranza dei comandi. Solo ciò che resta passa all'estrazione del contenuto (heredoc, script inline, argomenti `-c`) e infine al matching strutturale su AST via tree-sitter, che capisce la differenza tra un `rm -rf` citato in un `grep` e uno che verrà eseguito davvero.

Sopra tutto c'è una regola di buon senso: un tetto assoluto di 200 millisecondi. Se l'analisi supera il budget, il comando passa comunque e viene loggato un warning. È la scelta fail-open dichiarata del progetto: un comando legittimo bloccato è più dannoso di un comando pericoloso sfuggito — chi preferisce l'opposto può attivare il fail-closed con una riga di configurazione.

🚀 Installazione: un comando, hook configurati per tutti gli agenti

L'installazione «easy mode» fa tutto da sola: rileva la piattaforma, scarica il binario giusto, verifica i checksum SHA256 e le firme, configura gli hook per tutti gli agenti supportati che trova sulla macchina e aggiorna il PATH. Su Claude Code registra un hook `PreToolUse` con matcher `Bash` in `settings.json` — lo stesso meccanismo che uso per i quality gate di fine sessione, qui applicato a monte di ogni comando. Su Codex CLI (0.125.0+) l'hook finisce in `hooks.json`, su Gemini CLI diventa un `BeforeTool` su `run_shell_command`, e Cursor, Copilot CLI e Grok hanno i loro percorsi documentati.

Dopo l'installazione conviene lanciare `dcg setup`, che aggiunge un controllo all'avvio della shell: se l'hook viene rimosso da `settings.json` — da un aggiornamento, o da un agente troppo intraprendente — te ne accorgi subito invece di scoprirlo al prossimo disastro.

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

# verifica: questo viene bloccato...
dcg test "git reset --hard"

# ...questo no (è testo, non esecuzione)
dcg test "grep 'rm -rf' README.md"

# capire una decisione, con i tempi di ogni fase
dcg explain --verbose "rm -rf /tmp/build"

🧰 I pack di sicurezza: da git a Stripe, attivi solo se servono

Di default dcg protegge l'essenziale: `core.git` e `core.filesystem` (sempre attivi, non disattivabili) più `system.disk` contro i disastri a livello di dischi e partizioni. Tutto il resto è opt-in tramite oltre 50 pack tematici: database (PostgreSQL, MySQL, MongoDB, Redis), Kubernetes, Docker, cloud (AWS, Azure, GCP), Terraform, e persino pack per servizi come Stripe, Cloudflare o SendGrid. La logica mi sembra quella giusta: ognuno attiva solo i guardrail per l'infrastruttura che i suoi agenti toccano davvero, senza pagare falsi positivi su tutto il resto.

La configurazione è un TOML a livelli — sistema, utente, progetto (`.dcg.toml` nella radice del repo) — con override per singolo progetto e persino profili per agente. E quando un blocco è legittimo ci sono le valvole di sfogo: `dcg allow-once` con codice a sei cifre per l'eccezione una tantum, allowlist permanenti con motivazione obbligatoria, e `DCG_BYPASS=1` per disattivare tutto su una singola invocazione.

# ~/.config/dcg/config.toml
[packs]
enabled = [
    "database.postgresql",    # blocca DROP TABLE, TRUNCATE
    "kubernetes.kubectl",     # blocca kubectl delete namespace
    "containers.docker",      # blocca docker system prune
]

# eccezioni per progetto, con motivazione
# dcg allowlist add core.git:reset-hard --reason "cleanup CI" --project

🏢 Perché è interessante, per sviluppatori e PMI

Per chi sviluppa con gli agenti, dcg toglie dal tavolo la categoria di errore peggiore: quella irreversibile. Il vibe coding funziona proprio perché si concede all'agente molta autonomia, e più autonomia significa più comandi eseguiti senza revisione umana; un filtro deterministico, veloce e trasparente su quella superficie è un investimento minuscolo — un comando di installazione — contro un rischio che chiunque abbia perso uno stash o un branch conosce bene. E il fatto che il blocco arrivi con una spiegazione aiuta anche l'agente stesso, che di solito ripiega da solo sull'alternativa sicura suggerita.

Per una PMI che sta adottando agenti AI nei processi di sviluppo, dcg è un tassello di governance concreto: una policy di sicurezza eseguibile, versionabile nel repo (`.dcg.toml`) e uguale per tutti — sviluppatori e agenti. È la stessa logica di cui ho scritto parlando di shadow AI e governance degli agenti: le regole servono a poco se vivono in un documento; qui diventano un controllo tecnico attivo su ogni workstation, con log delle decisioni e eccezioni motivate. Non sostituisce backup, permessi e review — le completa nel punto in cui gli agenti operano davvero.

⚠️ I limiti da conoscere prima di fidarsi

Il README è onesto sui confini, e li riporto perché è lì che si decide un'adozione seria. Primo: un hook non è una sandbox — un agente può scrivere uno script su disco ed eseguirlo per una via che l'hook non intercetta; il progetto stesso invita a trattarlo come guardrail, da affiancare a credenziali limitate, backup e branch protection. Secondo: il default fail-open significa che timeout ed errori di parsing lasciano passare il comando — è una scelta sensata per l'ergonomia, ma va conosciuta (e si può invertire). Terzo: la copertura varia per harness — su Aider si limita agli hook git, su Continue non c'è intercettazione.

Ultima nota: la licenza è custom, non una MIT o Apache standard. Per uso personale non cambia nulla di pratico, ma un'azienda che volesse adottarlo in modo strutturato dovrebbe leggerla prima — vale il principio che applico a ogni repo del giorno: trending è un segnale di scoperta, non una due diligence già fatta.

• Non è una sandbox: filtra i comandi in transito, non limita ciò che un processo già avviato può fare.
• Fail-open di default: oltre 200ms o su errore di analisi il comando passa; `DCG_FAIL_CLOSED=1` inverte il comportamento.
• Copertura diseguale: piena su Claude Code, Codex, Gemini e Cursor; parziale su Aider, assente su Continue.
• Licenza custom: da leggere prima di un'adozione aziendale strutturata.

✅ Da dove partire

Il percorso che suggerisco: installa in easy mode su una macchina di sviluppo, verifica con `dcg test` che i pattern fondamentali vengano bloccati, e lavora una settimana con i soli pack di default — nella mia esperienza i falsi positivi sul flusso quotidiano sono rari, e quando capitano `dcg explain` dice esattamente quale regola è scattata e perché. Poi attiva i pack della tua infrastruttura reale, uno alla volta, e committa il `.dcg.toml` di progetto così la protezione viaggia con il repo.

Nel quadro più ampio, dcg completa il trittico di cui scrivo da settimane: il metodo (Superpowers e i workflow strutturati) riduce gli errori di progettazione, i quality gate via hook controllano il risultato a fine sessione, e dcg presidia l'unico punto dove l'errore non è recuperabile: il comando distruttivo eseguito. Tre livelli diversi, stessa idea: dare autonomia agli agenti senza consegnare loro le chiavi di tutto.

Altri articoli del blog