Votre system prompt n'est pas un contrôle de sécurité

Ce qui est inconfortable quand on sécurise une fonctionnalité LLM, c’est à quel point les défaillances sont ordinaires. Pas de zero-day, pas d’État-nation — juste une entrée à laquelle le système a fait confiance alors qu’il n’avait aucune raison de le faire.

La frontière a bougé

Le moindre privilège est le contrôle le moins cher dont vous disposez. Un agent qui ne peut faire que trois choses ne peut être manipulé pour en faire que trois. L’instinct d’accorder de larges capacités « pour être tranquille » est exactement à l’envers.

Le traitement des sorties est là où les vieilles vulnérabilités web reviennent habillées de neuf. Le texte du modèle devient le HTML, le SQL ou la commande shell de quelqu’un d’autre. Traitez-le comme l’entrée non fiable qu’il est, et les défenses familières s’appliquent toujours.

À quoi ressemble un vrai contrôle

La journalisation est le contrôle que personne n’apprécie jusqu’à la revue d’incident. Si vous ne pouvez pas rejouer précisément ce que le modèle a vu — system prompt, historique, contexte récupéré, appels d’outils — vous n’enquêtez pas, vous devinez.

Mesurer le rayon d’impact

L’instruction dangereuse vient rarement de l’utilisateur que vous surveillez. Elle vient de la page web que l’agent a récupérée, du document qu’il a consulté, du ticket qu’il a résumé. L’injection indirecte est le mode de défaillance qui surprend le plus les équipes.

L’injection de prompt n’est pas une liste de chaînes malveillantes à filtrer. C’est la conséquence structurelle du mélange d’instructions et de données dans le même canal. On ne filtre pas son chemin hors d’une conception qui invite la confusion en premier lieu.

L’exploit est rarement astucieux. Le correctif l’est rarement aussi. Tracez la frontière, accordez le minimum, journalisez assez pour pouvoir récupérer, et vous aurez traité la majorité de ce qui arrive réellement.