Skip to main content
Un harness è l’ambiente in cui il tuo agente effettivamente viene eseguito. Failproof AI supporta dodici di essi, divisi in due categorie:
  • Coding CLI (10) — Claude Code, Codex, GitHub Copilot CLI, Cursor, OpenCode, Pi, Factory Droid, Devin CLI, Antigravity CLI, Goose
  • Chat e gateway assistenti (2) — Hermes (Slack, Telegram, cron), OpenClaw (assistente self-hosted)
Gli stessi criteri e la stessa cronologia delle sessioni si applicano indipendentemente da quale harness esegue l’agente. Un livello di adattamento mappa i nomi degli eventi nativi di ogni harness, i nomi degli strumenti e i campi di input degli strumenti su 29 eventi canonici prima che venga eseguito qualsiasi criterio. Un agente che viene eseguito in nessuno dei dodici viene strumentato direttamente con Python SDK. È un contratto diverso, e vale la pena dichiararlo chiaramente: l’SDK fornisce tracciamento, sessioni, valutazioni e audit — non applica criteri autonomamente. Il blocco di un’azione non sicura prima della sua esecuzione richiede un hook di enforcement al confine degli strumenti del tuo runtime; contattaci e lo mapperemo. Ogni integrazione normalizza i nomi degli eventi hook nativi, i nomi degli strumenti e i campi di input degli strumenti prima che vengono eseguiti i criteri. Un criterio può agire solo su eventi esposti dall’harness; testa il comportamento end-of-turn e le istruzioni sull’harness e sulla versione esatta che distribuisci.

​
Capacità di enforcement

“Block” significa che il verdetto restituito dall’adattatore corrente viene consumato dall’harness denominato. Il blocco post-tool può sostituire il risultato mostrato al modello ma non può annullare un effetto collaterale dello strumento che si è già verificato. Le capacità sono sensibili alla versione. Ripeti i test dopo l’aggiornamento di un agent CLI, soprattutto quando un criterio si basa su comportamento di prompt, stop, permission o post-tool anziché sul gate pre-tool comune.

​
Plugin nativo di Hermes

Hermes è integrato attraverso un plugin nativo profile-local anziché un comando shell. L’installazione copia il plugin in ogni profilo Hermes predefinito e denominato, lo abilita nel config.yaml di quel profilo e migra solo le voci FailproofAI del legacy shell-hook. Questo evita uno spawn di processo su ogni hook e permette a instruct() di raggiungere il modello attraverso il risultato di blocked-tool nativo di Hermes. La prima istruzione corrispondente blocca la chiamata in sospeso. La stessa richiesta API rimane bloccata; un’iterazione del modello successiva può riprovare. Un libro mastro persistente con ambito profilo e un limite per turno impediscono a un’istruzione consultiva di diventare un ciclo senza limiti. deny() rimane un blocco duro. Esegui failproofai config --status per rilevare un profilo disabilitato, incompleto, duplicato o non configurato di recente.

​
Installa hook di cattura e criteri

  1. Apri Administration → Keys e crea una chiave con events:add e policies:pull, denominata per la macchina o l’ambiente.
  2. Sulla macchina target, connetti la CLI locale con la chiave visualizzata e installa gli hook dell’harness.
  3. Avvia una nuova sessione agente, quindi conferma i suoi eventi hook e sessione sotto Observe → Events.
  4. Apri Observe → policy per la stessa finestra temporale e conferma che una decisione di criterio è attribuita alla macchina.
La connessione inizia con una chiave macchina. Conferma che includa sia le autorizzazioni di ingestione che di policy-delivery prima di copiare il suo segreto.Il cassetto della nuova chiave API utilizzato per concedere le autorizzazioni di event ingestion e policy delivery.Dopo l’installazione degli hook, il flusso Events dovrebbe mostrare nuovi eventi dalla macchina e dall’ambiente che hai connesso.Il flusso Events live utilizzato per confermare che un harness appena installato sta segnalando.Infine, verifica che le decisioni di criterio siano attribuite alla stessa macchina. Questo conferma che l’harness sta segnalando l’attività di criterio oltre agli eventi di tracciamento.La pagina Policy utilizzata per verificare le decisioni di criterio da un harness appena connesso.

​
Aggiungi un percorso sessione non predefinito

I percorsi aggiuntivi vengono registrati sulla macchina, non in Cloud. Dopo aver aggiunto uno, apri Observe → Sessions, filtra in base all’ambiente della macchina e conferma che le sessioni dal nuovo percorso compaiono. Apri una sessione e controlla l’agente, l’harness e i timestamp degli eventi prima di fare affidamento su di esso in un audit.L'elenco Sessions filtrato in base all'ambiente che riceve dati dal percorso di cattura aggiuntivo.
Esegui una nuova sessione dopo l’installazione. Verifica sia il flusso di eventi live che un’effettiva decisione di criterio prima di espandere il rollout.