Checklist di hardening per iniezione di prompt per team LLM e agenti

1. Inventaria ogni canale di istruzioni

Prima di irrigidire, mappa dove le stringhe diventano istruzioni. I canali tipici includono prompt di sistema caricati sul lato server, messaggi di sviluppo in API di chat, chunk di documenti recuperati, payload di strumenti, corpi di webhook, inoltri di posta elettronica e campi di metadata che gli utenti non vedono ma che i modelli leggono comunque. Mancare un canale garantisce un punto cieco che gli attaccanti proveranno.

Documenta ogni canale con proprietario, classificazione dei dati e se il contenuto è controllato dall'utente finale. Contrassegna i canali che possono contenere HTML, markdown, codice o JSON serializzato separatamente - gli trucchi di codifica si concentrano lì. Revisita l'inventario trimestralmente o ogni volta che si aggiungono plugin.

2. Separa la politica dai dati non attendibili

La politica del sistema dovrebbe vivere in modelli di server controllati dagli utenti che non possono essere modificati. Il contenuto non attendibile deve arrivare all'interno di buste chiaramente etichettate: tag XML, campi JSON o sezioni markdown il cui titolo afferma che non sono direttive. Non interpolare mai il testo dell'utente nella stringa del sistema senza sfuggire e senza separazione strutturale raccomandata nel foglio di trucchi OWASP.

Per RAG, archivia le citazioni separatamente dalle frasi imperative quando possibile. I pipeline di recupero dovrebbero rimuovere i tag di script e gli attacchi omografi prima di incorporare. Se il tuo stack deve inlining chunk, antepone un avviso fisso che il testo del chunk è solo di riferimento.

3. Minimizza l'agenzia del modello su azioni sensibili

Ogni autorizzazione dello strumento è un payoff di iniezione. Elenca gli strumenti che leggono segreti, inviano email, spostano denaro o modificano configurazioni di produzione. Richiedi conferma umana, autenticazione step-up o percorsi di codice deterministici per quelle azioni. Gli agenti che possono navigare in URL arbitrari e pubblicare riassunti interni necessitano di limiti più stretti rispetto ai bot FAQ.

Applica il privilegio minimo agli ambiti OAuth che supportano gli strumenti. Ruota i token e verifica quali persone agenti possono invocare quali endpoint. Un'iniezione che raggiunge solo un indice di FAQ di sola lettura fa meno danni di una attaccata a un'API di distribuzione.

4. Convalida e normalizza gli input precocemente

Imposta lunghezze massime per campo, rifiuta payload binari inaspettati e normalizza Unicode in una forma canonica prima della tokenizzazione. Blocca o rimuovi caratteri di controllo noti che alcuni modelli trattano in modo strano. La convalida appartiene al codice dell'applicazione, non alla prosa del prompt che spera che il modello sia “sicuro”.

Per gli upload, esegui antivirus e sniffing di tipo; non fidarti delle estensioni. Converte i documenti in testo in un sandbox con timeout. Registra i fallimenti di conversione invece di silenziosamente cadere a stringhe vuote che potrebbero successivamente essere sostituite da contenuti di attaccanti al retry.

5. Esegui la regressione dell'iniezione deterministica

Mantieni un corpus di campioni malintenzionati e benigni. Esegui PromptShield o motori di regole equivalenti in CI quando cambiano i prompt, gli strumenti o le configurazioni di recupero. L'insieme di regole prompt-injection@2026-07-19.2 copre le famiglie di frasi, le persone carcerarie, gli attacchi delimitatori e le parole di esfiltrazione comuni - estendilo con incidenti interni.

Tratta la regressione come i test unitari: fallire un campione di attacco noto è un blocco di merge. Superare tutti i campioni è necessario ma non sufficiente; le parafrasi nuove richiedono comunque architettura e monitoraggio. Pubblica le modifiche al corpus nelle richieste di pull in modo che i revisori vedano l'intento.

6. Indurisci i percorsi di jailbreak e social

I jailbreak sfruttano l'empatia e l'autorità: false emergenze, richieste di aiuto per un bambino, affermazioni di stato dello staff di OpenAI o scenari di role-play che chiedono al modello di ignorare le politiche etiche. Forma i team di supporto e PM per non incorporare il linguaggio di override nelle macro. L'educazione degli utenti riduce gli auto-jailbreak accidentali anche quando la malizia è assente.

Allinea il rifiuto e la copia di escalation con ciò che il tuo backend effettivamente applica. Se il modello si scusa ma gli strumenti eseguono comunque, gli utenti imparano che le barriere di testo sono teatro. Abbina i confini narrativi a quelli tecnici.

7. Controlla l'iniezione indiretta nel recupero

Gli aggressori avvelenano wiki condivise, sezioni di commento o pagine SEO che si eseguono. Firma i documenti che si fidano; verifica le firme prima di indicizzare. Down-rank o escludi le pagine generate dagli utenti dai corpora di alta fiducia. Monitora per improvvisi spostamenti lessicali nel contenuto indicizzato che potrebbero indicare attività di campagna.

Al momento della risposta, mostra agli utenti quali chunk hanno influenzato una risposta in modo che possano rilevare citazioni senza senso. Quando i chunk contengono frasi imperative, considera l'abbassamento euristico a meno che non sia corroborato da fonti attendibili.

8. Gestione dell'output e resistenza all'esfiltrazione

Anche i filtri di input perfetti falliscono a volte. Applica le politiche di output: blocca le regex di API key, i nomi host interni e i modelli PII bulk prima che le risposte raggiungano i client. Per gli agenti, pulisci gli output degli strumenti prima di rientrare nel ciclo di contesto del modello. Limita la quantità di testo che una singola sessione può esportare ai webhook esterni.

Disabilita il rendering di HTML grezzo nella chat visibile all'utente quando non è richiesto. I collegamenti in markdown possono chiamare a casa; utilizza i domini dell'elenco consentiti o rimuovi i collegamenti nelle modalità aziendali.

9. Registrazione, privacy e conservazione

Registrare i tentativi di iniezione con payload hash, id regole e metadati del canale, ma non necessariamente segreti completi degli utenti incollati per errore. Definire la conservazione allineata con l'interesse legittimo del GDPR o il consenso, documentare nelle informative sulla privacy e supportare le richieste di cancellazione. Il monitoraggio della sicurezza deve rispettare la minimizzazione dei dati.

Fornire agli ingegneri di turno manuali che distinguono i colpi dello scanner, i blocchi WAF e i rifiuti del modello. Le tempeste di falsi positivi dovrebbero essere regolabili senza disabilitare completamente la registrazione.

10. Playbook di risposta agli incidenti

Quando l'iniezione ha successo, congelare le versioni degli agenti interessati, ruotare le credenziali che potrebbero essere state violate e catturare i prompt per il postmortem. Notificare i clienti se i loro dati o tenant sono stati interessati secondo le linee guida del vostro consulente legale. Aggiornare il corpus con la variante di payload di successo e aggiungere mapping di cheat-sheet.

Eseguire esercitazioni di tipo tabletop due volte l'anno. Includere il personale legale, PR e customer success, non solo gli ingegneri. Gli incidenti LLM si aggravano rapidamente quando gli agenti possono agire in modo autonomo.

11. Angoli multi-tenant e supply-chain

I prodotti SaaS devono isolare gli indici di recupero dei tenant e le memorie. Le fine-tune condivise o le cache dei prompt di sistema condivisi possono contaminare le istruzioni. I plugin di terze parti introducono rischi nella catena di approvvigionamento; verificare gli editor e bloccare le versioni.

Quando si integrano agenti esterni tramite MCP o protocolli simili, trattare le descrizioni degli strumenti remoti come input non attendibili, sono prompt con un altro nome.

12. Matrice di test (staging)

Per ogni candidato di rilascio, eseguire manualmente questa matrice anche se l'automazione passa:

- Stringhe di override dirette nella chat dell'utente. - Istruzioni indirette nascoste nei footer dei PDF caricati. - Contrabbando di argomenti degli strumenti tramite campi JSON annidati. - Persistenza della memoria di frasi ostili a più turni. - Payload codificati (base64, hex, script misti). - Personas di jailbreak e aggiornamenti di policy falsi.

Registrare le catture dello schermo per gli auditor. Notare quali controlli hanno bloccato l'impatto rispetto a quali hanno prodotto un rifiuto cortese mentre gli strumenti sono ancora in esecuzione, il rifiuto senza applicazione è un risultato.

13. Governance e proprietà

Assegna un proprietario cross-funzionale per il tracking di. La sicurezza definisce i limiti; la piattaforma implementa i controlli; il prodotto accetta il rischio residuo documentato nelle note di rilascio. Gli esecutivi ricevono metriche trimestrali: dimensione del corpus, elementi di hardening aperti, incidenti, tempo medio per patchare i modelli.

Evita la "sicurezza per demo". Le screenshot di marketing dovrebbero riflettere le stesse restrizioni degli strumenti di produzione. I modi di amministratore nascosti per le vendite invalidano la fiducia del cliente se scoperti.

14. Utilizzo dei risultati di PromptShield nelle recensioni

Esporta i risultati della scansione come artifact di discussione allegati ai biglietti di lancio. Ogni riga segnalata dovrebbe collegarsi a un elemento di controllo sopra e a un ingegnere nominato. Chiudi gli elementi con prove: richiesta di pull, differenza di configurazione o screenshot di monitoraggio - non assicurazione verbale.

Quando PromptShield rimane silenzioso su un campione preoccupante, trattalo come una lacuna nel set di regole da valutare - non come prova di sicurezza. Proponi nuove regole deterministiche con tag di versione seguendo le convenzioni di denominazione prompt-injection@2026-07-19.2.

15. Manutenzione a lungo termine

Iscriviti agli aggiornamenti di OWASP GenAI e ai feed di ricerca reputabili. Ricerca nuovamente ogni trimestre; le date di mitigazione obsolete sono bug. Quando si aggiornano i modelli, si esegue nuovamente la matrice completa - il tokenizer e la fine-tuning della sicurezza spostano il comportamento.

Budget del tempo dell'ingegnere per l'igiene del catalogo. Gli aggressori iterano; la tua checklist deve iterare più velocemente dei cicli di marketing, ma onestamente, senza promettere la perfezione.

Traccia la deriva delle regole nello stesso modo in cui tracci le CVE delle dipendenze: ogni nuova release del modello o connettore di strumenti guadagna un breve passaggio di regressione contro gli ultimi tre settimane di biglietti reali, non solo corpora sintetici. Preferisci piccoli pacchetti di regole versionati rispetto a un unico filtro monolitico che nessuno osa toccare. Quando una regola si attiva troppo spesso in produzione, demotela a warn-only con un biglietto - non cancellare silenziosamente la copertura durante un weekend di on-call.

16. Barriere di accessibilità e UX

Le interfacce di chat friendly con gli screen-reader espongono ancora istruzioni nascoste in etichette ARIA e testo di placeholder che gli aggressori possono manipolare. Revisiona quei campi nel tuo modello di minaccia. Le suggerimenti di autocomplete non devono prependere silenziosamente le direttive di sistema derivate dalla storia non attendibile.

I client mobili che memorizzano nella cache i bozzoli offline possono riprodurre stringhe ostili obsolete quando la connettività ritorna; cancella i bozzoli rischiosi dopo gli aggiornamenti delle politiche. I team di UX dovrebbero coordinarsi con la sicurezza prima di spedire "divertenti" prompt di Easter-egg che assomigliano a modelli di jailbreak.

Tabella di riferimento rapida

- Ambito : iniezione diretta e indiretta contro app e agenti. - Fonti principali: pagina OWASP + Prompt Injection Prevention Cheat Sheet. - Ruolo di PromptShield: modello deterministico + regressione di jailbreak su campioni. - Etichetta del set di regole: prompt-injection@2026-07-19.2. - Risultato: attività di hardening prioritarie - non un voto di pentest superato/non superato.

Riferimenti

- OWASP :2025 — Iniezione di prompt - OWASP LLM Prompt Injection Prevention Cheat Sheet

Open PromptShield

Aggiornato 2026-09-26 · checklist per il supporto alle decisioni · nessuna garanzia di copertura completa. Inoltre, si consiglia di consultare anche il testo completo dell' e la documentazione degli nonché di utilizzare strumenti come e di visitare il sito web di per ulteriori informazioni.