Prompt injection au Maroc : sécuriser les assistants IA métier

La prompt injection au Maroc devient un risque concret dès qu’un assistant IA lit des documents, consulte le web ou déclenche une action dans un outil métier. Une instruction malveillante peut être saisie directement par un utilisateur, mais aussi se cacher dans une page, un e-mail ou un fichier que le modèle doit analyser. Sécuriser l’assistant exige donc plus qu’un bon message système.

Comprendre l’injection directe et indirecte

Une injection directe arrive dans la conversation : l’utilisateur demande au modèle d’ignorer ses règles ou de révéler une information. Une injection indirecte est intégrée à une source externe. L’assistant peut la rencontrer en résumant un document, en lisant une page ou en interrogeant une base de connaissances.

Le référentiel OWASP LLM01 précise que le RAG et l’ajustement du modèle ne suppriment pas à eux seuls cette vulnérabilité. Le NIST définit également la prompt injection comme une manipulation des entrées destinée à provoquer un comportement non prévu.

Ne pas confondre instruction et autorisation

Un modèle de langage interprète du texte ; il ne doit pas devenir la frontière d’autorisation du système. La décision d’accéder à un dossier, d’envoyer un message ou de modifier une donnée doit rester contrôlée par l’application. Les rôles, les permissions et les règles métier doivent être appliqués en dehors du modèle.

Pour limiter la prompt injection au Maroc, chaque outil connecté à l’assistant doit fonctionner avec le moindre privilège. Une fonction de lecture ne doit pas hériter d’un droit d’écriture. Les opérations autorisées doivent être explicites, les paramètres validés et les destinations sensibles restreintes par une liste contrôlée.

Exiger une confirmation pour les actions sensibles

Une confirmation humaine est pertinente avant un envoi externe, une suppression, un paiement, une modification de droits ou toute autre action difficile à annuler. La confirmation doit présenter l’action réelle, sa cible et les données concernées. Elle ne doit pas se limiter à une formule vague générée par le modèle.

OpenAI recommande notamment de garder l’utilisateur en contrôle avant les actions conséquentes dans son analyse des prompt injections. Cette approche complète le modèle human-in-the-loop : l’IA prépare le travail, mais l’application et l’utilisateur conservent le pouvoir de décision.

Séparer données non fiables et consignes de confiance

Les contenus récupérés doivent être traités comme des données non fiables, jamais comme de nouvelles règles système. Une architecture robuste conserve la provenance de chaque élément, borne sa taille, neutralise les formats inattendus et transforme si possible le texte libre en champs structurés avant toute action.

Dans un assistant RAG, les passages retrouvés servent à répondre à une question ; ils ne doivent pas pouvoir redéfinir les permissions. Les documents, les métadonnées et les citations restent séparés des instructions internes. Les secrets, jetons et identifiants techniques ne doivent jamais être injectés dans un contexte accessible au modèle si l’action peut être réalisée autrement.

Combiner plusieurs couches de défense

Aucun filtre unique n’est suffisant. Une défense utile associe plusieurs contrôles :

• classifier et délimiter les entrées provenant d’utilisateurs ou de sources externes ;
• valider les appels d’outils, leurs paramètres et leurs résultats ;
• appliquer les droits dans le système métier, pas dans le prompt ;
• bloquer l’exposition des secrets et réduire les données transmises au modèle ;
• journaliser les décisions, les refus et les confirmations sans enregistrer de données sensibles inutiles ;
• prévoir un arrêt sûr lorsque le contexte ou l’intention reste ambigu.

Ces contrôles s’inscrivent dans une démarche DevSecOps : sécurité, tests et observabilité accompagnent chaque évolution de l’assistant, de son prompt à ses connecteurs.

Tester les parcours réels, pas seulement le chatbot

Un test utile couvre l’ensemble du parcours : entrée utilisateur, document récupéré, décision du modèle, appel d’outil et effet final. Les scénarios doivent inclure des instructions dissimulées, des changements de langue, des demandes ambiguës, des pièces jointes non fiables et des tentatives d’accès hors périmètre.

Les résultats alimentent des évaluations reproductibles. On vérifie si l’assistant refuse, demande une confirmation, limite son action ou remonte une alerte. Cette pratique complète l’évaluation de l’IA générative en mesurant le comportement du système connecté, et pas uniquement la qualité de la réponse.

Déployer un assistant IA avec un périmètre maîtrisé

Commencez par un cas d’usage délimité, avec des données connues et peu d’actions disponibles. Cartographiez ensuite les sources non fiables, les droits requis, les opérations irréversibles et les preuves à conserver. Étendez le périmètre seulement après des tests adversariaux et une validation métier.

Kanteek conçoit des solutions d’intelligence artificielle intégrées aux outils de l’entreprise, avec des contrôles adaptés aux données et aux actions. Notre équipe de conseil et stratégie peut cadrer la prompt injection au Maroc comme un risque d’architecture, de produit et d’exploitation, plutôt qu’un simple problème de formulation.