Skip to main content
Funzionalità beta. L’audit viene fornito in beta mentre raccogliamo i feedback iniziali. Il catalogo dei detector e il formato del report potrebbero cambiare prima della prossima versione stabile. Apri una segnalazione se qualcosa non ti sembra corretto.
L’audit è ora esposto come la pagina dashboard /audit, non come un sottocomando CLI. Aprilo dalla barra di navigazione del dashboard (tra Policies e Projects), oppure visita direttamente http://localhost:8020/audit quando esegui failproofai localmente.
failproofai          # apri il dashboard, quindi fai clic su "Audit"
Il dashboard scansiona i transcript CLI passati dell’agente su questa macchina (Claude Code, Codex, Copilot, Cursor, OpenCode, Pi, Gemini) e riporta quante volte l’agente ha fatto cose che failproofai è costruito per bloccare — controlli di variabili d’ambiente, force push, prefissi cd <cwd> ridondanti, loop di sleep-polling, ri-letture di file appena modificati, e altro ancora. Per ogni transcript, ogni evento di tool-use viene rieseguito attraverso le 39 politiche builtin e attraverso 8 detector audit-only che catturano pattern non ancora coperti dalle politiche di runtime. I conteggi sono aggregati per politica / detector su tutte le sessioni.

Cosa ottieni

La pagina /audit è composta da sei sezioni:
  1. Identity — il tuo agente classificato in uno degli 8 archetipi (optimist, cowboy, explorer, goldfish, paranoid architect, precision builder, hammer, ghost) in base al segnale ponderato su ogni transcript sottoposto a audit.
  2. Strengths — numeri reali derivati dalla scansione (clean-call %, “0 credential leaks”, ecc.) soggetti alle politiche sanitize rilevanti che effettivamente si attivano.
  3. Score — da 0 a 100 con bande S/A/B/C/D/F e un miglioramento previsto se ogni politica consigliata fosse abilitata.
  4. Findings — schede per-politica con cosa è successo, costo, prove catturate, e il comando failproofai policy add <slug> esatto per abilitare il builtin runtime che l’avrebbe catturato.
  5. Prescribed policies — lista di installazione aggregata con il comando failproofai policies --install singolo.
  6. Re-audit reminder — “ritorna meglio.” Imposta un reminder email di 7 giorni tramite l’api-server (richiede accesso; vedi failproofai auth).

Detector audit-only

Questi rilevano pattern di “comportamento stupido” non (ancora) applicati in tempo reale. Vengono eseguiti solo durante l’audit e non bloccano mai una tool call live.
DetectorCosa conta
redundant-cd-cwdComandi Bash che iniziano con cd <cwd> && … anche se i comandi vengono già eseguiti in cwd.
prefer-edit-over-read-catcat/head/tail/less/more su un singolo file sorgente — usa lo strumento Read.
prefer-edit-over-sed-awksed -i / awk … > file modifiche in-place — usa lo strumento Edit.
prefer-write-over-heredocHeredoc / multi-linea echo > file scrittura di file — usa lo strumento Write.
sleep-polling-loopLunghi sleep N (≥ 30s) o loop di polling while …; sleep …; done.
find-from-rootfind /, find /home, find /usr, ecc. — limita lo scope a cwd.
git-commit-no-verifygit commit … --no-verify / -n, saltando gli hook.
reread-after-editRead di un file appena modificato con Edit/Write nella stessa sessione.

Cache

  • Cache per-transcript in ~/.failproofai/cache/audit/<sha1>.json indicizzata da (mtime, size, engineVersion, detectorVersion) — si invalida automaticamente quando il transcript o il codice della politica/detector cambia. Ogni voce memorizza anche un timestamp cachedAt come metadati TTL (non parte della chiave di cache); le voci più vecchie di 7 giorni vengono rifiutate nella lettura in modo che i risultati di lunga durata non superino l’intento del detector in evoluzione.
  • Cache del risultato completo in ~/.failproofai/audit-dashboard.json (modalità 0600). Permette al dashboard di eseguire il rendering istantaneamente nella navigazione senza rieseguire. Viene anche rifiutato nella lettura dopo il TTL di 7 giorni/audit ricade quindi nello stato vuoto e richiede un’esecuzione aggiornata. Fai clic su [ re-audit now ] vicino al fondo del report per aggiornare — il re-audit invia noCache: true, quindi bypassa la cache per-transcript e scansiona di nuovo ogni transcript invece di restituire il risultato in cache; l’esecuzione fa lo streaming del progresso tramite una barra adesiva in alto e sostituisce il risultato sul posto al successo (nessun ricaricamento della pagina; un re-audit fallito mantiene il report precedente).

Note

  • Nessuna mutazione. L’audit viene rieseguito in modalità di sola lettura. warn-repeated-tool-calls viene saltato perché il suo sidecar per-sessione altrimenti verrebbe modificato.
  • Politiche workflow saltate. Le politiche require-*-before-stop si attivano solo su eventi Stop e execSync rispetto allo stato git live — non hanno un’interpretazione significativa di “cosa sarebbe successo nel 2025”, quindi non compaiono nei conteggi dell’audit.
  • Politiche personalizzate saltate. Gli hook personalizzati forniti dall’utente non vengono rieseguiti (potrebbero essere cambiati dalla sessione originale).