Prompt injection : protéger aussi l'action qui vient après

Un agent de gestion client traite un document fourni par un tiers. Le document contient une instruction cachée : supprimer la fiche du client concerné. L'agent dispose de trois outils.

• read_customer()
• export_customer()
• delete_customer()

Si le modèle suit l'instruction, qu'est-ce qui empêche l'appel à delete_customer() d'aboutir ? La réponse se répartit sur plusieurs couches, chacune avec son rôle et ses limites.

OWASP qualifie ce scénario de prompt injection indirecte : l'instruction provient d'un contenu externe traité par le modèle, et l'impact peut s'étendre aux fonctions que le modèle peut déclencher.^[1]

Couche prompt

Instructions système claires, séparation marquée entre consignes et contenus non fiables, analyse des entrées, guardrails en entrée et en sortie : ces mesures réduisent la probabilité que le modèle suive l'instruction hostile. Elles restent utiles et devraient être en place.

Leur limite est connue : OWASP indique qu'aucun mécanisme opérant uniquement dans le modèle n'offre de prévention infaillible.^[1]

Couche capacités

Première question hors du modèle : l'agent a-t-il besoin de delete_customer() ? Si sa mission est de répondre à des demandes, l'outil de suppression ne devrait pas lui être exposé. OWASP, dans sa description de l'Excessive Agency, recommande de limiter les fonctionnalités exposées aux extensions et outils à ce qui est nécessaire.^[2]

Un outil absent ne peut pas être appelé, quelle que soit la qualité de l'injection.

Couche permissions

Supposons que l'agent n'expose que read_customer(). Que permet l'identité utilisée par cet outil en aval ? Si le compte de service de l'API a les droits de suppression, un autre chemin (un outil générique d'appel HTTP, un bug du serveur d'outils) pourrait les exploiter. OWASP recommande d'appliquer le moindre privilège aux permissions accordées en aval.^[2]

Le guide OWASP consacré à MCP traite le même problème sous l'angle des tokens trop larges détenus par les serveurs d'outils.^[3]

Couche autorisation

Certains agents ont légitimement besoin d'outils sensibles. La question devient contextuelle : cette suppression, demandée par cet agent pour cet utilisateur, sur cette fiche, maintenant, est-elle permise ? Une politique peut par exemple autoriser la suppression uniquement pour des fiches marquées « doublon » et refuser toutes les autres, sans qu'aucune instruction du prompt n'intervienne dans la décision.

Couche enforcement

Une décision n'a d'effet que si un composant bloque physiquement l'appel refusé : un proxy devant le serveur d'outils, une passerelle d'API, le service métier lui-même. Ce composant doit se trouver sur un chemin que l'agent ne peut pas éviter.

Validation humaine

Pour une sélection d'actions à fort impact (suppression définitive, paiement, envoi de données vers l'extérieur), une validation humaine explicite ajoute une barrière indépendante du modèle. La demander partout produirait l'effet inverse : des validateurs qui approuvent sans lire. La liste des actions concernées doit être fixée par la politique, pas par l'agent.

Runtime

Si l'agent peut exécuter du code généré, l'injection peut viser un autre chemin : écrire un script qui appelle directement l'API avec un token trouvé dans l'environnement. Aucune des couches précédentes ne voit ce chemin s'il ne passe pas par un outil. Isoler l'environnement d'exécution, retirer les credentials inutiles et contraindre les accès réseau et fichiers ferment cette voie.

Architecture cible

Dans cette chaîne, le contenu non fiable peut influencer ce que l'agent demande. Il n'influence ni la politique, ni le composant qui l'applique, ni les droits de l'identité en aval.