Skip to main content

​
title: “Harness per agent” description: “Cattura sessioni e applica policy su tutti i 12 harness per agent supportati.” icon: “plug-zap”

Un harness è ciò in cui l’agent effettivamente viene eseguito. Failproof AI supporta dodici di loro, 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 per assistant (2) — Hermes (Slack, Telegram, cron), OpenClaw (assistant auto-ospitato)
Le stesse policy e la stessa cronologia delle sessioni si applicano indipendentemente da quale harness esegue l’agent. Un livello adattatore 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 qualsiasi policy venga eseguita. Un agent che viene eseguito in nessuno dei dodici viene instrumentato direttamente con Python SDK. Questo è un contratto diverso, e vale la pena affermarlo chiaramente: l’SDK fornisce tracciamento, sessioni, valutazioni e audit — non applica policy di per sé. Bloccare un’azione non sicura prima che venga eseguita richiede un hook di applicazione al confine dello strumento 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 le policy vengano eseguite. Una policy può agire solo su eventi esposti dall’harness; testa il comportamento end-of-turn e delle istruzioni sull’harness e la versione esatti che distribuisci.

​
Capacità di applicazione

“Block” significa che il verdetto restituito dall’adattatore attuale viene utilizzato dall’harness nominato. Il blocco post-tool può sostituire il risultato mostrato al modello ma non può annullare un effetto collaterale dello strumento che è già accaduto. Le capacità sono sensibili alla versione. Ritesta dopo l’aggiornamento di un CLI di agent, specialmente quando una policy si affida al comportamento di prompt, stop, permesso o post-tool piuttosto che al comune gate pre-tool.

​
Installa gli hook di cattura e policy

  1. Apri Administration → Keys e crea una chiave con events:add e policies:pull, denominata per la macchina o l’ambiente.
  2. Sulla macchina di destinazione, connetti la CLI locale con la chiave visualizzata e installa gli hook dell’harness.
  3. Avvia una nuova sessione di agent, quindi conferma i suoi hook e gli eventi di sessione in Observe → Events.
  4. Apri Observe → policy per la stessa finestra temporale e conferma che una decisione di policy sia attribuita alla macchina.
La connessione inizia con una chiave di macchina. Conferma che includa sia le autorizzazioni di acquisizione che di consegna delle policy prima di copiare il suo segreto.Il nuovo drawer della chiave API utilizzato per concedere le autorizzazioni di acquisizione degli eventi e consegna delle policy.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 policy siano attribuite alla stessa macchina. Questo conferma che l’harness sta segnalando l’attività di policy oltre agli eventi di traccia.La pagina Policy utilizzata per verificare le decisioni di policy da un harness appena connesso.

​
Aggiungi un percorso di sessione non predefinito

I percorsi aggiuntivi vengono registrati sulla macchina, non nel Cloud. Dopo averne aggiunto uno, apri Observe → Sessions, filtra per l’ambiente della macchina e conferma che le sessioni dal nuovo percorso compaiono. Apri una sessione e controlla l’agent, l’harness e i timestamp degli eventi prima di affidarti ad essa in un audit.L'elenco Sessions filtrato per l'ambiente che riceve dati dal percorso di cattura aggiuntivo.
Esegui una nuova sessione dopo l’installazione. Verifica sia il flusso di eventi live che una decisione di policy effettiva prima di espandere il rollout.