Sistema
Il codice si ripara mentre dormi.
Triagia incident, scrive patch, apre PR. Audit firmato Ed25519, threat model 10/10 mitigato, evidence pack SOC2 / ISO 27001 / NIS2 / GDPR generato in un click. Reliability AI per chi non può permettersi compromessi sulla riservatezza del codice.
I
Reliability come misura, non narrazione
Hermes definisce la reliability come la velocità con cui il sistema reagisce a un errore — non come l'assenza di errori. Lo dichiara nel nome: la derivata parziale di H rispetto al tempo è il KPI che porti in board. Tutti gli altri numeri sono conseguenza di quello.
II
Sette stadi, uno solo tocca un umano
Il motore segue una pipeline a sette stadi: StackDetector, Planner, Applier, BaselineCollector, Triager, Patcher, Validator. Solo l'ultimo — quando la policy boccia il merge automatico — chiama una review umana via step-up Face ID. Tutto il resto gira ventiquattro ore su ventiquattro, sentinella attiva, latency mediana sotto un minuto.
III
Threat model 10/10 mitigato
L'audit di sicurezza copre dieci vettori: prompt injection, branch escape, PR XSS, secret leak, webhook spoofing, rate-limit bypass, auth replay, trigger fingerprint replay, audit log tampering, model output exfiltration. Ogni mitigazione è tracciata a versione di rilascio, file sorgente, copertura test. PDF firmato disponibile a chiunque ne faccia richiesta.
IV
Audit append-only, evidence pack in un click
L'audit log gira su PostgreSQL con REVOKE UPDATE, DELETE FROM PUBLIC — solo INSERT e SELECT. Ogni evento firmato Ed25519. Il CISO clicca "Genera evidence pack" e ottiene un dossier conforme a SOC2 Type II, ISO 27001 A.12.6, NIS2 art.21 (D.Lgs 138/2024) e GDPR art.32. Un motore, quattro framework, zero opacità.
V
Keyless per progettazione
Hermes non chiede mai un personal-access-token. Ogni repository ha la sua deploy key Ed25519, pubblica su GitHub, privata cifrata AES-256-GCM at-rest. La superficie di leak è zero per design. Revoca singola per repo, rotation programmabile, niente OAuth scope troppo larghi sull'organizzazione.
Capability
01
Trigger fingerprint deduplicato
Ogni incident ha una signature stabile: fingerprint SHA-256 dei sintomi rilevanti. Niente lavoro duplicato, niente patch infinite sullo stesso errore intermittente.
02
Triager AI con trust score
Classifica ogni trigger in pochi secondi: noise, actionable, transient. Decisione patch sopra soglia 0.55 di trust, escalation umana sotto. Reasoning hashato e firmato.
03
Patcher generativo · max 3 tentativi
Il modello configurato (sonnet-4.5 di default, haiku-4.5 per cost-tier) propone fino a tre patch. Ogni tentativo è auditato. Quattro = escalation obbligatoria.
04
Validator sandbox
Esegue suite di test in container effimero, misura coverage delta e regression, blocca i merge che violano la regola no-regression. Verdetto in pochi secondi.
05
Policy engine YAML
Regole leggibili e versionate: cost cap, branch sanitizzato, no-regression, secret leak prevention. Ogni cambio è una riga firmata nel log.
06
Step-up Face ID review
Quando la policy boccia il merge automatico, l'operatore riceve push critical e fa step-up biometrico WebAuthn. TTL sessantasei secondi, audit firmato sull'identità.
07
Multi-tenant nativo
Tenant slug, policy per tenant, billing per tenant, audit isolato. System integrator possono orchestrare più clienti finali da un'unica console.
08
Console web e PWA mobile
Sei viste essenziali sul web (Workflows, Audit, Baseline, Threat, Discovery, Settings). Push critical su iPhone per le review escalated alle tre di notte.
Stack tecnologico
Motore TypeScript, oltre seicento test verdi, container effimero Docker per ogni sandbox, Postgres append-only per l'audit, WebAuthn per le autorizzazioni umane. Modelli LLM scelti per task — niente lock-in.
- hermes-core (TypeScript)Orchestrazione pipeline 7 stadi
- Next.js 16 · App RouterConsole multi-tenant web
- PostgreSQL 16 · append-onlyAudit log con REVOKE UPDATE/DELETE
- Ed25519Firma crittografica di ogni evento
- AES-256-GCM · KMS rotatingCifratura deploy keys at-rest
- WebAuthn passkeyAuth + step-up review Face ID/Touch ID
- Claude Sonnet 4.5 · Haiku 4.5Modelli LLM Triager + Patcher
- Docker · sandbox effimeraValidator runtime isolato
- GitHub Actions / Sentry / OTelTrigger sources standard
- policy_engine.yamlRegole tenant versionate Git-ops
- SSE · keepalive 20sStream workflow live in Console
- @oasi/core-aiLibreria condivisa con Atena e Avatar
Roadmap di delivery
Quattro fasi indipendenti. Il cliente vede valore prima di approvare la successiva. La fase Sentinella entra in funzione solo dopo che Hermes ha imparato i pattern del tenant — niente scorciatoie.
01 · 1 settimana
Discovery
StackDetector legge il repository — niente LLM, niente scrittura. Output: StackReport con framework rilevati, telemetria presente, copertura test, warning. Statement of Work firmato.
02 · 2-3 settimane
Onboarding telemetria
Planner pianifica le azioni di onboarding (Sentry, OpenTelemetry, hook CI). Applier apre la PR di onboarding sul repository. Da qui in poi Hermes vede gli incident.
03 · 4-8 settimane
Baseline
BaselineCollector osserva il rumore del sistema. Cluster classification: noise vs actionable vs transient. Recommended thresholds calcolati sui dati reali del tenant.
04 · Continua
Sentinella attiva
Triager + Patcher + Validator + PolicyEngine in produzione ventiquattro ore su ventiquattro. Audit firmato, evidence pack trimestrale, Quarterly Board Report PDF generato automatico.