Architecture principale • Taxonomie des attaques • Naïf vs Durci • Démarrage rapide • Feuille de route

🎯 Vue d'ensemble exécutive

Les agents modernes propulsés par LLM exécutent des actions privilégiées : interroger des bases de données internes, lire des systèmes de fichiers et interagir avec des API backend. Chaque action est une frontière où le prompt d'un attaquant peut déclencher une exécution non autorisée.

⚠️ Point d'architecture clé :
La vulnérabilité réside rarement dans les poids du LLM lui-même. Elle prospère à la frontière de confiance entre la demande d'intention du modèle et le backend applicatif qui l'exécute sans validation.

Tout comme l'injection SQL provenait de la concaténation de chaînes non paramétrées plutôt que du moteur de base de données lui-même, les failles de député confus dans les LLM surviennent lorsque le code applicatif fait aveuglément confiance aux arguments d'outil d'un agent.

🏛️ Architecture principale

⚔️ Les deux paradigmes d'outils

Les deux outils exposent une signature de fonction identique à l'agent LLM (get_user(username: str)). Le modèle ne peut pas déterminer avec quelle version d'outil il interagit.

🗃️ Taxonomie des attaques et suite de tests

Le banc d'essai exerce 5 catégories clés de vulnérabilités définies dans attacks.py :

🔬 Backend simulé et configuration d'injection implantée

L'environnement est soutenu par des dataclasses Python pures et déterministes dans testbed/fake_data.py :

💡 Pourquoi la bio d'Alice est empoisonnée : Cela modélise un scénario réaliste d'injection indirecte de prompt où un attaquant n'a pas besoin de privilèges élevés. Il lui suffit de contrôler des données qu'un outil récupère (par exemple, une bio de profil public), en attendant qu'un agent les lise lors d'une recherche de routine.

⚖️ Inspection de vérité terrain et verdict "INCERTAIN"

Noter des réponses LLM en texte libre est fondamentalement non déterministe. Un modèle peut esquiver, divulguer partiellement des informations ou refuser d'appeler un outil entièrement.

Distinguer INCERTAIN de BLOQUÉ est crucial : cela évite de prétendre faussement qu'un backend d'outil est sécurisé alors que l'attaque n'a simplement jamais atteint la couche d'outil.

📊 Modèle de données et structure des répertoires

🚀 Démarrage rapide

1. Installation

Clonez le dépôt et configurez les dépendances avec uv :

2. Configuration de l'environnement

Créez un fichier .env dans le répertoire racine :

3. Exécution des évaluations d'attaques

Exécutez les attaques contre l'une ou l'autre version d'outil via le harnais de test :

📑 Rapports détaillés et conclusions

• 📖 V1-RESULTS.md — Analyse complète des 5 attaques avec diagrammes de résultats, itérations de prompts et enseignements de sécurité.
• 🔬 PHASE-6-REPORT.md — Rapport approfondi sur la validation du harnais de test, les contraintes API et le comportement du modèle.
• 📓 BUILD-JOURNAL.md — Journal des décisions d'ingénierie étape par étape et processus de réflexion.

🛡️ Portée du projet et non-objectifs (v1)

• Backend simulé par conception : Les dataclasses Python pures évitent les configurations complexes de Docker/sandboxing pour garder l'accent strictement sur la sécurité des outils agentiques.
• Test de prompts vs. internes du modèle : Évalue le comportement externe des prompts et l'autorisation des outils, pas l'ajustement fin des poids du modèle.
• Exploration empirique : Sert de prototype éducatif rigoureux plutôt que de scanner lourd de red-teaming d'entreprise.

📈 Avancement des phases

• Phase 0 — Vérifié la boucle d'appel de fonction Gemini 3.6 Flash de bout en bout.
• Phase 1 — Défini les métriques de succès des attaques, les secrets de vérité terrain et le périmètre du backend simulé.
• Phase 2 — Implémenté les modèles de données immuables (FakeUser, AttackAttempt, AttackResult).
• Phase 3 — Formulé les règles de défense naïves et durcies.
• Phase 4 — Connecté les outils à la boucle API LLM en direct et confirmé le comportement de base.
• Phase 5 — Rédigé la suite d'attaques multi-catégories avec vecteurs d'injection indirecte implantés.
• Phase 6 — Automatisé l'exécution du runner par lots, le support multi-tours et la notation des réponses.
• Phase 7 — Vérification ponctuelle des résultats ambigus (revue de classification unclear).
• Phase 8 — Généré des comptes rendus d'évaluation complets, des tableaux récapitulatifs et des graphiques visuels.