Conviction

Le prompt ne doit pas porter seul la frontière de sécurité

Un system prompt peut définir le rôle d’un agent, ses consignes et les actions qu’il devrait éviter. Il reste interprété par le même système probabiliste qui traite des données externes potentiellement hostiles.

Une action irréversible ne devrait donc pas dépendre du seul respect d’une instruction textuelle.

Ce que le prompt fait bien

Le prompt cadre le rôle de l’agent, précise sa tâche, décrit les limites attendues et oriente son comportement. Un prompt bien construit améliore nettement la qualité et la prévisibilité des réponses. Il agit sur ce que le modèle a tendance à faire.

Quand l’agent dispose d’outils

Instruction système : « Read customer records. Never delete them. » L’outil mis à disposition expose pourtant read(), update() et delete(), et l’identité qu’il utilise en aval possède les droits correspondants.

Instruction et fonctions exposées

Le prompt demande de lire sans supprimer. L’outil expose pourtant read, update et delete, et son identité en aval possède les droits des trois opérations.

L’instruction interdit delete(). L’outil et ses droits le rendent possible.

La question de sécurité ne se limite pas à savoir si l’agent a reçu l’ordre de ne pas appeler delete(). L’architecture doit aussi expliquer pourquoi delete() est techniquement disponible pour cette tâche.

Deux chemins pour la même demande

Instruction ou contrôle externe

Premier chemin : l’instruction « Do not delete » est dans le contexte ; l’agent peut malgré tout émettre un tool call DELETE qui s’exécute. Second chemin : la requête de l’agent passe par une politique d’autorisation qui renvoie Deny ; l’action est bloquée.

L’instruction influence le comportement. Le contrôle externe limite l’effet possible.

Dans le premier chemin, seule l’obéissance du modèle sépare la demande de la suppression. Dans le second, la requête traverse une politique évaluée hors du raisonnement du modèle : une instruction contournée ne change pas la décision.

Ce que documente OWASP

OWASP décrit l’injection de prompt comme une vulnérabilité capable de faire dévier le comportement d’un LLM, de façon directe ou indirecte, par exemple via un fichier ou un site web lu par le modèle. L’impact peut aller jusqu’à l’accès non autorisé à des fonctions ou l’exécution d’actions dans des systèmes connectés.[1]

OWASP indique qu’aucun mécanisme de prévention infaillible n’est connu à l’intérieur du modèle lui-même, et recommande plusieurs mesures : privilèges minimaux, validation des sorties, approbation humaine des opérations à risque, séparation des contenus non fiables.[1]

La fiche Excessive Agency recommande en outre d’implémenter l’autorisation dans les systèmes en aval et d’appliquer une médiation complète (complete mediation), plutôt que de laisser le LLM juger si l’action est autorisée.[2]

Conséquences d’architecture

Retirer les fonctions inutiles
Un outil de consultation n’expose ni modification ni suppression.
Réduire les droits en aval
Le compte utilisé par l’outil ne détient que les opérations requises par la tâche.
Approuver explicitement les actions à fort impact
Une suppression ou un envoi externe passe par une validation hors du modèle.

Là où les guardrails restent utiles

Les défenses au niveau du prompt réduisent les demandes dangereuses, détectent des motifs suspects, contraignent le comportement attendu et arrêtent certaines attaques avant les étapes suivantes. Notre position relève de la défense en profondeur : elles gardent leur place, sans porter seules la frontière pour les actions sensibles.

Contenus associés

Sources

Sources vérifiées le

  1. [1]

    Framework

    OWASP GenAI Security Project

    LLM01:2025 Prompt Injection (lien externe, nouvel onglet)

    Fiche OWASP sur l'injection de prompt directe et indirecte, ses impacts et les mesures d'atténuation recommandées.

    Vérifié le

  2. [2]

    Framework

    OWASP GenAI Security Project

    LLM06:2025 Excessive Agency (lien externe, nouvel onglet)

    Fiche OWASP sur l'agentivité excessive : fonctionnalités, permissions et autonomie excessives, et mesures d'atténuation dont la médiation complète.

    Vérifié le

Appliquer ce principe à une architecture réelle

Nous pouvons partir d’un agent, d’un outil MCP ou d’une action sensible pour identifier la frontière de contrôle et vérifier comment elle est réellement appliquée.

Étudier mon architecture