Un’applicazione basata su un modello linguistico riceve istruzioni da tutto ciò che legge: l’utente, un documento recuperato, il contenuto di una pagina web, l’output di uno strumento. Non sa distinguere in modo affidabile un’istruzione dai dati. Quando il modello può chiamare strumenti, inviare messaggi o scrivere in un database, una frase nascosta in un documento diventa un’azione nei tuoi sistemi.
Testiamo l’intera applicazione e non solo il modello: i prompt, la pipeline di recupero, gli strumenti e i loro permessi, gli agenti e i protocolli che li collegano. La domanda è che cosa un attaccante può far fare, leggere o rivelare al sistema, e se i controlli attorno al modello reggono quando il modello stesso non regge.
01Perimetro
Che cosa testiamo
Prompt injection diretta e indiretta attraverso ogni input che il modello legge
Rivelazione di prompt di sistema, segreti e dati di altri utenti o tenant
Retrieval-augmented generation: avvelenamento, controllo degli accessi all’archivio dei documenti
Strumenti e function calling: permessi eccessivi, parametri non sicuri, confused deputy
Agenti: dirottamento degli obiettivi, avvelenamento della memoria, autonomia non sicura, fiducia tra agenti
Server Model Context Protocol: autenticazione, avvelenamento degli strumenti, esecuzione di comandi
Gestione dell’output: injection in browser, shell, query e sistemi a valle
Guardrail e filtri: aggiramento tramite codifica, lingua, gioco di ruolo e attacchi in più turni
Consumo di risorse e abuso dei costi
02Approccio
Come si svolge il lavoro
01
Revisione dell’architettura
Mappiamo che cosa legge il modello, che cosa può chiamare e con i permessi di chi. La maggior parte dei rilievi critici è visibile già in questa fase, sotto forma di un confine di fiducia che manca.
02
Test avversariali
Gli input vengono costruiti a mano e generati su larga scala contro ogni canale che porta al modello. Un attacco riuscito viene ridotto all’input minimo che lo riproduce.
03
Abuso di strumenti e agenti
Usiamo istruzioni iniettate per pilotare strumenti e agenti: leggere ciò che dovrebbe restare illeggibile, agire a nome di un altro utente, passare da un sistema al successivo.
04
Validazione dei controlli
Filtri, guardrail e passaggi di approvazione vengono testati singolarmente. Il report indica quale controllo ha fermato quale attacco e quale non ne ha fermato nessuno.
L’applicazione. La sicurezza del modello di base è responsabilità del suo fornitore. Ciò che controlli tu, e ciò che gli attaccanti sfruttano, è il modo in cui il modello è collegato ai tuoi dati e ai tuoi strumenti.
La prompt injection non si può correggere del tutto. A che cosa serve trovarla?
Serve a sapere che cosa ne consegue. Se l’injection porta a una risposta sbagliata, è un problema di qualità. Se porta a un’email inviata a nome dell’utente, è una vulnerabilità nei permessi attorno al modello, e si può correggere.
Usate i nostri dati per addestrare servizi di AI esterni o nei prompt che inviate loro?
No. I dati dei clienti, i prompt e i rilievi non vengono inviati a servizi di AI pubblici e non vengono usati per l’addestramento. Gli strumenti basati su modelli linguistici girano in ambienti che controlliamo noi.
Questo copre i requisiti dell’AI Act dell’UE?
I test avversariali sono una delle misure a cui il regolamento fa riferimento per determinati sistemi e modelli. Il report documenta metodo, perimetro e risultati in una forma adatta a essere usata come prova. Se e come il regolamento si applica al tuo sistema è una questione legale a cui non rispondiamo.