Secondo OWASP, l'iniezione immediata di codice è il rischio numero uno per le applicazioni aziendali che utilizzano modelli linguistici, e l'organizzazione si conferma al primo posto della sua classifica Top 10 per il secondo anno consecutivo. Non si tratta di uno scenario teorico o di un problema di laboratorio: è una diretta conseguenza del funzionamento di questi sistemi.
Un modello linguistico non distingue tra le istruzioni fornitegli dallo sviluppatore e il testo che elabora. Tutto arriva sotto forma di parole. Se un documento letto dal sistema contiene qualcosa in forma di istruzione, è possibile che venga trattato come tale.
La versione nota, ovvero un utente che scrive "ignora le tue istruzioni", è la meno preoccupante, perché l'attaccante deve essere presente e i suoi permessi sono quelli di qualsiasi altro utente.
La versione che conta in un ambiente aziendale è la iniezione indirettaIl testo dannoso non viene scritto dall'utente; è presente all'interno dei contenuti che il sistema elabora nel corso del suo normale funzionamento.
I vettori usuali:
In ogni caso, il processo è lo stesso: qualcuno esterno scrive del testo che il tuo sistema leggerà e che può influenzarne il comportamento. E in ogni caso, il danno potenziale è esattamente proporzionale all'entità delle autorizzazioni che hai concesso.
La risposta intuitiva sarebbe quella di filtrare le istruzioni sospette in fase di input. Questo però non funziona in modo affidabile, per tre motivi:
Il linguaggio ha infinite forme. Qualsiasi elenco di schemi proibiti può essere riformulato. L'istruzione può essere in un'altra lingua, parafrasata o suddivisa in più frasi.
Potrebbe essere nascosto. Testo vuoto su una pagina vuota in un PDF, metadati, contenuto che l'utente non vede ma che il sistema legge.
Il filtro non può conoscere l'intenzione. Un'e-mail legittima potrebbe contenere la frase "inoltra questo al reparto contabilità". Il sistema non dispone di un metodo affidabile per stabilire se si tratti di un'istruzione per se stesso o di un'informazione destinata a una persona.
La conclusione operativa è al tempo stesso scomoda e chiarificatrice: Dobbiamo presumere che l'iniezione avverrà e progettare in modo che non abbia importanza.
Principio | In cosa consiste? | Ciò che impedisce |
|---|---|---|
Permesso minimo | Il sistema accede solo a ciò che è necessario per il suo compito specifico | Che un'istruzione iniettata raggiunga dati esterni |
separazione dei canali | Il contenuto esterno non viene mai trattato come un'istruzione di sistema. | Lascia che un PDF ridefinisca il comportamento |
Lista bianca delle azioni | Sono consentite solo le operazioni esplicitamente elencate. | Che accada qualcosa di imprevisto |
Validazione umana nell'irreversibile | Pagamenti, comunicazioni esterne, modifiche alla produzione | Che il danno si materializzi senza revisione |
Registrazione completa | Registra ciò che è stato inserito e ciò che è stato eseguito. | Che l'incidente sia irreparabile |
Queste cinque sono decisioni architetturali, non configurazioni di strumenti. E tutte e cinque hanno un costo minimo se prese prima della fase di sviluppo, motivo per cui questo articolo si inserisce più in una discussione sulla progettazione che sulla sicurezza.
OWASP aggiunge a questa tabella due rischi correlati che meritano di essere menzionati: LLM02, divulgazione di informazioni sensibili, E LLM06, capacità in eccesso. I tre presentano lo stesso problema visto da angoli diversi: cosa può leggere il sistema, cosa può fare e chi può influenzarlo. Abbiamo sviluppato questo in Concedere autorizzazioni a un agente è una decisione rischiosa
Immaginate un assistente che elabora le fatture in arrivo nella casella di posta elettronica dell'amministrazione: estrae l'importo, il fornitore e il numero di conto, e prepara il pagamento.
Un fornitore fraudolento invia una fattura che include una piccola istruzione in calce al sistema per utilizzare un numero di conto diverso. Se l'assistente ha l'autorizzazione a preparare i pagamenti e nessuno verifica il numero di conto confrontandolo con i dati del fornitore, la frode viene portata a termine con l'efficienza di un sistema automatizzato.
Si noti che in questo esempio il modello non ha fallito: ha fatto esattamente ciò che il testo gli ha richiesto. Il difetto risiede nella progettazione, che ha permesso a un testo esterno di determinare un'informazione cruciale senza verificarla rispetto alla fonte di verità.
Ecco perché ripetiamo la regola in ogni progetto: Il modello elabora e interpreta; il sistema decide i fatti.. Importi, conti, stati e autorizzazioni vengono verificati rispetto al sistema di origine; non vengono mai accettati dal contenuto elaborato.
Quando qualcuno presenta una soluzione basata sull'intelligenza artificiale in grado di leggere contenuti esterni, tre domande distinguono una soluzione seria da una improvvisata:
Un fornitore che risponde "il nostro modello non cade in questa trappola" non ha compreso il rischio. Il contenimento non dipende dalla qualità del modello, ma dalla portata che gli è stata concessa.
Si tratta della manipolazione del comportamento di un modello linguistico attraverso un testo che il modello elabora come se fossero istruzioni. OWASP lo classifica come il rischio principale nella sua Top 10 per le applicazioni LLM entro il 2025, perché il modello non distingue strutturalmente tra le istruzioni dello sviluppatore e il contenuto che analizza.
Questa è la variante rilevante negli ambienti aziendali: le istruzioni non sono scritte dall'utente, ma sono contenute all'interno del materiale che il sistema elabora abitualmente, come un'e-mail di un fornitore, un PDF, una pagina web, un ticket di supporto o un campo di un modulo.
Non in modo affidabile. Il linguaggio consente infinite riformulazioni, le istruzioni possono essere nascoste in testo invisibile o metadati e un filtro non può determinare l'intento. L'approccio corretto è presumere che accadrà e limitare i potenziali danni attraverso autorizzazioni e controlli.
Con cinque principi di progettazione: autorizzazioni minime per ogni attività, separazione tra contenuti esterni e istruzioni di sistema, lista bianca delle azioni consentite, convalida umana obbligatoria nelle operazioni irreversibili e registrazione completa degli input e delle azioni eseguite.
Sì, se il sistema li elabora e dispone di ampi permessi. L'esempio tipico è una fattura che include un'istruzione per modificare il numero di conto di pagamento. Il problema non risiede nel modello in sé, ma nella progettazione che consente a un testo esterno di determinare dati critici senza verificarli rispetto alla fonte.
Cosa succede se il contenuto elaborato include istruzioni dirette al sistema? Cosa può fare il sistema nello scenario peggiore? E si potrebbe ricostruire un incidente avvenuto un mese fa? Una risposta che nega la possibilità di un attacco indica una scarsa consapevolezza del rischio.
Il vostro sistema di intelligenza artificiale legge contenuti scritti da terzi? Analizziamo l'ambito di applicazione, le autorizzazioni, la separazione dei canali e la tracciabilità, e ti indichiamo qual è lo scenario peggiore possibile con la configurazione attuale. Richiedi una recensione →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
