Tutorial 29: Analisi Approfondita della Sicurezza

Tutorial 29: Analisi Approfondita della Sicurezza

Bentornati, domatori di agenti! Oggi indossiamo il casco da cantiere e facciamo un’analisi approfondita del modello di sicurezza di Hermes Agent. Se vi siete mai chiesti cosa succede dietro le quinte per mantenere al sicuro le vostre sessioni, questo tutorial fa per voi.

Il Quadro Generale: Otto Livelli di Difesa

Hermes non si affida a un’unica serratura sulla porta. Utilizza invece un approccio difesa-in-profondità con otto livelli di sicurezza distinti. Pensatelo come un castello: anche se qualcuno supera il fossato, deve comunque affrontare le mura, i cancelli e le guardie all’interno.

Ecco la formazione:

1. Autorizzazione utente — chi può parlare con l’agente
2. Approvazione comandi pericolosi — controlli umani per azioni distruttive
3. Sicurezza scrittura file — liste nere e sandbox per le operazioni sui file
4. Isolamento container — sandboxing Docker/Singularity/Modal
5. Filtro credenziali MCP — tenere i segreti lontani dai sottoprocessi
6. Scansione file di contesto — rilevamento di prompt injection nei file di progetto
7. Isolamento tra sessioni — le sessioni non possono sbirciare i dati delle altre
8. Sanitizzazione input — blocco di shell injection tramite parametri della directory di lavoro

Ogni livello conta, ma oggi ci concentriamo su quello con cui interagirete di più: l’approvazione dei comandi pericolosi.

Come Funziona l’Approvazione dei Comandi Pericolosi

Prima che Hermes esegua qualsiasi comando, lo verifica rispetto a una lista curata di pattern pericolosi. Se c’è una corrispondenza, siete voi a decidere cosa succede dopo.

Controllate questo comportamento tramite la sezione approvals in ~/.hermes/config.yaml:

approvals:
  mode: smart                     # smart | manual | off
  timeout: 300                    # secondi di attesa per la risposta dell'utente
  cron_mode: deny                 # deny | approve
  single_query_mode: deny         # deny | approve
  mcp_reload_confirm: true        # conferma prima di ricaricare gli strumenti MCP
  destructive_slash_confirm: true # conferma prima di /clear, /new, ecc.

Tre Modalità di Approvazione

La chiave mode vi offre tre scelte:

Modalità	Comportamento
smart (predefinita)	Usa un LLM ausiliario per valutare il rischio. I comandi a basso rischio (come python -c "print('hello')") vengono auto-approvati. Quelli genuinamente pericolosi vengono auto-negati. I casi incerti vengono inoltrati a una richiesta manuale.
manual	Chiede sempre l’approvazione per i comandi pericolosi. Nessuna eccezione.
off	Disabilita tutti i controlli di approvazione. Equivalente a eseguire con --yolo.

⚠️ Attenzione: Impostare approvals.mode: off disabilita tutte le richieste di sicurezza. Fatelo solo in ambienti fidati come pipeline CI/CD o container usa-e-getta.

Modalità YOLO: Il Grande Pulsante Rosso

La modalità YOLO bypassa tutte le richieste di approvazione dei comandi pericolosi per la sessione corrente. Potete attivarla in tre modi:

1. Flag CLI: hermes --yolo o hermes chat --yolo
2. Comando slash: Digitare /yolo durante una sessione
3. Variabile d’ambiente: Impostare HERMES_YOLO_MODE=1

Il comando /yolo è un interruttore — ogni utilizzo lo attiva o disattiva:

> /yolo
  ⚡ Modalità YOLO ATTIVA — tutti i comandi auto-approvati. Usare con cautela.

> /yolo
  ⚠ Modalità YOLO DISATTIVATA — i comandi pericolosi richiederanno approvazione.

Quando YOLO è attivo, Hermes fa in modo che non possiate dimenticarlo. Vedrete un banner rosso all’avvio della sessione e un frammento ⚠ YOLO nella barra di stato, aggiornato in tempo reale mentre attivate/disattivate.

⚠️ Pericolo: La modalità YOLO disabilita tutti i controlli di sicurezza dei comandi pericolosi — eccetto la blocklist rigida. Usatela solo quando vi fidate completamente dei comandi generati (es. script di automazione ben testati in ambienti usa-e-getta).

Novità di Questa Versione: Chiavi di Configurazione più Intelligenti

Due nuove chiavi di configurazione meritano attenzione speciale:

mcp_reload_confirm (predefinita: true) — Quando è true, /reload-mcp chiede conferma prima di ricostruire il set di strumenti MCP. Perché? Perché la ricostruzione invalida la cache del prompt del provider, il che significa che il messaggio successivo reinvia i token di input completi. È un costo che potreste voler approvare prima.

destructive_slash_confirm (predefinita: true) — Quando è true, i comandi di sessione distruttivi (/clear, /new, /reset, /undo) richiedono conferma prima di scartare lo stato della conversazione. Viene visualizzata una finestra di dialogo a tre opzioni: Approva una volta / Approva sempre / Annulla. Su Telegram, Discord e Slack, questo passa attraverso i pulsanti nativi sì/no. Altrove, ricade sul testo.

Anche la TUI rispetta questa impostazione per i suoi modali /clear, /new e /reset. E se state automatizzando le cose, HERMES_TUI_NO_CONFIRM=1 salta forzatamente quel modale.

Sessioni Headless: Cron e Single-Query

Cosa succede quando un job cron o una sessione monouso hermes chat -q incontra un comando pericoloso? Non c’è nessun umano in attesa di rispondere a una richiesta.

È qui che entrano in gioco cron_mode e single_query_mode:

• deny (predefinita) — Blocca il comando. L’agente deve trovare un’altra strada.
• approve — Auto-approva tutto in quel contesto.

Entrambe sono impostate su deny di default per una buona ragione: meglio prevenire che curare quando nessuno sta guardando.

Conclusioni

Il modello di sicurezza di Hermes Agent mira a darvi controllo senza ostacolarvi. La modalità di approvazione intelligente gestisce automaticamente le cose noiose, mentre la modalità manuale vi offre supervisione completa quando ne avete bisogno. E se siete in un ambiente fidato, la modalità YOLO vi permette di muovervi velocemente.

Ricordate solo: da grandi poteri derivano grandi responsabilità. Usate YOLO con saggezza!

La prossima volta esploreremo come personalizzare il sistema di approvazione per il vostro flusso di lavoro specifico. Fino ad allora, restate al sicuro!