{"id":12486,"date":"2026-10-05T08:51:24","date_gmt":"2026-10-05T08:51:24","guid":{"rendered":"https:\/\/radicalbit.ai\/?p=12486"},"modified":"2026-10-05T09:05:33","modified_gmt":"2026-10-05T09:05:33","slug":"prompt-injection-nei-sistemi-genai-impatto-e-difesa-dei-workflow-agentici","status":"publish","type":"post","link":"https:\/\/radicalbit.ai\/it\/resources\/blog\/prompt-injection-nei-sistemi-genai-impatto-e-difesa-dei-workflow-agentici\/","title":{"rendered":"Prompt Injection nei sistemi GenAI: impatto e difesa dei workflow agentici"},"content":{"rendered":"\n

La prompt injection<\/strong> \u00e8 una tecnica di attacco che sfrutta un limite strutturale dei modelli linguistici: l’incapacit\u00e0 di distinguere tra le istruzioni da eseguire e i dati da elaborare.<\/p>\n\n\n\n

Per un LLM tutto ci\u00f2 che entra nel contesto ha lo stesso peso:<\/strong> il prompt di sistema sviluppato da chi ha creato l’applicazione, la domanda dell’utente, un documento aziendale estratto via RAG e la risposta di un tool esterno. Poich\u00e9 nessun input possiede un livello di privilegio superiore agli altri, qualsiasi frase formulata come comando pu\u00f2 essere trattata come un’istruzione legittima. Da l\u00ec, l’attaccante pu\u00f2 scavalcare le regole, accedere a informazioni riservate o far compiere all’agente azioni non autorizzate.<\/p>\n\n\n\n

Non si tratta del difetto di un singolo modello, bens\u00ec del funzionamento stesso della GenAI.<\/strong> Per questo motivo, la difesa deve essere progettata a livello architetturale<\/strong>, non limitandosi a scrivere prompt pi\u00f9 sicuri.<\/p>\n\n\n\n

La prompt injection come propriet\u00e0 architetturale degli LLM<\/h2>\n\n\n\n

Un’applicazione web tradizionale separa il codice dai dati:<\/strong> una query parametrizzata neutralizza la SQL injection perch\u00e9 il database sa cos’\u00e8 istruzione e cos’\u00e8 input utente. Un LLM non ha questo confine<\/strong>: system prompt, messaggio dell’utente, contenuto di un documento recuperato da un sistema RAG e output di un tool arrivano al modello come un unico flusso di token. <\/strong>Sebbene tecniche come la instruction hierarchy<\/strong> insegnino al modello a dare priorit\u00e0 alle istruzioni di sistema, si tratta di una preferenza statistica e non di un blocco di sicurezza garantito.<\/p>\n\n\n\n

Questo spiega perch\u00e9 la prompt injection<\/strong> occupa da due edizioni consecutive (2023 e 2025) la posizione LLM01 nella OWASP Top 10 for LLM Applications<\/a>, e perch\u00e9 non esiste una patch definitiva.\u00a0<\/p>\n\n\n\n

Non si tratta di un difetto di implementazione di un vendor specifico: \u00e8 il prezzo dell’interfaccia in linguaggio naturale<\/strong>. Le difese efficaci non eliminano la vulnerabilit\u00e0, la contengono. Riducono il numero di istruzioni ostili che arrivano al modello e, soprattutto, il danno che possono fare quando ci arrivano comunque. Chi progetta partendo dal presupposto che qualche payload passer\u00e0 sempre costruisce sistemi pi\u00f9 robusti di chi cerca il filtro perfetto.<\/p>\n\n\n\n

La conseguenza pratica per chi progetta architetture enterprise<\/strong> \u00e8 che ogni input non fidato che raggiunge un LLM va trattato come codice potenzialmente eseguibile<\/strong>, non come testo.<\/p>\n\n\n\n

Injection diretta vs indiretta: vettori d’attacco a confronto<\/h2>\n\n\n\n

Per comprendere le superfici d’attacco a cui sono esposti gli LLM, \u00e8 fondamentale distinguere tra due principali vettori d’ingresso:<\/p>\n\n\n\n