Proteggere le chiamate ai tool nei chatbot IA: autorizzazioni, conferma e piano di rollback

Un chatbot per siti web cambia radicalmente nel momento in cui non si limita a rispondere, ma può eseguire azioni. Consultare un appuntamento è un'operazione gestibile. Annullare un appuntamento, modificare un indirizzo o elaborare un rimborso altera invece lo stato reale delle attività aziendali. Il modello linguistico può suggerire la chiamata al tool più adeguata, ma spetta a un livello applicativo separato e deterministico stabilire se l'azione sia consentita. Di conseguenza, la sicurezza delle chiamate ai tool nei chatbot IA non si ottiene con un prompt di sistema particolarmente rigido, bensì limitando le funzioni, verificando le autorizzazioni lato server, richiedendo conferme trasparenti e definendo un percorso di esecuzione controllato.

Perché un buon modello linguistico non sostituisce l'autorizzazione

Un modello opera su base probabilistica. Può fraintendere un'intenzione, aggiungere un parametro errato o reagire a contenuti manipolati. La documentazione OWASP sui rischi relativi all'’Excessive Agency individua tre cause principali: funzionalità eccessive, autorizzazioni troppo estese e un livello di autonomia sproporzionato. Il problema non è limitato agli input malevoli: anche una richiesta ambigua o un errore del modello apparentemente plausibile possono avviare un'azione indesiderata.

La regola architetturale fondamentali è la seguente: il modello formula una proposta, ma l'applicazione la autorizza e la esegue. Una chiamata a un tool come cancelAppointment rappresenta inizialmente solo un'intenzione strutturata. Soltanto un controllo delle policy può verificare l'utente, il tenant, l'oggetto, l'azione consentita, lo stato attuale e la conferma richiesta. Questa separazione integra la protezione contro la prompt injection nei chatbot per siti web e rimane indispensabile anche quando non viene rilevato alcun attacco diretto.

Classificare ogni tool in base all'impatto e non al nome

I team non dovrebbero classificare l'intero chatbot come genericamente "sicuro" o "critico". Ciò che conta davvero è l'impatto di ogni singolo tool. Una matrice di rischio essenziale offre immediata chiarezza:

• In sola lettura e poco sensibile: consultazione degli orari di apertura o di informazioni di prodotto pubbliche.
• In sola lettura ma con dati personali: visualizzazione dello stato di un ordine o dei dati del cliente; richiede la verifica dell'identità, del tenant e della pertinenza dell'oggetto.
• In scrittura, ma facilmente reversibile: creazione di una richiesta interna di ricontatto o aggiunta di una nota non vincolante.
• A impatto elevato o difficilmente reversibile: cancellazione di una prenotazione, modifica dei dati di contatto, pubblicazione di contenuti, invio di messaggi o avvio di pagamenti.

Da ciascuna classe derivano le autorizzazioni, il livello di conferma, i limiti e la registrazione dei log. Un'autorizzazione generica del tipo "Il chatbot può utilizzare il CRM" è troppo vaga. È preferibile definire un elenco di funzionalità concrete con parametri ben delimitati e transizioni di stato consentite.

Il privilegio minimo inizia con la definizione precisa delle funzioni

La OWASP Authorization Cheat Sheet raccomanda l'uso del principio del privilegio minimo e l'approccio Deny by Default. Applicato alle chiamate ai tool, questo significa che il chatbot deve disporre soltanto della funzione e del sottoinsieme di dati strettamente necessari per il singolo passaggio.

Strumenti circoscritti al posto di interfacce universali

Un tool come getOrderStatus(orderId) è molto più semplice da mettere in sicurezza rispetto a un accesso aperto al database. Una funzione come requestCallback(topic, timeWindow) offre un controllo superiore rispetto a una routine generica per l'invio di messaggi arbitrari. L'uso incontrollato di funzioni SQL, shell, URL o email aumenta inutilmente la superficie d'impatto. Inoltre, i tool di test non più necessari devono essere rimossi dal catalogo di produzione.

Esecuzione nel contesto dell'utente autenticato

Il backend non deve mai presumere che il modello fornisca l'ID cliente corretto. Deve invece ricavare l'utente e il tenant correnti da una sessione sicura e verificare nuovamente, per ciascun oggetto, la presenza dei diritti di accesso. Le differenze pratiche tra una chat pubblica e un'area riservata sono approfondite nell'articolo su identità e accesso ai dati nel portale clienti. Un account di servizio generico con diritti completi rappresenta quasi sempre la scelta sbagliata per le azioni legate ai singoli utenti.

Validazione deterministica dei parametri

I parametri del tool richiedono uno schema rigido: campi consentiti, tipi di dati, lunghezze, intervalli di valori e regole di stato. L'ID di un appuntamento deve corrispondere all'utente, la data deve rientrare in un periodo valido e l'azione deve integrarsi nello stato attuale. Eventuali campi sconosciuti devono essere rifiutati. L'applicazione deve inoltre garantire che il nome del tool provenga da una allowlist definita e non venga eseguito a partire da testo libero.

La conferma deve mostrare l'azione effettiva

Per modifiche ad alto impatto, una semplice domanda come "Sei sicuro?" non è sufficiente. La guida OWASP sull'autorizzazione delle transazioni introduce il principio "What You See Is What You Sign": gli utenti devono poterne esaminare e confermare i dettagli chiave. Per un chatbot di un sito web, questo si traduce in:

• "Annullare l'appuntamento del 18 agosto alle 14:30" invece di "Conferma modifica"
• "Modificare l'indirizzo di spedizione dell'ordine ...84 con Roma" invece di "Salva dati"
• "Creare una richiesta di ricontatto con oggetto Fatturazione" invece di "Invia richiesta"

La conferma viene associata lato server a quella specifica bozza di azione. Se la destinazione, l'importo, la data, il destinatario o altri parametri rilevanti cambiano, la conferma scade. Essa deve avere una durata limitata e non può essere riutilizzata per un'altra azione. Per le operazioni particolarmente critiche, può essere necessaria una riautenticazione o l'approvazione di un operatore umano. Il modello non deve potersi sostituire a questo passaggio né scavalcarlo formulando una risposta rassicurante.

Pianificare idempotenza, limiti e procedure di rollback

Anche una chiamata a un tool autorizzata correttamente può essere ricevuta due volte a causa di inconvenienti tecnici: il browser ripete la richiesta, un timeout innesca un tentativo di retry o l'utente invia nuovamente lo stesso messaggio. I tool che modificano lo stato dovrebbero quindi utilizzare un ID di idempotenza lato server. Con lo stesso ID, l'azione viene eseguita al massimo una volta e un eventuale retry riceve il risultato già elaborato.

Ogni tool deve inoltre prevedere limiti appropriati: chiamate massime per sessione, timeout brevi, tentativi di retry limitati e l'interruzione automatica di sequenze anomale. Prima di procedere, il backend verifica nuovamente lo stato, evitando ad esempio che una prenotazione già cancellata venga elaborata una seconda volta. Laddove possibile, l'azione dovrebbe essere creata inizialmente come bozza o ordine in sospeso. Se le modifiche dirette sono inevitabili, deve essere chiaro come compensarle, revocarle o trasferirle al team di supporto. La presenza di un piano di rollback e la gestione della modalità degradata prevengono la necessità di improvvisare in caso di malfunzionamenti.

Registrare i log senza raccogliere informazioni riservate

Un log di sicurezza deve poter chiarire chi ha autorizzato una determinata azione, su quali basi e con quale esito è stata eseguita. I dati utili includono un ID utente pseudonimizzato, tool e versione, riferimento all'oggetto, versione della policy, esito dell'autorizzazione, ID di conferma, ID di idempotenza, timestamp e risultato. Password, token, cronologie di chat complete e dati personali non necessari non devono finire nei log di sicurezza.

La OWASP AI Agent Security Cheat Sheet raccomanda l'uso di dati decisionali strutturati per le azioni ad alto rischio e la netta separazione tra processo decisionale ed esecuzione. Questo approccio differisce dal tracing tecnico completo: ai fini degli audit di sicurezza, ciò che conta è una traccia sintetica e affidabile della catena di approvazione. La conservazione e gli accessi devono essere commisurati alle reali esigenze di verifica.

Un'architettura solida in cinque livelli

1. Dialogo e proposta: il modello individua l'intento e genera una bozza di azione strutturata, ma non esegue nulla direttamente.
2. Decisione della policy: un componente deterministico verifica l'allowlist dei tool, l'utente, il tenant, l'oggetto, i parametri, la classe di rischio e i limiti.
3. Conferma: l'interfaccia mostra i dati essenziali dell'azione. L'approvazione ha una durata breve ed è vincolata alla bozza originale.
4. Esecuzione: un executor con privilegi ristretti controlla nuovamente l'autorizzazione subito prima della chiamata e impiega un ID di idempotenza.
5. Tracciabilità e risposta: l'esito, gli errori e la catena di approvazione vengono registrati nel rispetto del principio di minimizzazione dei dati; gli allarmi, le compensazioni e il passaggio a un operatore umano sono definiti preventivamente.

Il framework NIST AI RMF Core suddivide questi compiti nelle fasi di Govern, Map, Measure e Manage. In termini pratici: stabilire responsabilità e soglie di rischio, comprendere il contesto d'uso, testare i controlli e reagire prontamente alle deviazioni riscontrate.

Matrice di test prima del rilascio in produzione

I test con esito positivo non sono sufficienti. Un tool deve dimostrare di fallire in modo sicuro anche in condizioni avverse. Una matrice di test ripetibile dovrebbe coprire almeno questi casi:

• Un utente non autenticato o privo delle autorizzazioni necessarie richiede l'azione.
• Una sessione valida fa riferimento a un oggetto appartenente a un altro tenant.
• I parametri essenziali vengono modificati dopo che la conferma è già avvenuta.
• La stessa richiesta viene inviata nuovamente a causa di un timeout o di un doppio clic.
• Un tool restituisce istruzioni manipolate o campi aggiuntivi inattesi.
• Una chiamata supera i limiti temporali, di volume o di costo.
• Il sistema di destinazione diventa indisponibile tra la verifica e l'esecuzione.
• Un'autorizzazione viene revocata un istante prima dell'esecuzione.

I risultati attesi non devono limitarsi alle esecuzioni corrette, ma includere rifiuti trasparenti, dati inalterati ed eventi di sicurezza utili per le analisi. Prima di abilitare i permessi di scrittura per gli utenti finali, è consigliabile verificare il flusso in Shadow Mode con richieste reali, senza eseguire le azioni proposte.

Checklist per i team web

• Ogni tool è circoscritto, mirato e inserito in una allowlist definita?
• Utente, tenant, oggetto e azione vengono verificati lato server?
• Trovano applicazione il principio Deny by Default e i permessi tecnici minimi?
• Gli utenti possono esaminare tutti i dati essenziali prima delle azioni critiche?
• La conferma scade in caso di modifiche e allo scadere del tempo impostato?
• È presente un ID di idempotenza per impedire esecuzioni doppie?
• Sono previsti limiti, timeout, interruzioni, compensazioni e l'handover a un operatore umano?
• Token, credenziali e dati personali non necessari vengono esclusi dai log?
• La matrice di test copre errori di autorizzazione, tentativi di manipolazione, retry e indisponibilità del servizio?

Conclusione: il modello propone, l'applicazione decide

Un chatbot per siti web in grado di compiere azioni non deve necessariamente partire con permessi d'accesso completi. È preferibile iniziare con un'azione limitata e reversibile, costruendovi attorno una trasparente catena di approvazione. Progettando insieme parametri dei tool, autorizzazioni lato server, conferme dettagliate, idempotenza e procedure di rollback, la chat offrirà un reale valore operativo senza delegare al modello il ruolo di sistema di sicurezza. Per compiere il passo successivo, è consigliabile organizzare un workshop tra i team di prodotto, sviluppo, supporto e protezione dati: individuate un'azione concreta, valutatene il rischio e definite la gestione sicura del rifiuto prima del primo rilascio in ambiente di produzione.