Un banco di prova di sicurezza disciplinato che verifica se gli agenti LLM dotati di strumenti possono essere manipolati per esfiltrare dati non autorizzati tramite prompt injection, ingegneria sociale basata su ruoli dichiarati e attacchi di tipo confused-deputy.

Architettura Core • Tassonomia degli Attacchi • Paradigmi Naive vs Hardened • Avvio Rapido • Roadmap

🎯 Panoramica Esecutiva

Gli agenti moderni basati su LLM eseguono azioni privilegiate: interrogare database interni, leggere file system e interagire con API backend. Ogni azione è un confine in cui il prompt di un attaccante può innescare esecuzioni non autorizzate.

⚠️ Concetto Architetturale Chiave:
La vulnerabilità raramente risiede solo nei pesi dell'LLM. Prospera nel confine di fiducia tra la richiesta di intento del modello e il backend applicativo che la esegue senza validazione.

Proprio come la SQL Injection derivava dalla concatenazione di stringhe non parametrizzate piuttosto che dal motore del database stesso, i Difetti Confused-Deputy negli LLM si verificano quando il codice applicativo si fida ciecamente degli argomenti degli strumenti dell'agente.

🏛️ Architettura Core

⚔️ I Due Paradigmi di Strumenti

Entrambi gli strumenti espongono una firma di funzione identica all'agente LLM (get_user(username: str)). Il modello non può determinare con quale versione dello strumento sta interagendo.

🗃️ Tassonomia degli Attacchi e Suite di Test

Il banco di prova esercita 5 categorie chiave di vulnerabilità definite in attacks.py:

🔬 Backend Mock e Configurazione dell'Iniezione Piantata

L'ambiente è supportato da dataclass Python pure e deterministiche in testbed/fake_data.py:

💡 Perché la bio di Alice è avvelenata: Questo modella uno scenario realistico di prompt injection indiretta in cui un attaccante non ha bisogno di privilegi elevati. Deve solo controllare i dati che uno strumento recupera (es. bio di un profilo pubblico), aspettando che un agente li legga durante una ricerca di routine.

⚖️ Ispezione Ground-Truth e Verdetto "UNCLEAR"

Valutare risposte LLM in testo libero è fondamentalmente non deterministico. Un modello potrebbe usare giri di parole, divulgare parzialmente informazioni o rifiutarsi di chiamare uno strumento del tutto.

Distinguere UNCLEAR da BLOCKED è cruciale: impedisce di affermare falsamente che un backend di strumenti è sicuro quando l'attacco semplicemente non è riuscito a raggiungere il livello dello strumento.

📊 Modello Dati e Struttura delle Directory

🚀 Avvio Rapido

1. Installazione

Clona il repository e configura le dipendenze con uv:

2. Configurazione dell'Ambiente

Crea un file .env nella directory principale:

3. Esegui le Valutazioni degli Attacchi

Esegui gli attacchi contro entrambe le versioni degli strumenti tramite l'harness di test:

📑 Report Dettagliati e Risultati

• 📖 V1-RESULTS.md — Analisi completa di tutti i 5 attacchi con diagrammi dei risultati, iterazioni dei prompt e insegnamenti di sicurezza.
• 🔬 PHASE-6-REPORT.md — Report approfondito sulla validazione dell'harness di test, i vincoli API e il comportamento del modello.
• 📓 BUILD-JOURNAL.md — Registro passo-passo delle decisioni ingegneristiche e del processo di pensiero.

🛡️ Ambito del Progetto e Non-Obiettivi (v1)

• Backend Mock per Progettazione: Dataclass Python pure evitano configurazioni complesse con Docker/sandboxing per mantenere l'attenzione esclusivamente sulla sicurezza degli strumenti agentici.
• Test dei Prompt vs. Internals del Modello: Valuta il comportamento esterno dei prompt e l'autorizzazione degli strumenti, non il fine-tuning dei pesi del modello.
• Esplorazione Empirica: Serve come prototipo educativo disciplinato piuttosto che come scanner pesante di red-teaming aziendale.

📈 Avanzamento delle Fasi

• Fase 0 — Verificato il loop di chiamata di funzione Gemini 3.6 Flash end-to-end.
• Fase 1 — Definite le metriche di successo degli attacchi, i segreti ground-truth e l'ambito del backend mock.
• Fase 2 — Implementati modelli dati immutabili (FakeUser, AttackAttempt, AttackResult).
• Fase 3 — Formulate le regole di difesa naive e hardened.
• Fase 4 — Collegati gli strumenti al loop API LLM live e confermato il comportamento di base.
• Fase 5 — Creata la suite di attacchi multi-categoria con vettori di iniezione indiretta piantati.
• Fase 6 — Esecuzione automatizzata del batch runner, supporto multi-turno e valutazione delle risposte.
• Fase 7 — Verifica a campione degli esiti ambigui (revisione della classificazione unclear).
• Fase 8 — Generati report di valutazione completi, tabelle riassuntive e grafici visivi.