La décision

Traitez documents, courriels et sorties du modèle comme entrées non fiables. Un texte peut décrire un ordre sans autorité pour le donner. OWASP identifie injection et autonomie excessive ; les frontières doivent exister hors du prompt.

Un cas concret

Un courriel fictif demande d’ignorer les règles et d’exporter les clients. C’est un contenu à analyser, pas une autorité. Même si le modèle demande l’export, l’application vérifie droits, destination et action approuvée.

Les options à comparer

Un assistant en lecture seule dispose de moins d’actions. Pour écrire, exposez un outil étroit, des paramètres validés et une confirmation claire. Un formulaire classique peut mieux convenir aux décisions importantes.

Les points de rupture

Pas d’identifiants dans le prompt ; « ne divulgue pas les secrets » ne contrôle pas l’accès. Limitez outils et données, séparez les clients avant recherche. Testez les ordres hostiles dans les pièces jointes.

Attacher l’autorisation à la commande

Limitez les capacités, par exemple lire ses commandes ou préparer une réponse. Identifiez utilisateur et organisation via la session authentifiée, pas le courriel ni les paramètres du modèle. Vérifiez la propriété du dossier côté serveur. Autoriser un nom d’outil ne suffit pas si ses paramètres permettent un autre client, destinataire ou périmètre.

Prévisualisez les actions importantes. Liez l’accord au dossier, à l’opération et aux paramètres essentiels, non à un « oui » général. Tout changement demande une nouvelle décision. La lecture peut aussi divulguer : contrôlez droits dans la recherche et les passages retournés, pas uniquement à l’écriture.

Répéter le refus et une suspension sûre

Testez une pièce jointe hostile fictive demandant les données d’un autre compte, accompagnée d’une demande légitime. N’utilisez pas de vrais clients. Aucun accès, modification ou envoi non autorisé ne doit survenir, même si le modèle réclame un outil inapproprié. Vérifiez que les erreurs ne révèlent pas l’existence de dossiers protégés.

Permettez de désactiver un outil ou une source en conservant les fonctions sûres. Définissez le sort des travaux en attente après révocation. Tracez références, décisions d’autorisation et catégories sûres sous accès limité, sans secrets ni contenu inutile. Réexaminez toute capacité ajoutée. Un test réussi réduit des risques connus ; il ne prouve pas l’élimination de l’injection de consignes.

Avant de lancer le projet

Que peut-il lire, modifier, envoyer ? Qu’impose le serveur ? Quelle trace laisse un refus ? Reprenez ces vérifications lorsque outils ou sources changent.

Sources et lectures complémentaires

  1. OWASP: security risks in language model applications
Services

Intégration IA

L’IA lorsqu’elle aide. Des limites lorsqu’elles comptent.

Parlons de ce service