Un agent reçoit du texte non fiable et peut déclencher des outils puissants. Une instruction système comme « ignore les demandes dangereuses » ne constitue pas une barrière. La sécurité doit être appliquée avant l’appel du modèle, dans chaque outil et au moment de restituer le résultat.
Classer les données non fiables
Traitez comme non fiables messages utilisateur, pages Web, documents RAG, pièces jointes et résultats d’outils. Séparez clairement instructions, données et métadonnées. Limitez taille, formats, encodages et types de fichiers. Un document récupéré peut contenir une injection demandant au modèle de révéler des secrets ou d’appeler un outil.
Protéger les outils
Exposez le minimum d’outils nécessaire à chaque étape. Validez leurs arguments avec un schéma strict, puis vérifiez identité, tenant et permission dans l’exécuteur. Séparez lecture et écriture ; utilisez listes d’autorisation, délais, quotas et idempotence. Une action financière, une suppression ou un envoi externe doit demander une confirmation explicite.
Isoler les données
Appliquez les filtres d’accès avant la récupération RAG. Ne laissez jamais le modèle choisir seul un tenant ou un identifiant d’utilisateur. Masquez les secrets dans logs et callbacks, et évitez de transmettre variables d’environnement ou erreurs internes au modèle. Les sessions et checkpoints doivent être isolés par utilisateur.
Limiter et observer
Fixez nombre maximal d’étapes, tokens, temps et appels par outil. Détectez répétitions et arrêtez les boucles. Tracez décisions, outils et refus avec des identifiants corrélés, tout en minimisant les données. Construisez des tests d’injection indirecte, d’escalade d’autorisation, d’exfiltration et de résultats d’outils malformés.
FAQ
Un filtre de mots-clés suffit-il ?
Non. Il peut compléter d’autres contrôles, mais les attaques se reformulent facilement.
Les sorties structurées sécurisent-elles l’agent ?
Elles améliorent le format, pas l’autorisation ni la légitimité d’une action.
Faut-il laisser le modèle voir les secrets ?
Non. L’outil doit utiliser le secret côté serveur sans l’insérer dans le contexte.
Pipeline de validation avant l’agent
Ne concaténez jamais directement l’entrée utilisateur dans un message système. Séparez les rôles et contrôlez la taille :
from pydantic import BaseModel, Field, field_validator
from langchain_core.messages import HumanMessage, SystemMessage
class UserRequest(BaseModel):
text: str = Field(min_length=1, max_length=4000)
@field_validator("text")
@classmethod
def reject_control_chars(cls, value: str) -> str:
if any(ord(char) < 32 and char not in "\n\t" for char in value):
raise ValueError("caractère de contrôle interdit")
return value.strip()
request = UserRequest(text=raw_input)
messages = [
SystemMessage("Réponds uniquement à partir des documents autorisés."),
HumanMessage(request.text),
]Une détection de mots-clés ne suffit pas contre l’injection de prompt. Protégez surtout les capacités : outils en liste blanche, arguments typés, identités propagées jusqu’aux sources et validation humaine avant écriture. Marquez les documents récupérés comme données non fiables et demandez au modèle d’ignorer leurs instructions. Testez des attaques indirectes placées dans un PDF, une page web et les métadonnées d’un document.