Remediation automatica alle 3 di notte: chi autorizza le mutazioni sul tuo stack?

Un agente che ripara la produzione da solo, ma solo dopo un'approvazione firmata

Un progetto sperimentale documentato su dev.to, "Building TrueSRE: Autonomous Multi-Agent Incident Remediation", racconta un sistema che diagnostica e prova a risolvere un guasto di produzione in pochi secondi. Il dettaglio interessante non è la velocità: è che ogni azione capace di modificare la produzione si ferma a un gate umano, e viene eseguita solo con un token crittografico monouso. Le richieste senza firma vengono respinte come MUTATION_BLOCKED.

Tradotto: il progetto ha deciso, per design, che nessuna operazione distruttiva parte senza qualcuno che la autorizza in modo verificabile. È una scelta banale a parole e rarissima nella pratica.

Se hai costruito e messo online un'app con uno strumento AI, questa storia ti riguarda più di quanto pensi. Perché il tuo backend, quasi certamente, non ha nessun gate del genere.

Cosa significa se il tuo codice l'ha scritto Lovable

Quando generi un'applicazione con Lovable, ottieni in fretta un frontend collegato a un backend con database, endpoint e permessi. Funziona subito, e questo è il punto debole: la parte che decide chi può fare cosa viene generata insieme al resto, senza che nessuno la guardi con attenzione.

Il problema tipico non è la funzionalità visibile. È l'autorizzazione. Un endpoint che modifica o cancella dati spesso viene esposto senza controllare davvero l'identità e i permessi di chi chiama. Nessun MUTATION_BLOCKED, nessuna firma, nessun gate: se conosci l'URL e sei loggato in qualche modo, la mutazione parte.

Nella pratica questo produce vulnerabilità come l'IDOR: cambi un identificativo nella richiesta e leggi o modifichi i dati di un altro utente. Oppure trovi rotte amministrative raggiungibili da un account normale. Lovable non ha fatto niente di malevolo: ha generato codice plausibile. Ma "plausibile" e "autorizzato correttamente" sono due cose diverse, e la differenza la scopri solo se qualcuno la verifica.

Perché ora ti serve un audit

Il progetto TrueSRE si è dato una regola severa proprio perché sa che un'azione sbagliata in produzione costa. Tu, sul tuo repository, hai bisogno della stessa domanda posta prima che sia un attaccante a rispondere: quali operazioni possono modificare i dati, e chi è davvero autorizzato a lanciarle?

Un audit serve a ottenere un verdetto su questo. Non a rassicurarti, ma a dirti dove il modello di autorizzazione è debole o assente. Con VibeInspect carichi lo ZIP del repository, degli specialisti AI lo analizzano e ricevi un PDF con il verdetto. Nessun server, nessuna installazione: il codice sorgente viene cancellato al termine dell'analisi.

È importante essere chiari su cosa non è. VibeInspect non è un pentest, non è un linter e non corregge il codice al posto tuo. Non promette sicurezza assoluta. Ti dà un giudizio strutturato sullo stato reale del repository, così smetti di navigare a intuito.

Se il tuo problema è "ci sono endpoint che modificano dati e non so se sono protetti", non ti serve un'impressione generica: ti servono file, riga ed evidenze. Il piano Diagnostic a 499€ ti mostra esattamente dove il controllo di autorizzazione manca o è incoerente, con le prove a supporto, senza revisione umana e senza correzioni automatiche. Se invece vuoi solo capire in che stato è complessivamente il progetto, lo Snapshot a 49€ ti dà uno score e un verdetto generale, senza indicazioni di file o riga.

Cosa un linter non vede

Qui sta l'equivoco più comune. Molti pensano che, siccome il progetto "passa" i controlli automatici e non ci sono errori evidenti, allora è a posto. Non è così.

Un linter analizza la forma del codice: stile, variabili non usate, pattern sintattici, tipi. È utile, ma lavora sulla superficie. Non capisce la logica di business e non sa nulla del contesto delle autorizzazioni. Un endpoint che cancella record di qualsiasi utente può essere sintatticamente perfetto: nessuna virgola fuori posto, nessun warning. Il linter è contento, l'IDOR resta.

Le cose che un linter non può vedere sono proprio quelle che contano quando qualcuno prova ad abusare del tuo backend:

• se un endpoint di modifica verifica davvero che l'utente sia il proprietario della risorsa;
• se esistono rotte sensibili raggiungibili senza i permessi giusti;
• se una mutazione critica parte senza alcun controllo di ruolo;
• se il confine tra utente normale e amministratore è reale o solo nascosto nell'interfaccia.

Il progetto TrueSRE ha inserito un gate esplicito e una firma proprio perché sapeva che nessun controllo automatico di sintassi lo avrebbe protetto da un'azione non autorizzata. La stessa logica vale per te: la sicurezza dell'autorizzazione è una questione di significato, non di forma, e va giudicata a quel livello.

Cosa fare questa settimana

Non serve riscrivere tutto. Servono pochi passi concreti, subito.

1. Elenca gli endpoint che modificano dati. Ogni rotta che crea, aggiorna o cancella. Sono quelle dove un errore di autorizzazione fa più danni.
2. Prova un IDOR a mano. Prendi una richiesta legittima, cambia l'identificativo con quello di un'altra risorsa e guarda se passa. Se passa, hai un problema serio.
3. Verifica le rotte amministrative. Prova a raggiungerle da un account normale. Se il controllo è solo nel frontend, non è un controllo.
4. Chiediti dove manca un gate. Esiste un'operazione distruttiva che parte senza nessuna verifica di ruolo? Segnala e mettila in cima.
5. Fai girare un audit. Carica lo ZIP su VibeInspect e ottieni un verdetto su file e riga, così sai esattamente cosa correggere prima.

Hai costruito veloce con l'AI: è un vantaggio, non una colpa. Ma velocità senza verdetto significa non sapere in che stato è davvero il tuo backend. Un'app che modifica dati senza un modello di autorizzazione solido è un incidente che aspetta il momento giusto.

Questa settimana chiudi il cerchio: individua gli endpoint di mutazione, prova a bucarli tu prima degli altri e fai analizzare il repository con VibeInspect nel piano Diagnostic per avere le evidenze su cui intervenire.