Moindre privilège pour les agents IA dans un SaaS multi-tenant

Un raccourci de prototype fréquent consiste à fournir à un agent un jeton, à exposer tous les outils et à contraindre le comportement avec une invite. Cela rend la démonstration plus simple. En production, cela crée un problème : l’intention écrite dans les invites devient la principale barrière entre une erreur de modèle et la pleine capacité du compte.

Le moindre privilège pour un agent ne s’arrête pas à un rôle « lecture‑seule ». Au minimum, nous devons contraindre cinq aspects : les outils, le type d’opération, les ressources cibles, les données et la durée/identité de l’accès.

1. Limiter le jeu d’outils

Un agent qui analyse la performance publicitaire n’a pas besoin des fonctions de gestion des utilisateurs. Un agent qui prépare un rapport de conformité n’a pas besoin d’un accès shell illimité. Un agent qui organise des fichiers dans un répertoire n’a pas besoin de tout le système de fichiers.

Plus le catalogue d’outils est large, plus la surface d’exposition augmente pour :

• sélectionner le mauvais outil ;
• subir une injection d’invite menant à une action non désirée ;
• combiner de façon inattendue plusieurs outils ;
• exposer accidentellement des données ;
• commettre des erreurs de configuration au niveau du modèle.

La première question ne doit donc pas être « Que peut faire cette API ? » mais :

Quelles trois ou cinq opérations cet agent doit‑il réellement exécuter pour ce travail précis ?

Tout le reste peut rester invisible.

2. Séparer lecture, écriture, effet opérationnel et destruction

« Avoir accès aux campagnes » est trop vague.

Pour nos outils, un modèle d’opération est plus utile :

Portée	Signification	Exemple
read	récupérer l’état et les rapports	obtenir les dépenses, le statut ou la liste des ressources
write	préparer ou modifier la configuration	créer un brouillon, renommer, changer un paramètre
operate	déclencher une conséquence métier	activer une campagne, publier, lancer une synchronisation
destructive	supprimer, détacher ou révoquer	supprimer une ressource, retirer un accès, effectuer un changement difficile à inverser

Un agent peut préparer une configuration sans permission de l’activer. Il peut lire la facturation sans modifier les paramètres de paiement. Il peut rédiger un message sans pouvoir l’envoyer.

Cette frontière est souvent l’endroit où l’autonomie utile réside.

3. La portée de l’outil ne suffit pas — contraindre aussi la ressource

Une permission telle que :

campaign.write

reste trop large si un opérateur possède dix comptes mais que l’agent ne doit travailler que sur un seul.

Dans la mesure du possible, l’autorisation doit prendre en compte :

La décision d’autorisation inclut l’utilisateur, l’agent, la fonction, le type d’opération, le locataire/compte/projet, la ressource et le contexte de la tâche.

qui
+ quel agent
+ quelle fonction
+ quel type d’opération
+ quel locataire/compte/projet
+ quelle ressource
+ quel contexte de tâche

Notre MCP interne Brillnet Ads exige des identifiants explicites de compte/client à l’intérieur d’une frontière autorisée. Une requête générale ne doit pas simplement deviner sur quel compte agir.

C’est particulièrement important dans les SaaS multi‑locataires. Sélectionner le mauvais locataire peut être plus grave qu’une simple erreur de raisonnement du modèle.

4. Limiter les données d’entrée et de sortie

Le moindre privilège s’applique également aux données.

Un agent peut avoir besoin de :

• dépenses agrégées, pas de la liste complète des données utilisateur ;
• statut de la tâche, pas de chaque pièce jointe ;
• confirmation de l’existence d’un identifiant, pas de sa valeur ;
• identifiant de personne, pas de son profil complet ;
• champs de document sélectionnés, pas de tout le référentiel.

Si un outil peut renvoyer un objet minimal, il faut renvoyer l’objet minimal. Ne pas exposer un payload complet du fournisseur au modèle simplement parce que l’API le rend disponible.

Le même principe s’applique aux journaux : une trace d’audit doit contenir suffisamment de preuves, pas une duplication de toutes les données sources.

Lire : pistes d’audit des agents IA

5. Un identifiant ne doit pas vivre plus longtemps ni plus largement que nécessaire

Un jeton administrateur à longue durée placé dans l’environnement de chaque composant est facile à mettre en place. Il est également difficile à contraindre de façon sûre.

Nous privilégions un schéma plus proche de :

1. L’agent ne reçoit pas le secret.
2. La passerelle vérifie l’identité, la portée et la ressource.
3. Elle obtient un identifiant à courte durée.
4. Elle effectue un appel fournisseur autorisé.
5. Le secret n’entre jamais dans la réponse du modèle ni dans le registre d’audit.

Selon sa documentation, notre MCP interne Ads obtient des jetons fournisseurs à courte durée au moment de l’appel. Le matériel d’identification est géré en dehors du contexte du modèle et n’est pas écrit dans les journaux d’application.

Vérifier les permissions au moment de l’exécution

Un agent peut avoir démarré une tâche alors que l’opérateur disposait d’un certain rôle. Dix minutes plus tard, ce rôle peut avoir été révoqué. Un flux de travail long ne doit pas supposer que la permission acquise au début de la session reste valable.

Pour les opérations matérielles, l’autorisation est vérifiée lorsque l’outil s’exécute.

Il en va de même pour les approbations. Un consentement pour une action ne constitue pas une permission pour des actions ultérieures arbitraires.

Une invite n’est pas une ACL

Une instruction telle que :

vous ne pouvez que lire les données et ne devez jamais rien supprimer

peut être une règle comportementale utile. Elle ne remplace pas un contrôle qui bloque techniquement le DELETE.

Si le modèle peut accéder à un outil destructif et à un identifiant qui permet la suppression, la capacité existe. L’invite ne fait que demander au modèle de ne pas l’utiliser.

Une séparation pratique est :

• invite : ce que l’agent doit faire ;
• autorisation/politique : ce que l’agent est autorisé à faire ;
• rôle fournisseur/API : ce que l’identité technique peut faire chez le fournisseur.

L’arrangement le plus sûr est lorsque les trois couches sont alignées, mais aucune d’elles n’est le seul contrôle.

Profils au lieu d’un super‑agent unique

Dans notre outil publicitaire interne, nous séparons les capacités de lecture/planning, de gestion de campagne et une surface de niveau propriétaire pour les opérations administratives rares.

Les noms ne sont pas essentiels. L’essentiel est que l’analyse ordinaire ne tourne pas en permanence avec le niveau de privilège le plus élevé.

Un design similaire ailleurs pourrait être :

Profil	Travail autorisé	Frontière supplémentaire
research‑agent	rechercher, lire, résumer	aucune modification d’état
operations‑agent	lire, créer un brouillon, mettre à jour les champs approuvés	portée opérationnelle
admin workflow	opération administrative	invocation séparée, identité/portée, approbation obligatoire, fenêtre temporelle étroite

Un compromis ou une erreur dans un agent ne confère pas automatiquement l’accès à toutes les classes d’opérations.

Contraindre le système de fichiers et les outils « universels »

Deux catégories méritent une attention particulière.

Shell / exécution de commandes

Un shell sans restriction peut contourner la plupart d’un modèle d’outils soigneusement conçu. Si un agent peut exécuter n’importe quelle commande en tant qu’utilisateur OS largement privilégié, les portées fines ailleurs offrent une protection limitée.

Des outils construits sur mesure ou des commandes sur liste blanche dans un environnement contraint sont généralement plus faciles à raisonner.

Système de fichiers

Un agent qui doit écrire un rapport dans /workspace/reports n’a pas besoin d’accéder à /etc, au répertoire personnel d’un opérateur ou aux secrets CI.

Dans notre MCP interne Ads, les opérations de fichiers sont limitées à des emplacements serveur approuvés ou à des charges utiles bornées. Les chemins système arbitraires sont rejetés.

Une passerelle bas‑niveau a aussi besoin de portées

Parfois, une passerelle générale est utile pour de nouveaux points de terminaison fournisseur avant qu’un outil dédié n’existe. Elle ne doit pas devenir une trappe d’évasion.

Elle doit classifier :

• méthode HTTP ;
• point de terminaison ;
• ressource ;
• caractéristiques de la charge utile ;
• si l’opération écrit ou détruit l’état.

Ce n’est qu’après cela qu’elle doit mapper la requête aux permissions requises.

Si raw_request peut utiliser un jeton à accès complet sans vérifications de politique, il s’agit effectivement d’un accès administrateur, quel que soit le soin apporté aux autres outils.

Élévation temporaire pour les actions à haut risque

Au lieu d’attribuer une portée large de façon permanente, un système peut recourir à une élévation contrôlée :

1. L’agent prépare l’opération ;
2. La passerelle détecte qu’un privilège supérieur est requis ;
3. Une personne approuve les paramètres exacts ;
4. Le système accorde la permission uniquement pour cette opération ou pour une courte période ;
5. La permission expire après l’exécution ;
6. La trace d’audit enregistre l’approbation et le résultat.

Ce mécanisme n’est pas obligatoire partout. Pour les opérations critiques, il réduit le temps pendant lequel une permission large existe.

Lire : Quand un agent IA doit‑il nécessiter une approbation humaine ?

Modèle de tableau d’inventaire des capacités

Avant la mise en production, consignez les limites :

Agent / flux de travail	Outil	Opération	Ressource	Données	Approbation	Identifiant	Audit
reporting campagne	Ads report	read	compte A	métriques sans PII	non	courte durée	oui
préparation campagne	campaign tool	write	compte A	configuration	non/conditionnel	courte durée	oui
activation campagne	campaign operate	operate	campagne X	budget + statut	oui	courte durée	oui
suppression ressource	admin tool	destructive	ressource spécifique	minimum	oui	élevé	oui

Cela est bien plus utile que d’écrire « l’agent a accès à Google Ads ».

Anti‑patterns

Une seule clé API pour tout le système

Les rôles ne peuvent pas être séparés proprement et l’accès à un flux de travail devient difficile à révoquer.

Le même jeu d’outils pour chaque agent

La fonction la plus large du catalogue devient partie du risque de chaque agent.

« Lecture‑seule » uniquement dans l’invite

Si le backend accepte toujours les écritures, « lecture‑seule » n’est qu’une requête, pas un contrôle.

Expansion automatique de la portée après un 403

Un manque de permission doit entraîner un arrêt et une décision, pas un « réessayer en tant qu’administrateur ».

Identifiants dans le contexte du modèle

Un modèle n’a pas besoin de la valeur d’un secret pour demander à une passerelle de confiance d’exécuter un appel autorisé.

Checklist du moindre privilège pour un agent

• L’agent ne voit que les outils requis pour son rôle.
• Lecture et écriture sont séparées.
• L’activation d’un effet opérationnel possède une portée différente de la préparation de la configuration.
• Les opérations destructives ont une barrière supplémentaire.
• La permission est contrainte au locataire/compte/projet/ressource.
• Les ressources cibles ambiguës ne sont pas devinées automatiquement.
• Les outils renvoient le minimum de données nécessaire.
• Les identifiants restent hors du contexte du modèle.
• Les jetons sont à courte durée quand c’est praticable.
• L’autorisation est vérifiée à l’exécution, pas seulement au démarrage de la session.
• L’accès au système de fichiers et au shell est limité ou remplacé par des outils dédiés.
• Une passerelle brute ne contourne pas la politique.
• L’élévation de privilège est explicite et traçable.
• L’accès peut être révoqué de façon centralisée.

Exemple détaillé : rapport de qualité pour une ligne de production

Considérons un flux de travail proposé, pas un déploiement réel. Un fabricant souhaite un résumé matinal des non‑conformités pour la ligne L1. L’agent combine comptes, statuts et échéances d’actions. Il ne décide pas de libérer un produit. Le responsable qualité possède le processus ; l’administrateur d’application possède la configuration d’accès.

Commencez par autoriser la lecture des enregistrements L1, en excluant les pièces jointes et les détails des employés. Enregistrez le rapport dans un répertoire interne. Ne pas accorder les fonctions de clôture des non‑conformités, de modification des résultats d’inspection ou d’envoi de communications client simplement parce que la même API les supporte.

Si l’équipe a plus tard besoin de tâches d’action corrective, ajoutez la permission de créer un brouillon pour une équipe nommée. La création de ce brouillon ne doit pas changer le statut du produit. Mettez à jour l’inventaire d’accès et identifiez qui gère une tâche mal assignée. Les identifiants de cet exemple sont des hypothèses de conception, pas des résultats de déploiement Brillnet.

Ce que l’autorisation MCP établit

Ce guide utilise la spécification MCP version 2026‑07‑28. Son modèle d’autorisation HTTP exige de vérifier qu’un jeton d’accès a été émis pour le serveur visé. Un jeton valide pour un autre service ne doit pas octroyer l’accès MCP. Les recommandations de sécurité MCP abordent également le transfert de jetons clients vers des API en aval sans validation adéquate.

Cela ne détermine pas pour autant si un utilisateur peut lire le dossier client B. L’autorisation applicative doit résoudre la relation entre identité et ressource cible. Les scopes OAuth et le filtrage par locataire couvrent des parties différentes de la frontière. Les deux sont importants. Vérifiez les détails du protocole par rapport aux versions réellement utilisées par votre client et serveur ; « compatible MCP » ne dit pas grand‑chose sur les restrictions d’accès.

Vérifier le refus ainsi que le succès

Un rapport correct prouve que le chemin autorisé fonctionne. Il ne prouve pas que les autres chemins sont fermés. Lors de l’acceptation, conservez les résultats d’un petit ensemble de vérifications concrètes :

• demander le même type d’objet depuis un autre locataire ;
• appeler une fonction d’écriture via le profil de reporting ;
• exécuter après la révocation du rôle de l’opérateur ;
• accéder à un fichier hors du répertoire de rapport ;
• tenter la même opération interdite via une passerelle générale.

Attendez un refus sans modification d’état ni divulgation de données de ressource. Enregistrez l’identifiant du test, la version de la politique et le résultat, en excluant les secrets et les dossiers clients complets. Ce sont des contrôles d’acceptation suggérés pour ce flux, pas un programme complet de tests de sécurité.

Conserver un propriétaire pour les changements de permission

L’accès a tendance à croître de façon incrémentale : un connecteur supplémentaire, une exception, un répertoire additionnel. Demandez‑vous si l’agent exécute toujours le même travail. Un connecteur qui permet d’envoyer des messages ne doit pas étendre silencieusement un profil de reporting.

Le propriétaire du processus approuve le besoin métier. L’administrateur provisionne et révoque les accès. Le propriétaire sécurité examine les exceptions et les routes de contournement. Dans une petite entreprise, une même personne peut cumuler plusieurs rôles, mais les décisions doivent rester traçables. Définissez un intervalle de révision basé sur la fréquence des changements et les conséquences possibles. Retirez les privilèges d’installation une fois l’installation terminée.

Demain, inventoriez un agent. Supprimez une permission dont la tâche n’a plus besoin et vérifiez le refus en dehors de la frontière approuvée. Cela fournit une preuve utile sans nécessiter un remplacement complet de l’architecture.

Preuves et limites

Les guides OWASP soutiennent l’usage d’outils restreints et de vérifications d’autorisation. Le NIST publie un catalogue de contrôles de sécurité. Notre modèle lecture/écriture/operation/destructive et l’exemple détaillé sont des recommandations d’ingénierie, pas une législation ou un certificat de conformité. Déterminez séparément les obligations organisationnelles applicables. La documentation interne Ads MCP, version 1.0 du 28 juillet 2026, décrit le design de contrôle cité ; elle ne prouve pas de façon indépendante une opération en production pour un client.

Frontière

Le moindre privilège réduit l’impact maximal d’une erreur ou d’un abus. Il ne garantit pas qu’une opération autorisée soit substantiellement correcte. Nous le combinons donc avec la validation d’entrée, l’approbation pour les actions à fort impact et une trace d’audit.

Revenez au guide des agents IA sûrs ou consultez Brillnet Security.

Deux organisations fictives, une tâche limitée

Dans un environnement de démonstration dédié, autorisez un assistant à lire une procédure approuvée dans l'organisation fictive A et à préparer un brouillon. Exclure l'approbation, la publication, les modifications d'autorisation et l'accès à l'organisation B. Le service d'application établit le contexte de l'organisation à partir de l'acteur authentifié et de la relation autorisée ; un identifiant modifié dans la demande ne constitue pas une autorité pour utiliser les données d'une autre organisation.

Testez la lecture autorisée, une approbation exclue et une demande pour l'organisation B. Pour chaque cas, enregistrez le résultat attendu et inspectez le résultat réel. Les cas de refus doivent laisser l’état interdit inchangé et ne renvoyer aucune donnée de locataire sans rapport. Conservez la version de la stratégie et les métadonnées d'événement minimales nécessaires pour reconstruire le contrôle, tout en excluant les informations d'identification et le contenu inutile du document.

Incluez une instruction inoffensive dans la source synthétique demandant une exportation sans rapport. Traitez-le comme du contenu de document. Les autorisations de tâche et de serveur approuvées restent la base de l'opération autorisée. Cela montre à quel point une gestion rapide et un accès forcé doivent fonctionner ensemble dans la conception proposée.

Dans Pulsar, enregistrez l’exigence, le risque, l’action et les preuves fictives pour examen. Cela teste la façon dont votre équipe documente le contrôle. Cela ne signifie pas que l'essai public Pulsar expose une passerelle MCP ou implémente chaque autorisation d'agent dans votre architecture. Passez en revue l'essai de 14 jours, le mode de paiement requis et les conditions d'annulation, et acceptez une intégration externe séparément si vous en avez besoin.

Sources

• OWASP AI Agent Security Cheat Sheet. Consulté : 2026‑10‑02.
• OWASP Authorization Cheat Sheet. Consulté : 2026‑10‑02.
• Model Context Protocol — The 2026‑07‑28 Specification. Consulté : 2026‑10‑02. Sources vérifiées: 2026-10-10.
• MCP — HTTP authorization specification, 2026-07-28 — Autorisation de transport et jetons liés aux ressources.
• MCP — security best practices — Sécurité de l'intégration et limites d'autorisation.
• NIST SP 800-53 Rev. 5 — Principes de contrôle d’accès et de contrôle d’audit.
• OWASP — LLM01 Prompt Injection — Instructions documentaires non fiables et risques pour les agents.
• OWASP — Logging Cheat Sheet — Enregistrements d'événements utiles et informations sensibles exclues.
• Pulsar GRC — data-exchange scope — Limite des revendications d’intégration publique.
• Portée du produit publié et conditions d'essai — Portée du produit publié et conditions d'essai.

Révisez les conditions et démarrez l'essai de 14 jours

Auditer une opération d'IA : autorisation, résultat et état vérifié

CAPA agro-alimentaire : du constat à l’évaluation de l’efficacité

Une SOP pharmaceutique modifiée : vérifiez la formation et la version source