L'injection de prompts est un problème d'autorisations

On présente souvent l’injection de prompts comme un problème de modèle : il faudrait mieux repérer les mauvaises instructions. C’est nécessaire. Ce n’est pas suffisant.

Un agent qui lit des e-mails, des pages web, des documents, des tickets ou des dépôts rencontrera du texte qui essaie de le diriger. L’attaque n’est plus forcément un vulgaire « ignore les instructions précédentes ». Elle ressemble de plus en plus à de l’ingénierie sociale : urgence, autorité apparente, processus métier plausible et lien serviable. OpenAI observe ce glissement et explique que filtrer les entrées ne suffit pas à limiter l’impact d’une manipulation réussie.¹

Ma conclusion est simple : l’injection de prompts est d’abord un problème d’autorisations.

La question n’est pas seulement de savoir si l’agent croit une phrase hostile. C’est ce qu’il peut faire ensuite.

S’il peut seulement résumer une page, l’échec est gênant. S’il peut envoyer des données à un nouveau destinataire, approuver un paiement, modifier un déploiement ou exécuter du code dans un environnement privilégié, le même échec a un coût.

Le modèle n’est pas la frontière de sécurité

Dans une même fenêtre de contexte, un modèle ne possède pas de moyen cryptographique fiable de séparer l’intention de l’utilisateur des instructions hostiles cachées dans le contenu traité. Marquer la provenance et apprendre une hiérarchie des instructions aide. Cela ne transforme pas un texte arbitraire en canal d’autorité fiable.

La frontière dure doit donc se situer entre une action proposée et le droit de l’exécuter.

Le test que j’applique à chaque capacité agentique est le suivant :

Si un document non fiable change l’avis de l’agent, quelle est la pire action qu’il peut accomplir avant qu’un humain ou une politique ne l’arrête ?

Si la réponse est « tout ce que peut faire l’utilisateur », il n’y a pas de garde-fous. Il y a une extension de navigateur avec un problème de négociation d’otages.

L’OWASP Top 10 for Agentic Applications 2026 traite cette catégorie de risques parce que les agents planifient, agissent et décident à travers des workflows, au lieu de simplement produire du texte.² Le risque n’est pas une phrase étrange. C’est une boucle capable de la faire franchir une frontière de confiance.

Séparer quatre éléments

Le contenu non fiable. Corps d’e-mail, pages web, documents récupérés, commentaires et sorties d’outils sont des données, pas des instructions. Un lien extrait n’est pas une destination approuvée. Un texte qui prétend autoriser une action ne l’autorise pas.

L’intention. La demande utilisateur définit le but avant que l’agent ne parte explorer. « Rechercher des fournisseurs et préparer une comparaison » n’autorise ni prise de contact, ni création de compte, ni transfert de notes internes. Un plan rend l’interprétation visible ; ce n’est pas du théâtre.

L’autorité. Les outils ont besoin de droits étroits et typés. Lire n’est pas transférer. Rédiger n’est pas déployer. Écrire, envoyer, acheter, supprimer et exécuter sont des verbes différents. Traitez-les comme tels. Anthropic décrit l’agent comme une boucle qui planifie, agit, observe et s’ajuste, tout en maintenant le contrôle humain là où le jugement compte.³ Le bon point de contrôle est avant une transition conséquente : nouveau destinataire externe, action impliquant un secret, écriture irréversible ou extension de périmètre.

La vérification. La couche d’action doit contrôler les faits que le modèle ne peut pas s’auto-certifier : destinataire autorisé, domaine approuvé, plafond de dépense, suppression ou publication, correspondance avec le plan déclaré.

Le modèle propose. Le moteur de politiques peut refuser. Ce n’est pas glamour, donc cela fonctionne.

Trois règles à déployer maintenant

Rendez l’exfiltration volontairement pénible. Aucun outil ne devrait à la fois lire des données sensibles et envoyer vers n’importe quelle destination réseau. Les nouveaux destinataires exigent une politique explicite et, idéalement, une confirmation.

Utilisez des jetons de capacité, pas un pouvoir ambiant. Accordez une permission limitée et temporaire pour la tâche actuelle. Ne fournissez pas un identifiant large en espérant que le prompt système restera inspirant.

Journalisez les actions proposées comme des données structurées. « L’agent pensait que c’était acceptable » n’est pas un contrôle. Conservez le but utilisateur, l’origine des paramètres, l’outil, la cible, la décision de politique et l’état de confirmation.

Aucun classifieur magique ne séparera durablement les instructions malveillantes des instructions légitimes. Le phishing humain l’a démontré depuis longtemps. Les agents compliquent tout : ils peuvent être persuadés et habilités dans le même tour.

La réponse est de l’ingénierie sans glamour : réduire les autorisations par défaut, lier les actions à l’intention explicite, restreindre les destinations et vérifier le passage des mots aux conséquences.

Les filtres progresseront. Les modèles aussi. Les attaquants également.

Les autorisations sont la partie que nous contrôlons.

Sources