Les droits d’accès ne sont pas des consignes de prompt.
Conserver l’identité et les accès dans le logiciel, filtrer avant la réponse, limiter les outils et éviter les fuites entre comptes ou services.
Réponse courte
Un prompt peut expliquer une règle, mais il ne peut pas imposer un droit d’accès. L’application doit identifier la personne, calculer ses droits, filtrer les documents et les données avant la réponse, réduire la liste des outils et vérifier chaque action au moment de l’exécution. Les jetons d’accès doivent viser le bon service et ne jamais circuler vers des systèmes sans rapport. L’assistant peut distinguer un résultat vide, refusé ou indisponible sans recevoir le contenu protégé.
À retenir
- 01
L’autorisation est une responsabilité déterministe du produit.
- 02
Le modèle reçoit un contexte et une liste d’outils déjà limités.
- 03
Chaque appel important est revérifié par l’application au moment de l’exécution.
01 / SITUATION
Une règle écrite en langage naturel n’est pas une barrière de sécurité
Une consigne comme « ne montre pas les dossiers d’une autre entreprise » exprime une intention. Elle n’empêche ni un document récupéré par erreur, ni un résultat d’outil compromis, ni une injection de prompt de pousser le modèle vers des données interdites.
Une conception plus sûre retire les données et les opérations interdites avant que le modèle ne choisisse quoi que ce soit. L’assistant peut expliquer qu’une information n’est pas disponible. Il n’a besoin ni du contenu protégé ni de l’identifiant qui permettrait de le récupérer.
02 / MECHANISM
Un pipeline de sécurité qui ne peut que réduire le périmètre
Les étapes probabilistes peuvent classer ou réduire des choix. Elles ne doivent jamais élargir une limite déterministe.
- 01Authentifier
Utiliser la session du logiciel ou un jeton délégué avec un périmètre précis. Vérifier l’émetteur, la destination, l’expiration et la ressource visée.
- 02Autoriser
Calculer les droits effectifs en lecture et en écriture pour l’organisation, le site, le dossier et l’opération.
- 03Filtrer avant la recherche
Appliquer les métadonnées d’accès avant le chargement d’un texte dans le contexte du modèle. Ne pas chercher partout pour masquer ensuite.
- 04Réduire les outils disponibles
Retirer les opérations interdites ou indisponibles avant le routage. Garder les identifiants et les jetons des services hors des prompts et des journaux.
- 05Valider chaque appel
Contrôler côté serveur l’outil, ses paramètres, le périmètre, l’état actuel et les droits. Refuser les identifiants périmés ou rattachés à une autre organisation.
- 06Tracer sans exposer
Enregistrer les décisions, les identifiants utiles et la classe du résultat après expurgation. Éviter les jetons, les prompts complets et les données personnelles inutiles.
03 / Dans le travail réel
Une question, plusieurs rôles
Le contexte client ne contient aucun outil de validation. L’opérateur peut préparer une correction. L’administrateur ne voit le parcours de revue que si l’application l’autorise.
Identifiant d’une autre organisation
Un numéro de dossier envoyé par le navigateur est recherché dans l’organisation connectée. Un identifiant valide ailleurs produit un refus, jamais des données.
Accès à une ressource MCP
Le serveur MCP vérifie que le jeton a été émis pour sa propre ressource et ne le transmet pas tel quel à une API en amont.
Pièges fréquents
- Écrire les droits dans le prompt système.
- Récupérer des passages protégés puis demander au modèle de ne pas les citer.
- Accepter le rôle ou l’organisation indiqués par le navigateur.
- Faire circuler un même jeton large entre plusieurs services.
- Journaliser les prompts, les paramètres ou les résultats sans politique d’expurgation.
Checklist d’implémentation
- L’identité vient d’une session authentifiée par le produit.
- La ressource visée et la destination du jeton sont vérifiées explicitement.
- Les filtres d’accès s’appliquent avant la recherche et la génération.
- Le routage sémantique ne peut pas élargir la liste des outils.
- Chaque action revérifie les droits et l’état actuel.
- Les états vide et refusé restent distincts.
- Les journaux excluent les secrets et limitent les données personnelles.
- Les tests avant livraison couvrent les injections de prompt et les accès entre organisations.
Ce que cette approche ne promet pas
- Cette architecture réduit l’exposition, mais ne remplace pas une analyse complète des menaces.
- MCP standardise le protocole. Il ne rend pas tous les serveurs dignes de confiance.
- La sécurité réelle dépend encore de l’implémentation, du déploiement et des pratiques d’exploitation.
Sources et nature des références
- 01Model Context Protocol specificationMCP maintainers · 2025-11-25Référentiel
- 02MCP Security Best PracticesMCP maintainers · 2026Documentation officielle
- 03AgentDojo: A Dynamic Environment to Evaluate Prompt Injection AttacksDebenedetti et al. · 2025Recherche
- 04Adversarial Machine Learning: A Taxonomy and TerminologyNIST · 2025Référentiel
- 05OWASP Top 10 for LLM Applications 2025OWASP · 2025Référentiel
Questions fréquentes
Le prompt peut-il tout de même contenir des règles ?
Oui, pour expliquer le comportement attendu. Leur application doit rester hors du modèle, dans des contrôles déterministes.
Faut-il dire à la personne que l’accès a été refusé ?
Seulement au niveau utile dans le produit. L’assistant peut signaler qu’une information est indisponible sans confirmer l’existence d’un dossier protégé.
L’auto-hébergement règle-t-il le problème des accès ?
Non. Le lieu d’hébergement et les autorisations sont deux sujets distincts. Un modèle hébergé en interne peut tout de même recevoir trop de données ou des identifiants trop larges.