Osservatorio sull'ecosistema Jev (parte 2): 30 progetti di guardrail per agenti, cosa hanno bloccato e cosa hanno lasciato passare

Nel post precedente abbiamo tracciato il quadro dei primi quattro giorni dell'ecosistema Jev. Questo post approfondisce il caso d'uso principale: la supervisione degli agenti. Entro 72 ore dal rilascio di Jev da parte di TypeSafe, la sola categoria «sicurezza/supervisione degli agenti» ha prodotto oltre 30 progetti. Al quarto giorno, la commoditizzazione aveva spinto gli addetti ai lavori a definirla un «mercato saturo», segno di una domanda reale. Questo articolo li divide in quattro forme, li mette a confronto attraverso casi di studio quantitativi e risponde a una domanda pratica: quale guardrail dovrebbe usare il tuo agente?

Anzitutto, le fonti: i dati sui progetti riportati di seguito sono dichiarati dagli autori (classificati A/B/C in base alla solidità delle prove), con latenza e costi misurati a livello di progetto. Il repository completo dei casi è disponibile su jev-radar, con fonti di prima mano per ogni voce.

Perché all'improvviso i guardrail funzionano

I guardrail per agenti non sono un'idea nuova: in passato fallivano per ragioni economiche. Far valutare a un LLM se una chiamata a un tool fosse pericolosa richiedeva diversi secondi e costava centesimi a inferenza. Inserirlo in ogni passo del loop di un agente portava dritto ai timeout. Il README di pi-warden presenta un nuovo bilancio: circa 1.000 token in input, circa 0,00004 $ e circa 0,3 secondi per controllo (dichiarato dall'autore). Per la prima volta è praticabile eseguire un controllo per ogni chiamata sottoposta al guardrail. Per questo i guardrail sono diventati il caso d'uso principale: latenza e costi unitari hanno trasformato la supervisione passo per passo da lusso a impostazione predefinita.

Quattro architetture di guardrail

Classificando gli oltre 30 progetti in base a ciò che valutano e al fatto che blocchino o meno, emergono quattro approcci distinti:

• Supervisione in modalità shadow: valuta il rispetto delle regole, il rumore, gli stalli o le dichiarazioni di completamento senza test. Non blocca: inserisce i giudizi nel contesto perché l'agente si corregga. Esempi: pi-warden, Foreman.
• Limiti rigidi con giudizio sulle zone grigie: valuta le chiamate fuori da una whitelist. Blocca, ma le regole rigide hanno la precedenza e Jev valuta solo la zona grigia. Esempi: jevgate, rh-guard.
• Gate di approvazione: fa da ultimo controllo prima dei passi costosi o rischiosi, bloccandoli per una revisione umana o declassandoli. Esempi: toolgate, noulgate, hermes-approvals.
• Riconciliazione delle dichiarazioni: confronta ciò che l'agente dichiara con ciò che è successo davvero e fa emergere le discrepanze dopo l'esecuzione, senza bloccare in tempo reale. Esempio: clear-head.

La supervisione in modalità shadow ha la base di prove più solida. pi-warden usa Jev per valutare le operazioni di scrittura rispetto ai file di regole del progetto e riporta nel contesto dell'agente i riferimenti alle regole violate. Senza interrompere l'utente, l'agente riceve una correzione. Due metriche dichiarate dall'autore meritano attenzione: su 150 esecuzioni headless appaiate, le regole sono state violate 6 volte con i guardrail disattivati e 0 volte con i guardrail attivi. In 321 sessioni reali e 17.160 chiamate del guardrail, l'esecuzione è stata messa in pausa solo 42 volte (5 sbloccate dal messaggio successivo dell'autore, 37 per le quali il blocco è stato mantenuto). Un guardrail efficace interviene di rado invece di bloccare tutto. Un altro dettaglio: quando una funzionalità di rilevamento delle deviazioni dal task ha reso meno del previsto nella valutazione dell'autore, è stata declassata a semplice suggerimento invece di essere eliminata.

Vale la pena adottare il design che combina limiti rigidi e giudizio sulle zone grigie. rh-guard prende di mira il reward hacking negli agenti di coding, come manomettere i valutatori, ispezionare test nascosti o manipolare i processi di valutazione. La sua scelta architetturale è documentata nel README: prima le regole rigide strutturate bloccano le chiamate non consentite, poi Jev valuta la zona grigia rimanente. Nelle demo registrate, le modifiche alle asserzioni con sed vengono bloccate, mentre i comandi echo innocui passano. I progettisti della stessa famiglia formulano il principio in modo ancora più diretto: jevgate funziona come una whitelist che definisce cosa può essere eseguito, Jev valuta ciò che resta fuori dall'elenco e i giudizi soft non impongono mai un veto unilaterale (fail-open). Le probabilità calibrate possono sbagliare, quindi non possono fare da unico gate. Questa famiglia ha persino sviluppato un livello di decisione progettuale (Augustus) che stabilisce quando non usare Jev.

I gate di approvazione mettono un checkpoint prima dei passi costosi. hermes-jev-approvals offre uno dei rari confronti quantitativi: dichiara una velocità 8,7 volte superiore e costi 4 volte inferiori rispetto alla soluzione originale. toolgate parte di default in modalità shadow: si limita a osservare e registrare finché non si è costruita la fiducia necessaria, e solo allora attiva il gate.

La riconciliazione delle dichiarazioni è l'approccio più recente e leggero: quando l'agente segnala di aver finito, clear-head confronta ciò che l'agente dichiara di aver letto con le letture effettive dal disco, puntando proprio alle affermazioni non riscontrate.

Un controesempio

Il benchmark WebMCP (nekuda-ai, open source e riproducibile) offre un utile banco di prova per i progetti di guardrail: Jev, collegato così com'è a un harness per browser, ha risolto 25 task web su 49, mentre aggiungendo un livello WebMCP che condensa le sequenze di clic in singole chiamate ai tool si è arrivati a 49/49. Questa conclusione vale anche per la progettazione dei guardrail: scegliere il pulsante giusto tra quelli ammessi non equivale a scegliere il passo successivo giusto. Il valore del livello di giudizio dipende dalla rappresentazione dello stato che riceve. Lo stesso vale per i guardrail: domande ristrette e stati accurati producono giudizi affidabili.

Se stai implementando un guardrail

Cinque principi di progettazione ricavati da oltre 30 progetti, in ordine di importanza:

1. Prima le regole rigide, a Jev le zone grigie: ciò che si può esprimere con whitelist e regole strutturate non deve dipendere da un giudizio probabilistico. Jev si occupa delle aree non coperte dalle regole.
2. Fail-open, con giudizi soft che non impongono mai un veto unilaterale: le probabilità calibrate possono sbagliare, e in caso di errore si deve chiedere una verifica umana invece di fermare i flussi di lavoro.
3. Modalità shadow prima dell'enforcement: all'inizio registra senza intervenire e valuta il tasso di falsi positivi prima di aprire i gate (come fa toolgate di default).
4. Domande ristrette: valuta domande ristrette ed enumerabili, come l'irreversibilità o la coerenza con l'intento, invece di giudizi soggettivi sulla qualità (la lezione di Supercov si applica direttamente ai guardrail).
5. Declassa le funzionalità che rendono poco invece di eliminarle: mantenerle con permessi ridotti conserva più segnale che rimuoverle del tutto (come fa pi-warden con il rilevamento delle deviazioni dal task).

Le opportunità oltre il mercato saturo

Con oltre 10 progetti che implementano la stessa forma, le strade per differenziarsi sono chiare: puntare su host specifici (jury.nvim per Neovim, jev.el per Emacs, git-judge-jev per GitHub Actions, plugin per OpenCode), esplorare nuovi tipi di giudizio (l'integrità della valutazione di rh-guard, la riconciliazione delle dichiarazioni di clear-head) oppure concentrarsi sui livelli di progettazione (Augustus, su quando non usare Jev). Per chi entra ora: gli spazi per i guardrail generici sono esauriti, ma ogni nuovo host e ogni nuovo tipo di violazione dei limiti crea un nuovo punto in cui inserire un gate.

Chiudiamo qui il discorso sui livelli di giudizio. Nel prossimo articolo guardiamo l'altro lato di questo ecosistema: i campioni di fallimento. Se devi alimentare un livello di giudizio con dati, la raccolta affidabile di recensioni, sentiment e prezzi è la competenza centrale di EveryInfra; parti dalla guida all'API unificata per i dati.