Cas d'usage

Permissions d'outils

Chaque agent IA reçoit son propre trousseau de clés limité — il ne peut utiliser que les outils dont son travail a besoin, avec des accès restreints, temporaires et suivis.

En deux mots

Pensez à un trousseau de clés. Le trousseau du concierge ouvre les bureaux mais pas le coffre-fort; celui du gérant ouvre le coffre mais pas la salle des serveurs. Les permissions d'outils donnent à chaque agent IA son propre trousseau : la question n'est jamais de savoir si l'édifice peut s'ouvrir, mais si cet agent-là détient cette clé-là.

Le trajet, en une image
L'agent demande un outilLe registre vérifie ses clésPermis ? Clé temporaire émiseRefusé ? Appel bloquéChaque accès consigné

Le problème, en mots simples

Vous donnez à un agent IA l'accès à vos systèmes pour qu'il puisse vraiment aider : chercher une commande, mettre un dossier à jour, envoyer un message. La façon facile de brancher tout ça, c'est un compte tout-puissant dont tout le monde partage le mot de passe. Ça marche — jusqu'à ce que ça ne marche plus. Chaque agent peut alors tout faire, et quand quelque chose tourne mal, impossible de dire qui a fait quoi : tout a été fait avec la même clé maîtresse. Un agent qui se mêle, ou un identifiant qui fuit, et tout l'édifice est grand ouvert.

Ce que nous mettons en place

Un registre — un catalogue central d'outils, bâti sur MCP (Model Context Protocol, une façon standard pour les agents IA d'utiliser des outils) — devient le serrurier. Chaque outil déclare quelles permissions (portées d'accès) il exige pour fonctionner. Le registre tient la carte de quel agent, travaillant pour quel client (tenant), détient quelles portées. Quand un agent appelle un outil, il ne reçoit pas le mot de passe maître : il reçoit un jeton — une clé temporaire limitée à exactement cette portée, qui expire d'elle-même. Le vrai système derrière l'outil ne voit jamais d'identifiant partagé. Un appel hors de la portée d'un agent est refusé avant même d'atteindre le système, et chaque fois qu'une clé est accordée ou retirée, le changement est consigné.

Comment ça fonctionne, étape par étape

  1. Chaque outil déclare ses besoins

    Chaque outil du catalogue annonce d'avance quelles permissions il exige — pas de « donne-lui tous les droits et passe au suivant ».

  2. Chaque agent reçoit son trousseau

    Le registre note quel agent détient quelles portées, et au nom de qui. Agents différents, trousseaux différents.

  3. Un appel reçoit une clé temporaire

    Chaque appel d'outil porte un jeton limité et à durée de vie courte, plutôt qu'un mot de passe partagé. Il ouvre une porte, pour un moment.

  4. Mauvaise clé ? La porte reste fermée

    Un appel hors de la portée de l'agent est refusé au registre, avant de toucher le vrai système.

  5. Les changements de clés sont au dossier

    Chaque octroi et chaque retrait est consigné : « qui avait quelle clé, quand » devient une requête — pas une dispute.

Ce qui change pour vous

Avant : n'importe quel agent qui déraillait — ou se faisait piéger — pouvait faire tout ce que le compte partagé pouvait faire, et le ménage commençait par des devinettes. Après : un agent compromis ou mêlé ne peut agir que dans son trousseau, le rayon des dégâts est petit par conception, et un audit se répond tout seul à partir du journal. Ajouter un nouvel agent, c'est décider tout haut quelles clés il reçoit, au lieu de tout hériter par défaut. Ce qu'il ne fera pas : il ne jugera pas si une action permise est une bonne idée. Un agent qui a la clé des remboursements peut encore rembourser au mauvais moment — c'est le rôle des approbations humaines et des pistes d'audit.