Tests d'IA autorisés : où se situe la limite

La recherche sur l'injection de prompt est à double usage. Le même payload qui démontre une voie d'exfiltration de données à l'équipe sécurité d'un éditeur devient, lancé contre un système qui ne vous appartient pas, une attaque. La technique ne change pas — c'est l'autorisation qui change. Cet article traite de cette limite, car tout le reste de ce site suppose que vous vous trouvez du bon côté.

Ce que « test autorisé » signifie réellement

Un test autorisé signifie que vous disposez d'une permission explicite et documentée de la partie qui possède ou exploite le système, couvrant précisément ce que vous comptez faire. Pour une application LLM, c'est plus large qu'un pentest web classique, car la surface d'attaque comprend :

Le modèle et son prompt système.
Les outils, fonctions et agents connectés que le modèle peut invoquer.
Les sources de récupération (corpus RAG, fichiers téléversés, récupération web).
Les systèmes en aval que le modèle peut atteindre (messagerie, ticketing, bases de données, exécution de code).
Les fournisseurs de modèles tiers, dont les conditions d'utilisation vous engagent également.

La permission portant sur « l'application » ne vaut pas automatiquement permission de faire envoyer des e-mails à l'agent, d'appeler des API internes ou d'extraire des données d'un espace de stockage connecté. Précisez-le noir sur blanc.

Obtenez-le par écrit, avec un périmètre

Un « oui, allez-y » verbal n'est pas une autorisation sur laquelle vous pouvez vous appuyer. Avant d'envoyer le moindre payload, vous voulez un accord écrit qui établit :

Qui autorise (une entité qui possède réellement le système) et qui effectue le test.
Les cibles — noms d'hôtes exacts, comptes, tenants, points d'accès des modèles, et quels outils connectés sont dans le périmètre.
Hors périmètre — explicitement. Les données clients en production, les SaaS tiers, l'infrastructure du fournisseur de modèles et les autres tenants sont des exclusions courantes.
Les actions autorisées — pouvez-vous déclencher des appels d'outils ? Exfiltrer vers un point d'accès de démonstration que vous contrôlez ? Utiliser des données réelles ou uniquement synthétiques ?
Les règles d'engagement — fenêtre de test, limites de débit, un contact pour arrêter et notifier, et la conduite à tenir si vous tombez sur de vraies données sensibles.

Les programmes de bug bounty encodent une grande partie de tout cela dans leur politique et leurs clauses de sphère de sécurité (safe harbor). Si un programme existe, lisez-le et restez à l'intérieur ; la politique est votre autorisation, et elle a des limites.

Pourquoi la recherche sur l'injection de prompt est légitime

Les défenseurs ne peuvent pas se prémunir contre une classe d'attaque qu'ils n'ont pas le droit d'étudier. L'injection de prompt indirecte, les balises par image markdown et l'empoisonnement de RAG sont des techniques réelles, observées en conditions réelles. Construire des détections, écrire des contrôles de spotlighting et de sortie de données (egress), et mener des exercices red team sur ses propres agents exigent tous de reproduire les attaques dans des conditions contrôlées. C'est une pratique de sécurité standard — la même logique qui rend le développement d'exploits légitime pour ceux qui livrent le correctif.

C'est précisément ce caractère à double usage qui fait peser tout le poids sur l'intention et l'autorisation. Publier une technique bien connue avec ses défenses sert le domaine. Lancer cette technique contre un système qui ne vous l'a jamais demandé, non.

Rappel sur l'usage autorisé : chaque technique présentée sur ce site est destinée aux systèmes que vous possédez ou que vous êtes explicitement mandaté pour tester. Reproduisez les attaques en laboratoire ou dans un environnement compris dans le périmètre, jamais contre des tiers.

Divulgation responsable

Lorsque vous trouvez quelque chose — dans le périmètre ou par accident — traitez-le avec soin :

Cessez de surenchérir. Démontrez l'impact avec le minimum nécessaire ; ne poussez pas plus loin une fois la faille prouvée.
Minimisez les données. Utilisez des secrets synthétiques comme leurres (canaries). Si vous touchez à de vraies données, ne capturez que ce qui prouve le problème et consignez ce que vous avez vu.
Signalez d'abord en privé. Passez par le contact sécurité de l'éditeur, le fichier security.txt ou le canal de bug bounty. Fournissez des étapes de reproduction claires et l'impact.
Laissez le temps de corriger. Convenez d'un délai de remédiation (divulgation coordonnée, souvent 90 jours). Ne publiez qu'après un correctif ou un délai raisonnable et communiqué.
Conservez des traces. Votre document de périmètre, les horodatages et les échanges sont ce qui distingue la recherche de l'intrusion si l'on vous pose la question.

Ce qu'il NE faut PAS faire

Certaines limites sont nettes, et les franchir transforme la recherche en délit dans la plupart des juridictions :

Ne testez pas des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas de permission écrite — y compris « juste un payload » contre un chatbot tiers en production.
N'exfiltrez pas les données d'autrui. Faites baliser un leurre que vous avez planté, pas les dossiers d'un vrai client ni les documents d'un autre tenant.
Ne dépassez pas votre périmètre pour « voir jusqu'où ça va ». Les systèmes agentiques peuvent entreprendre des actions destructrices dans le monde réel ; partez du principe que les appels d'outils ont des conséquences.
Ne conservez ni ne partagez les données capturées au-delà de ce qu'exige la divulgation, et supprimez-les ensuite.
Ne restez pas assis sur une faille critique pendant que vous décidez de l'exploiter ou non. Divulguez.

En résumé

Le contenu technique présenté ici correspond directement à la catégorie LLM01 : Prompt Injection de l'OWASP. La compétence est transférable ; l'autorisation ne l'est pas. Gardez le périmètre écrit, gardez les leurres synthétiques, divulguez de manière responsable et restez à l'intérieur de la limite — c'est ce qui rend ce travail défendable et digne d'être mené.