Agenti AI che rimborsano da soli: cosa rischia il tuo repository

Klarna ha dato a un agente AI il potere di rimborsare, poi ha rimesso gli umani nel giro

Un agente AI non risponde soltanto: agisce. Legge da un database, scrive su un CRM, muove un rimborso su un processore di pagamento. È questa la differenza raccontata nell'articolo "AI Agents vs AI Chatbots: What's the Difference in 2026?", che parte da un caso reale: l'assistente di Klarna, lanciato nel 2024, arrivava a gestire cancellazioni e rimborsi dall'inizio alla fine, riducendo i tempi di risoluzione da 11 minuti a meno di 2. Poi, nel 2025, l'azienda ha corretto la rotta e ha ricominciato ad assumere persone per il supporto.

La frase chiave dell'articolo è netta: "un chatbot risponde, un agente agisce". E un'azione sbagliata di un agente — un rimborso errato, un aggiornamento sballato del CRM — fa molti più danni di una risposta imprecisa. L'autonomia senza guardrail, percorsi di escalation e checkpoint umani crea un tipo di rischio nuovo.

Qui non conta il marketing dell'AI. Conta cosa può toccare il tuo codice quando gli dai il permesso di scrivere sui sistemi.

Cosa significa se il tuo codice l'ha scritto Lovable

Mettiamo che tu abbia costruito con Lovable un'app SaaS che include un pannello di assistenza, magari con un piccolo agente che gestisce richieste dei clienti. Nel momento in cui quell'agente — o anche solo un endpoint del tuo backend — può eseguire un rimborso, cancellare un ordine o modificare un record utente, il confine tra "legge" e "scrive" diventa la parte più delicata del tuo prodotto.

Il problema tecnico concreto qui è l'IDOR (Insecure Direct Object Reference): un endpoint che accetta un identificativo — order_id, customer_id, refund_id — e agisce su quella risorsa senza verificare che chi chiama abbia davvero il diritto di toccarla. Gli strumenti come Lovable generano rapidamente route funzionanti: la logica di business gira, la demo passa, il rimborso arriva a destinazione. Ma "funziona" non vuol dire "controlla chi sei".

Un agente che può rimborsare è potente esattamente quanto è pericoloso l'endpoint che chiama. Se quell'endpoint non impone il controllo di autorizzazione, chiunque conosca o indovini un identificativo può ottenere un'azione che vale denaro reale. E non serve un agente autonomo: basta una route esposta senza il giusto controllo di ownership.

Perché ora ti serve un audit

Quando generi con l'AI, il codice nasce già in produzione nella tua testa: gira, quindi lo pubblichi. Ma tra "gira" e "è sicuro esporre azioni che spostano soldi" c'è una distanza che non vedi finché qualcuno non la attraversa.

Un audit indipendente serve proprio a questo: darti un verdetto sullo stato reale del repository prima che un endpoint scrivibile diventi un incidente. Non parliamo di un pentest e non parliamo di correzioni automatiche. Parliamo di sapere, nero su bianco, dove il tuo codice esegue azioni sensibili senza verificare l'autorizzazione di chi le richiede.

VibeInspect funziona su richiesta: carichi lo ZIP del repository, degli specialisti AI lo analizzano e ricevi un PDF con il verdetto. Nessun server coinvolto, il codice sorgente viene cancellato a fine analisi. Con il piano Diagnostic ottieni file, riga ed evidenze dei punti in cui un'azione — come un rimborso — parte senza un controllo di ownership adeguato. Niente correzioni al posto tuo, niente revisione umana: ti diciamo dove guardare, con la precisione che ti serve per intervenire.

È la differenza tra scoprire il problema durante un audit e scoprirlo quando un utente ha rimborsato un ordine che non era il suo.

Cosa un linter non vede

Un linter è utile, ma vive a un altro livello. Controlla lo stile, le variabili non usate, le importazioni mancanti, qualche pattern rischioso a livello di sintassi. Quello che non capisce è la logica di autorizzazione della tua applicazione.

Un linter non sa che l'endpoint POST /refunds/:id dovrebbe verificare che l'utente autenticato sia il proprietario dell'ordine. Non conosce le regole del tuo dominio: chi può rimborsare cosa, quali ruoli possono cancellare un record, quali azioni richiedono un permesso amministrativo. Per un linter una funzione che esegue un rimborso senza controllo è codice perfettamente valido — indentato bene, senza errori di sintassi, pronto a girare.

L'IDOR è esattamente il tipo di falla che passa indenne attraverso i linter, i test funzionali e persino la demo che convince il cliente. Il codice fa quello che gli hai chiesto. Il punto è che fa anche quello che non avresti mai voluto: obbedisce a chi non dovrebbe.

È qui che serve uno sguardo che ragiona sulla logica delle autorizzazioni, non solo sulla forma del codice. La lezione di Klarna vale anche per il tuo repository: la potenza di un'azione automatica dipende interamente dai controlli che la circondano.

Cosa fare questa settimana

Non devi riscrivere tutto. Devi guardare i punti in cui il tuo codice agisce, non solo risponde.

1. Elenca le azioni che scrivono. Fai la lista di ogni endpoint che modifica dati sensibili: rimborsi, cancellazioni, cambi di stato, aggiornamenti di record altrui.
2. Verifica l'ownership su ognuno. Per ciascuna route, controlla che ci sia una verifica esplicita: l'utente autenticato ha davvero il diritto di agire su quella risorsa? Un customer_id nel body non basta.
3. Prova a manipolare gli identificativi. Con un secondo account, tenta di eseguire un'azione su una risorsa che non ti appartiene, cambiando l'ID nella richiesta. Se funziona, hai un IDOR.
4. Aggiungi guardrail sulle azioni ad alto impatto. Come Klarna ha reintrodotto checkpoint e supervisione, definisci quali azioni richiedono un controllo extra prima di eseguire.
5. Ottieni un verdetto sul repository. Se hai costruito con Lovable e non sai in quanti endpoint manca il controllo di autorizzazione, un audit Diagnostic ti dà file, riga ed evidenze da cui partire.

Un agente che rimborsa da solo non è il problema. Il problema è non sapere se il codice sotto controlla davvero chi sta chiedendo. Scoprilo prima che lo faccia qualcun altro: avvia l'analisi del tuo repository con VibeInspect.