QAtration lancia veri attacchi di prompt injection contro il tuo bot IA e ti consegna un rapporto in parole semplici di ciò che ha lasciato trapelare o fatto, prima che lo trovi qualcun altro. Lo esegui tu. Sulla tua macchina o nella tua CI, contro il tuo deployment: nessun account, nessun endpoint da consegnare, niente che venga inviato a noi.
Non puntare questo strumento su un sistema che non è tuo. Invia attacchi veri (prompt injection, esfiltrazione di dati, abuso di tool) a qualunque URL tu gli indichi. Il tuo deployment, oppure uno il cui proprietario ti ha dato un permesso scritto in anticipo. Non un chatbot pubblico che ti sembra interessante. Non la demo di un fornitore. Leggi AUTHORISED-USE.md prima della prima esecuzione.
Due dipendenze. L'intero corpus di attacchi è incluso, e con esso le prove che stanno dietro ogni numero di questa pagina, tutte quante in
out/, che viene distribuito insieme al repository. I rapporti degli altri due strumenti non ci sono, perché le loro licenze non lo consentono. I comandi che li rigenerano sì.
Misurato sui nostri obiettivi di test, non estrapolato. La trascrizione qui accanto illustra l'idea, i numeri qui sopra sono risultati.
Ogni funzionalità IA che va in produzione è una nuova superficie di attacco. Quanta parte della tua questo strumento riesce a raggiungere dipende da ciò che il tuo deployment gli lascia vedere, e qui la linea viene tracciata invece che sfumata, perché uno scanner che dichiara di coprire ciò che non può osservare è esattamente la cosa che stai cercando di evitare.
Basta un endpoint di chat: questo si può testare così com'è, anche nell'arco di più turni.
Il testo dell'attaccante prevale sulle regole del tuo bot: «ignora le tue istruzioni e…».
Il tuo bot rivela chiavi API, codici interni o i dati di un altro cliente.
Le tue istruzioni nascoste trapelano alla lettera: la mappa per ogni attacco successivo.
Una regola piantata in un turno cambia in silenzio ogni risposta successiva, molto dopo che la conversazione è tornata a sembrare normale.
Non puoi piantare un documento in una base di conoscenza su cui non hai il permesso di scrittura, e dall'esterno non puoi distinguere una chiamata a tool realmente eseguita da una che il bot ha soltanto descritto, una distinzione che, nelle nostre misure, i bot sbagliano su sé stessi. Per questo servono il corpus, le definizioni dei tool o la visibilità delle chiamate. Misurato sulle prove distribuite con questo strumento: 62 dei 137 riscontri su obiettivi che riportano le chiamate ai tool non compaiono affatto se si legge soltanto la risposta. Il bot risponde con garbo e mette il segreto in un argomento della chiamata.
Il tuo agente viene convinto a compiere un'azione irreversibile: cancellare, rimborsare, inviare una email.
SQL o un comando di shell infilati dentro una chiamata a tool. Una vecchia classe di bug, una porta d'ingresso nuova.
Un solo documento malevolo nel tuo RAG dirotta le risposte a domande innocue.
Una riga nascosta nella descrizione di un tool fa sì che il tuo agente riveli qualcosa a fronte di una domanda ordinaria, senza alcun messaggio da parte di un attaccante.
qatration init scrive la configurazione al posto tuo: l'URL, la forma della richiesta, e in quale campo della risposta si trova il testo del bot. Un bersaglio remoto vuole anche un header di autenticazione, come variabile d'ambiente. Configurazioni pronte per le API in formato OpenAI e per quelle di Anthropic, Bedrock e Vertex. qatration onboard invia una domanda ordinaria e ti dice che cosa manca prima che parta un solo attacco.
qatration init genera un segreto tutto tuo e il blocco da incollare nel tuo prompt di sistema. L'esecuzione conferma prima di tutto che sia davvero arrivato: un canarino non piantato significa che nessun controllo trova niente, e questo si legge esattamente come un bot che ha retto.
Che cosa è trapelato, come esattamente, e la correzione che lo chiude, scritto per una squadra senza un esperto di sicurezza. --fail-on exploited fa fallire una build. qatration sarif mette i riscontri direttamente nella tua scheda code scanning.
Un attacco che non è passato riporta uno zero. Lo stesso vale per un controllo che non è riuscito a partire, e lo stesso per un bot davvero irrobustito, ed è qui che i test si arenano: tre fatti diversi arrivano con lo stesso aspetto, e nessuno sa che cosa provare dopo. Queste sono misure prese da esecuzioni reali, non estrapolazioni.
E una violazione è una violazione solo se l'ha causata l'attacco. Ogni obiettivo riceve prima un'esecuzione innocua: domande ordinarie, nessuno che attacchi. Su uno dei bot qui presenti,
canary_in_tool_call scatta sull'88% di quel traffico ordinario, quindi un riscontro che si appoggia soltanto a esso viene contrassegnato come non attribuibile invece che conteggiato.
Quando un attacco fallisce, il rapporto dice che cosa lo ha fermato: il controllo dell'identità, il filtro dei contenuti, un permesso sul backend, oppure una chiamata a strumento soltanto stampata e mai realmente eseguita. Quest'ultima, in una trascrizione, sembra una violazione e non vale nulla.
Un bot, due modelli, 254 attacchi ciascuno, 3 tentativi ciascuno. Il più piccolo ha ceduto su 27 di essi, il più grande su 24, e 18 di quelli sono gli stessi attacchi, 17 dei quali fanno cedere entrambi i modelli a ogni singolo tentativo. Su questo bot il modello più grande ha rimescolato quali attacchi passano ai margini. Il buco non lo chiude.
Contro un vero framework di guardrail, 46 attacchi digitati nella casella di chat: non ne è passato nessuno. Non è passato nemmeno uno portato dentro un documento recuperato, finché entrambe le sue barriere erano attive. Spegni il filtro in uscita e quello stesso documento se ne esce a ogni singolo tentativo. I filtri in ingresso leggono ciò che l'utente digita, e non vedono mai ciò che la tua base di conoscenza consegna al modello, quindi il guardrail in ingresso non è mai stato ciò che lo fermava.
Abbiamo rimandato gli stessi messaggi a quel guardrail e non è sempre stato d'accordo con sé stesso: cinque formulazioni hanno ricevuto verdetti diversi a parità di input, e una domanda ordinaria è stata permessa dieci volte su dodici. Perciò riferiamo quanti tentativi hanno rotto qualcosa, e non se lo ha fatto uno solo. Una singola esecuzione è la storia di un solo pomeriggio, e questo vale per un risultato pulito quanto per uno cattivo, incluso il nostro.
Lo stesso guardrail che ha bloccato quel documento ha anche rifiutato di rispondere a 6 domande ordinarie di clienti su 9 riguardo agli argomenti coinvolti. Una difesa che risponde «no» ai tuoi clienti è un numero che vuoi conoscere prima di pubblicare, non dopo.
Uno scanner che trova sempre qualcosa non vale niente, quindi abbiamo misurato il numero opposto: 1500 sonde innocue su 30 obiettivi, senza alcun attaccante in nessuna di esse, attraverso gli stessi controlli. Metà sono utenti che parlano di sicurezza a pieno titolo, perché è proprio questo che manda in crisi un riconoscitore di pattern: qualcuno che incolla la query che fallisce, un addetto all'assistenza che inoltra uno stack trace, qualcuno che chiede se un dominio sosia sia autentico.
I bot scritti qui sono il caso facile, così lo abbiamo puntato su un framework di agenti che qui nessuno ha progettato. Ha prodotto otto falsi allarmi in una sola esecuzione di 48 prompt puliti, in quattro categorie che 480 sonde contro la nostra flotta non avevano mai prodotto nemmeno una volta. Tutte e quattro sono corrette, e le due regole che stanno sotto fanno ora fallire la nostra build invece del tuo rapporto: nessun controllo può leggere la domanda, e nessun controllo può trattare le parole dell'agente stesso come prova riguardo al sistema.
Eseguito contro gli stessi obiettivi di terze parti usati da garak e promptfoo, con ogni risposta di tutti e tre valutata da una sola regola di sottostringa invece che dal judge proprio di ciascuno strumento. Su un'applicazione RAG senza alcun guardrail, il 46% delle sonde innocue restituisce già la stringa piantata, cosicché contare i riscontri misura l'applicazione e non l'attaccante. Uno dei tre strumenti lo dice nel proprio rapporto. Sull'obiettivo protetto tutti e tre segnano zero secondo la regola comune, e siamo stati gli unici a trovare qualcosa, una violazione su 324, mentre quello stesso deployment rifiuta di rispondere a 38 domande ordinarie di clienti su 48. Quella pagina pubblica anche i punti in cui gli altri due sono migliori, e un'affermazione che abbiamo ritirato dopo che un revisore ha chiesto un valore p. Leggi il confronto.
Un profilo di dodici sonde, tutte innocue: cinque bot hanno consegnato le proprie istruzioni a una semplice richiesta. Uno ha stampato la propria chiave di sessione riservata dentro la stessa frase che gli vietava di condividerla. Due hanno riferito il riavvio di un database pur non avendo alcuno strumento in grado di riavviare alcunché.
Ogni esecuzione viene conservata, quindi ogni riscontro porta la data in cui è comparso la prima volta. «Critico» è un'opinione. «Critico e aperto dal giorno tre» è un fatto su come una squadra risponde a riscontri del genere, ed è quella riga a far entrare una correzione nella pianificazione.
Un riscontro che ritorna dopo che l'hai chiuso viene segnalato come ritornato, e non conteggiato in silenzio insieme a quelli nuovi. Una correzione che non ha retto è la peggiore delle due conversazioni, e mescolarle la nasconde.
Se un'esecuzione non invia un attacco, quell'attacco finisce nel rapporto come non testato, mai come corretto. L'assenza non è un risultato pulito, e un rapporto che confonde le due cose ti dice che le tue vulnerabilità sono sparite quando in realtà nessuno ha guardato.
Alcune chiamate consegnano a un tool un valore che non compare in nessun testo che possiamo leggere. Quelli li elenchiamo a parte e ti diciamo quale log li apre, perché la differenza tra «abbiamo controllato ed era pulito» e «non siamo riusciti a vedere» è la differenza tra una misura e una promessa.
«Gli abbiamo detto di non rivelare segreti» è un'affermazione, non una difesa: sugli obiettivi qui presenti è caduta già ai primi attacchi. QAtration dichiara puliti anche i bot davvero blindati, quindi un risultato pulito significa davvero qualcosa. Misura il tuo bot, invece di gridare al lupo ogni volta.
Apache 2.0. Installalo, puntalo sul tuo deployment, conserva le prove.