Les agents LLM (Claude avec tools, GPT-4 functions, LangChain, AutoGen) donnent à un modèle langage la capacité d'exécuter du code, d'appeler des APIs, de lire des fichiers, de modifier une base. Si l'architecture n'est pas sécurisée dès le départ, l'agent peut escalader ses privilèges, accéder à des ressources interdites, ou contourner ses propres garde-fous.
Cet audit couvre la phase de conception : comment valider avant exécution, comment isoler les contextes, comment constrainer l'orchestration pour éviter que tout déraille.
Tool Use Validation
L'agent génère un appel fonction. Si cet appel n'est pas validé avant exécution, l'agent peut invoquer des outils non autorisés, avec des paramètres malveillants, ou halluciner des fonctions qui n'existent pas.
- Agent appelle outil sans permission
- Injection SQL via paramètres non validés
- Hallucination : fonction n'existe pas
- Exécution directe sans checklist
Les LLM hallucinant sur ce qu'ils peuvent faire (même avec Anthropic Claude), validation stricte est essentielle. Pas de fallback sur "il a sûrement raison".
- Whitelist stricte des fonctions
- Validation schéma JSON
- Type checking paramètres
- Audit logging chaque invocation
Escalade de privilèges
L'agent commence avec un accès restreint. Par manipulation du prompt ou hallucination, il se convainc qu'il a accès à des outils supplémentaires. Exemple : agent limité à "chat" hallucine qu'il peut appeler "delete_user_account" ou "modify_database".
- Hallucination de permission élevée
- Chaîne requêtes contournant restrictions
- Injection dans wrapper d'outils
- Confusion entre contexte utilisateur
Chaque agent doit avoir accès qu'aux outils strictement nécessaires. Pas de "on lui donne tout et on espère". Isolation par rôle/tenant.
- Isoler par rôle / tenant
- Permissions déclaratives & validées
- Audit exhaustif chaque action
- Human-in-the-loop actions irréversibles
Memory Poisoning
L'agent stocke un contexte (historique conversation, données utilisateur, états). Attaquant injecte des données malveillantes dans ce contexte. Exemple : chat RAG stocke messages en DB → attaquant injecte doc malveillant → l'agent le traite comme contexte légitime → hallucine instructions d'attaque.
- Contexte utilisateur compromis
- Historique conversation altéré
- Documents RAG injectés
- État d'agent DB manipulé
Training poisoning est une attaque sur le corpus d'entraînement. Memory poisoning affecte le contexte runtime de l'agent. Plus ciblée mais toujours critique.
- Isolation contexte par utilisateur
- Validation source contexte
- Size limits (prev. bloat)
- Expiration TTL (stale data)
Orchestration non contrainte
L'agent itère librement : call outil → reçoit résultat → décide prochaine action. Aucune limite sur le nombre d'itérations, actions parallèles, dépendances outils. L'agent peut rentrer en boucle infinie, appeler le même outil 1000 fois, ou créer une chaîne d'appels dangereuse.
- Boucle infinie → coûts API explosent
- Chaîne appels non validée
- Dépendances circulaires entre outils
- Race conditions multi-threads
Confiance aveugle dans les décisions de l'agent sans supervision. C'est un choix architectural : autour-boucle ou boucle-fermée ?
- Max iterations limit (ex: 5 appels)
- Max tokens par action (prev. verbosity)
- Timeout stricte par appel
- Human-in-the-loop critiques
Audit architecture : Avant de déployer un agent : vérifiez tool validation, permissions par rôle, contraintes orchestration (max iterations, timeouts). Une faille architecturale est exponentiellement plus coûteuse à corriger en prod.
Testing : Fiches de test (checklist) pour chaque pattern sécurisé. Rejouer les scénarios d'attaque : hallucination outil, escalade privilège, poisoning contexte.
Audit complet : Consultez aussi les audits LLM (vulnérabilités modèle) et production (monitoring) pour une stratégie end-to-end.
← Retour accueil