The System Prompt Is the Attack Surface: How LLM Agent Configuration Shapes Security and Creates Exploitable Vulnerabilities

1. Il Problema

Gli assistenti email basati su Large Language Models (LLM) stanno diventando agenti autonomi che prendono decisioni di sicurezza critiche (es. bloccare o permettere link) senza intervento umano. Sebbene la ricerca si sia concentrata sulla selezione del modello o sugli attacchi di "prompt injection", manca uno studio sistematico su come la configurazione della prompt di sistema (l'istruzione che definisce la personalità e i criteri decisionali dell'agente) influenzi la capacità di rilevare il phishing.
Il rischio è asimmetrico: un falso negativo (mancato rilevamento) porta al furto di credenziali o compromissione dell'account, mentre un falso positivo blocca email legittime. L'ipotesi convenzionale è che la sicurezza dipenda principalmente dall'architettura del modello; questo lavoro dimostra invece che la configurazione della prompt è una variabile di sicurezza di primo ordine, capace di variare le prestazioni da quasi perfette a quasi nulle.

2. Metodologia: PhishNChips

Gli autori hanno sviluppato PhishNChips, un benchmark su larga scala composto da 220.000 valutazioni strutturate.

• Dataset: Un corpus bilanciato di 2.000 email (1.000 phishing, 1.000 legittime).
  • Email Phishing: Generate da un modello LLM (Gemini 3 Flash) utilizzando URL reali e dannosi da feed di threat intelligence (PhishTank, OpenPhish). Sono progettate per essere difficili da rilevare, utilizzando hosting di fiducia (es. Google Docs, GitHub Pages). Include un sottoinsieme di 73 email di "Infrastructure Phishing", dove l'attaccante registra un dominio che corrisponde sia all'indirizzo del mittente che all'URL del link, annullando l'indicatore di disallineamento dei domini.
  • Email Legittime: Generate con regole anti-phishing rigorose (nessuna urgenza, nessun richiesta di credenziali). Il 98,4% di queste ha un allineamento tra dominio del mittente e dominio dell'URL (una caratteristica che influenza i risultati del benchmark).
• Modelli: 11 modelli LLM di 5 provider diversi (Google, OpenAI, Anthropic, Meta, Mistral, DeepSeek, Qwen), selezionati per scenari di agenti autonomi reali (modelli veloci ed economici).
• Strategie di Prompt: 10 strategie di prompt di sistema, incluse:
  • 6 strategie "core" che variano la personalità (da "sicurezza prima" a "efficienza prima").
  • 3 strategie ottimizzate basate su segnali specifici (es. controllo della coerenza dominio-mittente/URL).
  • 1 strategia "infra_aware" progettata per recuperare la robustezza contro l'infrastructure phishing.
• Metriche:
  • Recall: Percentuale di phishing rilevati.
  • FPR (False Positive Rate): Percentuale di email legittime bloccate erroneamente.
  • Safetility: Una nuova metrica composita che penalizza severamente i FPR superiori a una soglia operativa (τ = 10%), riflettendo la realtà deployabile.

3. Contributi Chiave

1. Il Prompt come Variabile di Sicurezza: Dimostrazione che la variazione delle prestazioni di sicurezza all'interno dello stesso modello (cambiando solo la prompt) supera spesso la variazione tra modelli diversi.
2. Ottimizzazione Basata sui Segnali e Fragilità: Sviluppo di strategie che raggiungono un recall fino al 93,7% con un FPR del 3,8%, ma che creano una superficie di attacco sfruttabile tramite "inversione del segnale".
3. Paradosso della Specificità dell'Istruzione: Dimostrazione che istruzioni troppo specifiche possono degradare modelli già capaci, sostituendo il ragionamento multi-segnale con una dipendenza da un singolo segnale sfruttabile.
4. Safetility: Introduzione di una metrica che combina recall e costi operativi (FPR), rivelando che la maggior parte delle configurazioni non è deployabile nonostante buoni punteggi di recall isolati.
5. Limite della Difesa Solo-Prompt: Evidenza che contro l'infrastructure phishing, i prompt da soli raggiungono un tetto di efficacia a causa della mancanza di "ground truth" (dati esterni) per verificare la reputazione dei domini.

4. Risultati Principali

A. L'Impatto della Prompt di Sistema

La configurazione della prompt determina l'intervallo operativo di sicurezza.

• Per il modello GPT-4o-mini, il tasso di bypass del phishing varia dal <1% (con una persona "security-first") al 97% (con una persona "efficiency-first").
• Le strategie core non riescono a bilanciare sicurezza e usabilità: nessuna supera lo 0,5% di Safetility.

B. Ottimizzazione e Generalizzazione Cross-Modello

Le strategie basate su segnali (es. sender_url_match, che controlla la coerenza tra dominio del mittente e URL) hanno portato a miglioramenti drastici per modelli con baseline deboli (es. GPT-4o-mini è passato dal 32,8% al 93,7% di recall). Tuttavia, questo guadagno è distribuzione-dipendente: funziona bene nel benchmark perché il 98,4% delle email legittime ha domini allineati, ma fallisce su email legittime con link cross-domain.

C. Il Collasso dell'Infrastructure Phishing (Inversione del Segnale)

Quando gli attaccanti soddisfano il segnale privilegiato (registrando un dominio che corrisponde all'URL), le strategie ottimizzate collassano:

• Il recall crolla fino al 30-40% per molti modelli (es. GPT-4o-mini scende da 93,7% a 30,1%).
• Analisi delle risposte: Il 98% delle risposte che bypassano il filtro cita esplicitamente la "coerenza del dominio" come prova di legittimità. I modelli eseguono fedelmente l'istruzione, ma l'assunzione dell'istruzione è falsa.
• Paradosso dell'Obbedienza: I modelli che seguono le istruzioni più fedelmente (es. GPT-4o-mini) sono i più vulnerabili all'inversione del segnale, mentre modelli con una "disposizione alla sicurezza" intrinseca (es. Claude, Mistral) mostrano una "non conformità benefica", ignorando parzialmente l'istruzione stretta per applicare un ragionamento di sicurezza più ampio.

D. Disposizione Pre-Deploy e Recupero

Gli autori identificano tre categorie di modelli basate su come eseguono le istruzioni:

1. Calibrati (es. GPT-4o-mini, Gemini): Eseguono le istruzioni con precisione. Possono essere ottimizzati per alte prestazioni ma sono fragili se l'istruzione è sbagliata.
2. Amplificatori di Sicurezza (es. Claude, Mistral): Amplificano le istruzioni di sicurezza, portando a FPR catastrofici se viene data loro una "permesso di override" (es. infra_aware porta a un FPR del 67,6% su Claude Haiku).
3. Autosufficienti (es. Qwen 3): Hanno già un ragionamento robusto e le istruzioni aggiuntive possono degradarne le prestazioni.

La strategia infra_aware (che permette di bloccare anche se i domini corrispondono, se ci sono altri segnali sospetti) recupera la robustezza, ma il costo in FPR varia di un ordine di grandezza tra i modelli (da +2,6% su Gemini 2.5 Flash a +65% su Claude Haiku).

E. Il Tetto della Difesa

L'analisi avversariale su 10 campioni reali di infrastructure phishing mostra che anche la migliore configurazione prompt-modello lascia passare il 90% degli attacchi. Il problema non è l'istruzione, ma l'informazione: i modelli non hanno accesso a dati esterni (età del dominio, WHOIS, feed di intelligence) per verificare la legittimità di un dominio appena registrato.

5. Significato e Implicazioni

• Il Prompt è una Superficie di Attacco: La progettazione della prompt non è solo un dettaglio di deployment, ma una variabile di sicurezza critica. Ottimizzare per un segnale specifico crea una vulnerabilità prevedibile e sfruttabile.
• Necessità di Co-Ottimizzazione: Non esiste una "migliore prompt" universale. La scelta del modello e della prompt deve essere co-ottimizzata in base alla "disposizione pre-deploy" del modello.
• Limiti dell'Approccio Solo-Prompt: Per difendersi da attacchi sofisticati (infrastructure phishing), l'ingegneria dei prompt non è sufficiente. È necessaria l'augmentazione con strumenti (tool-augmentation) come lookup WHOIS, sandboxing URL e feed di intelligence per fornire ai modelli dati di verità oggettiva.
• Metrica Safetility: Le organizzazioni dovrebbero adottare metriche che penalizzino i falsi positivi operativi, poiché un alto recall con un alto FPR rende l'agente inutilizzabile nella pratica.

In sintesi, il paper dimostra che l'ottimizzazione delle LLM per la sicurezza è un gioco a somma zero dove la precisione contro le minacce comuni crea vulnerabilità strutturali contro avversari adattivi, e che la soluzione richiede un approccio ibrido che combina prompting intelligente, selezione del modello e integrazione di strumenti esterni.