Un agente AI che paga da solo: perché la verifica lato server decide tutto

Un agente AI che firma e paga da solo mette a nudo un problema di fiducia nel tuo codice

Su dev.to è comparso un racconto tecnico che vale la pena leggere fino in fondo: "My AI agent hired a law firm and paid them while I was sleeping". L'autore descrive un agente, chiamato ProofPay, che riceve un obiettivo e un budget, sceglie un fornitore nel marketplace, firma il contratto, mette il deposito in escrow e poi si spegne. Quando arriva la conferma del lavoro, l'agente si risveglia, riverifica ogni certificato del registro pubblico direttamente alla fonte e sblocca il pagamento solo se cinque controlli passano.

Il dettaglio decisivo è uno solo: come scrive l'autore, "l'AI non tocca mai i soldi". Il modello ragiona, sceglie, legge le prove e può dire "non pagare". Ma la decisione finale di muovere denaro la prende codice normale, leggibile, deterministico. Non il prompt, non l'LLM. Ed è esattamente questa separazione che, se manca nel tuo repository, apre una voragine.

Cosa significa se il tuo codice l'ha scritto Bolt

Mettiamo che tu abbia generato con Bolt un flusso in cui un agente o una funzione decide qualcosa di sensibile: approvare un rimborso, applicare uno sconto, cambiare uno stato d'ordine, sbloccare un accesso. Quando prototipi in fretta, è facilissimo che la logica di autorizzazione finisca dove non dovrebbe stare: dentro il client, dentro il prompt, oppure in un endpoint che si fida di quello che riceve senza riverificarlo.

Il problema tecnico qui ha un nome preciso: verifica lato server e controllo delle autorizzazioni. L'esempio del racconto lo illustra bene. Un certificato era valido al momento dell'invio, ma è stato revocato dopo. La piattaforma aveva già detto "tutto ok". L'agente però ricontrolla poco prima di pagare, trova che il documento non esiste più e rifiuta. Due controlli, in due momenti diversi, e il valore sta proprio nel punto in cui non coincidono.

Se il codice generato da Bolt controlla i permessi una volta sola, o si fida dello stato che arriva dal frontend, il tuo repository ha lo stesso buco che quel design ha evitato di proposito. Un utente può inviare una richiesta con dati validi al momento giusto e farla approvare quando non dovrebbe più esserlo. È l'anatomia classica di un IDOR o di un bypass di autorizzazione mascherato da "funziona nella demo".

Perché ora ti serve un audit

La velocità con cui uno strumento AI ti porta da idea a app pubblicata è reale. Il problema non è aver usato l'AI: è non avere un verdetto su cosa hai effettivamente messo online. Un agente che decide e un endpoint che paga sono comodi da generare, ma nessuno strumento di generazione ti dice se la decisione finale è protetta da codice deterministico o se, sotto pressione, l'intero flusso si fida di un input manipolabile.

Un audit serve a rispondere a domande che di solito nessuno si pone finché non è tardi:

• La logica che muove denaro o cambia stato è eseguita lato server, o parte della decisione vive nel client?
• I controlli di autorizzazione vengono rifatti al momento dell'azione, o solo quando il record viene creato?
• Un prompt o un modello può, direttamente o indirettamente, autorizzare un'operazione irreversibile?
• Cosa succede se un dato valido diventa invalido tra la creazione e l'esecuzione?

Con VibeInspect carichi lo ZIP del tuo repository e ottieni un'analisi con un PDF che ti dà un verdetto. Niente server da configurare, e il codice sorgente viene cancellato al termine dell'analisi. Non è un pentest, non corregge il codice e non promette sicurezza assoluta: ti dice dove guardare, con evidenze, così non stai indovinando.

Cosa un linter non vede

Un linter è utile e va tenuto, ma vive su un altro piano. Segnala variabili inutilizzate, import mancanti, stile incoerente, tipi che non tornano. Non ha idea di chi può eseguire una funzione né di quando dovrebbe farlo.

Un linter non ti dirà mai che il tuo endpoint di pagamento accetta un order_id senza verificare che appartenga all'utente autenticato. Non nota che la revoca di un permesso non viene ricontrollata prima dell'azione. Non capisce che una decisione presa da un LLM finisce per autorizzare una scrittura sensibile senza un cancello di codice in mezzo. Non vede che lo stesso controllo di autorizzazione manca in tre rotte su cinque.

Sono tutti problemi di logica applicativa e di flusso, non di sintassi. Passano ogni build verde e ogni linter felice, poi esplodono quando qualcuno invia esattamente la richiesta che nessuno aveva previsto. Il piano Diagnostic di VibeInspect è pensato proprio per questo: file, riga ed evidenze sui punti dove la tua logica di autorizzazione e la verifica lato server non tengono, senza correzioni automatiche e senza revisione umana.

Cosa fare questa settimana

Non serve riscrivere tutto. Serve un giro mirato sui punti che contano:

1. Elenca ogni azione irreversibile o sensibile del tuo repository: pagamenti, rimborsi, cambi di stato, sblocchi di accesso, cancellazioni.
2. Per ognuna, verifica che il controllo di autorizzazione sia eseguito lato server e ripetuto al momento dell'azione, non solo alla creazione del record.
3. Cerca ogni punto in cui una decisione dell'AI porta direttamente a una scrittura: inserisci un cancello di codice deterministico che possa dire "no", mai un "sì" cieco.
4. Simula il caso scomodo: un dato valido che diventa invalido tra due passaggi. Il tuo flusso se ne accorge?
5. Carica lo ZIP su VibeInspect e leggi il verdetto con file e riga, così sai da dove partire invece di cercare a caso.

Un agente che paga mentre dormi è affascinante finché a decidere è codice che puoi leggere. Se nel tuo repository quella decisione se la prende qualcos'altro, è il momento di scoprirlo prima che lo scopra un utente.