Outils de moindre privilège
Attribuez à un agent l'ensemble d'outils le plus restreint, et à chaque outil la portée la plus étroite, dont la tâche a réellement besoin. Ce modèle accepte le fait que l'injection de prompt réussira parfois et limite ce qu'un agent compromis peut faire — vous ne pouvez pas corriger le modèle, mais vous pouvez décider de ce qu'il est capable d'atteindre.
Définition
La mise en œuvre d'outils de moindre privilège consiste à restreindre le catalogue d'outils d'un agent, ainsi que les identifiants sous-jacents de chaque outil, au strict minimum requis par la tâche — de sorte que les conséquences d'une attaque réussie ou d'une erreur de modèle soient limitées par conception plutôt que par la conformité du modèle.
Problème
Un agent doté d'outils et d'identifiants étendus transforme toute injection, jailbreak ou hallucination réussie en une action réelle disposant de toute la portée du compte associé.
Quand l'utiliser
Utilisez ce modèle partout où un agent peut agir — appeler des API, écrire des fichiers, envoyer des messages, transférer de l'argent. Plus l'autonomie est grande et moins il y a de contrôle humain, plus le rayon d'impact doit être défini au niveau de la couche d'autorisation plutôt que dans le prompt.
Solution
Partez de la tâche, pas de la plateforme. Listez les opérations que l'agent doit effectuer et exposez précisément celles-ci. Un catalogue assemblé à partir de « ce que propose l'API » constitue une attribution d'autorisations que personne n'a examinée.
Séparez la lecture de l'écriture : outils distincts, identifiants distincts, et aucun chemin d'écriture accessible via un argument d'un outil de lecture. Les points de terminaison de « requête » qui peuvent également modifier des données constituent l'escalade silencieuse la plus courante.
Limitez la portée de l'identifiant, pas seulement de l'outil. Un outil en lecture seule s'appuyant sur un jeton d'administration n'est qu'à un bug près de devenir un outil d'écriture ; émettez des identifiants par outil avec la portée la plus étroite prise en charge par le système amont.
Limitez les paramètres. Autorisez explicitement (allowlist) les chemins, dépôts, tables, comptes ou destinataires qu'un outil peut cibler, afin qu'un agent compromis ne puisse pas rediriger un outil légitime vers une cible illégitime.
Faites en sorte que les autorisations expirent et soient réévaluées. Les outils s'accumulent ; supprimez ceux qui ne sont jamais appelés et considérez l'ajout d'un outil comme la modification d'autorisation qu'il représente réellement.
Enregistrez l'autorisation et l'appel séparément. Ce que l'agent pouvait faire et ce qu'il a fait constituent deux audits d'incidents différents, et la résolution d'un incident nécessite les deux.
Composants
Avantages
- Limite les dommages d'une injection réussie sans dépendre du bon comportement du modèle.
- Transforme la question « cet agent est-il sûr ? » en un artefact vérifiable : une liste d'outils, de portées et de propriétaires.
- Améliore la précision de la sélection des outils comme effet secondaire — il est plus facile pour un modèle de choisir parmi des outils moins nombreux et plus précis.
- Rend les incidents analysables, car l'ensemble accessible était connu avant l'incident.
Risques
- Dérive de la portée par commodité : un jeton étendu collé pendant le débogage et jamais restreint par la suite.
- Fragmentation : des dizaines d'outils extrêmement spécifiques que le modèle ne parvient pas à distinguer, troquant un gain de sécurité contre une perte de fiabilité.
- Faux sentiment de sécurité. Le moindre privilège limite les conséquences ; il n'empêche pas l'attaque et ne dit rien sur l'exfiltration via un outil de lecture légitimement autorisé.
- Lenteur des processus : si l'émission d'un identifiant restreint est plus difficile que la réutilisation d'un identifiant étendu, le processus lui-même devient la vulnérabilité.
Quand ne pas l'utiliser
- Prototypes sur des données synthétiques sans accès à la production, où le formalisme coûte plus cher que le risque qu'il élimine.
- Lorsque la plateforme amont ne peut pas du tout exprimer de portées — le contrôle se déplace alors vers un proxy placé devant elle, plutôt que d'être considéré comme résolu.
- Lorsque restreindre l'agent reviendrait à transférer le travail vers un parcours humain qui est lui-même moins limité et moins audité.
Technologies
Exemples
- Un agent de codage disposant d'un jeton de dépôt limité à un seul dépôt et à un seul préfixe de branche, sans accès en lecture à l'échelle de l'organisation. Une injection via le fichier README d'une dépendance peut toujours ouvrir une branche, mais elle ne peut pas accéder aux quarante autres dépôts.
- Un agent de support dont les outils CRM sont séparés : read_customer avec une clé en lecture seule, et update_ticket restreint aux tickets déjà présents dans la conversation. Une session détournée peut perturber un ticket, mais pas exporter la base de clients.
- Un serveur MCP public dont l'ensemble du catalogue est constitué d'accesseurs (getters) sur du contenu déjà publié, sans aucun identifiant d'accès associé — il n'y a rien à révoquer car il n'y a rien à divulguer.
Preuves de production
- Contexte
- Le point de terminaison MCP public de cette base de connaissances, accessible par n'importe quel agent sur Internet.
- Scénario
- Le corpus étant public et en lecture seule, le catalogue est entièrement composé d'accesseurs (getters). Aucun outil n'effectue d'écriture, aucun outil n'accède à une base de données que le site ne publie pas déjà, et aucun identifiant n'est accessible depuis un outil.
- Technologie
- JSON-RPC sans état sur HTTP via un gestionnaire de route Next.js, liste d'autorisation d'origine vérifiée avant l'exécution de tout gestionnaire, limitation du débit par appelant dans Redis, journalisation d'audit structurée par appel.
- Charge
- Trafic continu d'agents autonomes depuis le lancement, ainsi que des robots d'indexation de registres et des vérifications de l'état des répertoires.
- Résultats
- Un client de ce serveur détourné par injection de requêtes ne peut rien obtenir qu'il n'aurait pu récupérer sur le site public, car l'ensemble accessible correspond exactement au corpus publié. Il n'y a aucun identifiant à révoquer ni aucun chemin d'écriture à exploiter.
KPI
- Outils par agent
- La taille du catalogue. Une croissance sans suppressions indique que les autorisations s'accumulent sans être passées en revue.
- Part des outils disposant de droits d'écriture
- La proportion du catalogue capable de modifier l'état. Un indicateur qu'il convient de réduire au strict minimum requis par la tâche.
- Âge de l'outil inutilisé le plus ancien
- Nombre de jours écoulés depuis le dernier appel d'un outil autorisé. Une ancienne autorisation inutilisée représente un accès inutile dont un attaquant pourrait hériter.
- Couverture de la documentation des portées
- Part des outils disposant d'une portée documentée et d'un propriétaire désigné. Un outil non documenté est un outil sans limites.
Modes de défaillance observés
- Le jeton d'administration derrière l'outil en lecture seule : portée déclarée au niveau de l'outil, mais illimitée au niveau des identifiants.
- Redirection de paramètre : l'outil est légitime mais la cible ne l'est pas, car rien ne contraignait l'argument.
- Député confus (confused deputy) : restreindre les outils sans restreindre l'autorité sous laquelle ils s'exécutent ne change rien, car l'appelant hérite toujours de la portée de l'agent.
- Dérive du catalogue : les outils ajoutés pour une expérimentation restent en place, et l'ensemble de permissions initialement validé ne correspond plus à celui qui est déployé.
Leçons apprises
- Définissez le rayon d'impact par écrit avant d'autoriser l'outil, et non après l'incident.
- Le nom d'un outil ne définit pas sa portée. Seul l'identifiant côté serveur le fait.
- Supprimer un outil que personne n'appelle est l'action de sécurité la plus économique qui soit.
- Le moindre privilège est doublement rentable : il limite les attaques et permet à l'agent de mieux choisir ses outils.
FAQ
- Le moindre privilège permet-il d'empêcher l'injection de requêtes (prompt injection) ?
- Non, et ce n'est pas son but. Il part du principe que l'injection réussira parfois et détermine à l'avance ce qu'une attaque réussie peut accomplir. La prévention et le confinement sont deux tâches distinctes ; seul le confinement est sous votre contrôle.
- À partir de quand une restriction devient-elle excessive ?
- Lorsque le modèle ne parvient plus à distinguer deux outils, ou lorsqu'une tâche courante nécessite quatre appels qui auraient pu, en toute sécurité, n'en faire qu'un. Diviser améliore la sécurité jusqu'à ce que cela provoque de mauvais choix d'outils, et un appel erroné constitue un échec en soi.
- Nous utilisons un seul compte de service pour tout. Est-ce si grave ?
- Cela signifie que chaque agent, et chaque attaquant qui en compromet un, dispose de la portée de la tâche la plus large exécutée par l'un d'eux. Utiliser un compte unique revient à appliquer ce modèle avec un rayon d'impact égal à « l'intégralité du système ».