RBAC vs ABAC: Choisir un modèle de contrôle d'accès pour les agents IA

Ce qu'est réellement le RBAC

Le contrôle d'accès basé sur les rôles (RBAC) place une couche nommée entre les personnes et les permissions. Vous n'accordez pas à Priya la capacité de lire un groupe de secrets. Vous définissez un rôle nommé Secret Group Viewer contenant cette permission, et vous y assignez Priya.

Le modèle de contrôle d'accès basé sur les rôles repose sur trois éléments :

L'intérêt réside dans l'indirection. Quand l'équipe sécurité décide que les lecteurs ne doivent plus voir les valeurs des secrets, elle modifie un seul rôle et tous les lecteurs sont mis à jour simultanément. Le NIST a formalisé ce modèle il y a des décennies, c'est pourquoi chaque console cloud possède une page dédiée aux rôles.

La faiblesse découle aussi de cette indirection. Les rôles sont des ensembles statiques. Si une permission ne doit s'appliquer qu'à partir d'une IP d'entreprise, ou uniquement aux enregistrements de la propre région du demandeur, le RBAC classique ne peut pas l'exprimer. Les équipes répondent en multipliant les rôles : analyst-eu, analyst-eu-readonly, analyst-eu-readonly-prod. C'est l'explosion des rôles, la raison la plus souvent citée pour se tourner vers l'ABAC.

Ce qu'est réellement l'ABAC

Le contrôle d'accès basé sur les attributs supprime le groupe nommé. Au lieu de demander quel rôle détient un sujet, il évalue une expression de politique au moment de la requête sur quatre catégories d'attributs :

Une politique ressemble à : autoriser la lecture quand subject.department == resource.owning_team et resource.classification != "restricted" et env.network == "corp". Le NIST SP 800-162 en est la publication de référence ; en pratique, l'ABAC est déployé via un langage de politique tel que XACML, Rego ou Cedar derrière un service d'autorisation.

L'ABAC est véritablement plus expressif. Une règle bien écrite peut remplacer une centaine de rôles, et il gère des relations que le RBAC ne peut pas du tout exprimer : « le médecin assigné à ce patient ».

Cette expressivité a un coût. Les politiques sont du code : elles nécessitent des revues, des tests, du versionnement et un moyen d'analyser l'interaction entre les règles. De plus, la première question posée par un auditeur — qui peut lire ces données ? — n'a plus de réponse directe par simple recherche. Vous devez énumérer chaque sujet et évaluer la politique par rapport à chacun. Certains moteurs proposent des outils de requête inverse pour cette raison ; la plupart des déploiements ne les utilisent pas.

Aperçu des différences RBAC vs ABAC

Un élément que ce tableau ne montre pas : l'ABAC requiert des attributs fiables. Une politique basée sur resource.data_region ne vaut que par la rigueur du marquage qui alimente ce champ. La plupart des organisations qui essaient l'ABAC découvrent qu'elles ont un problème de données non marquées avant d'avoir un problème d'autorisation. Et les deux modèles ne s'excluent pas — la configuration courante en production utilise le RBAC comme socle avec quelques conditions d'attributs par-dessus.

Les erreurs fréquemment commises par les équipes

Traiter l'explosion des rôles comme une raison de changer de modèle. L'explosion des rôles est généralement un problème de portée (scoping), pas une défaillance du modèle. Si vous avez analyst-team-a, analyst-team-b et analyst-team-c, vous n'avez pas besoin d'attributs — vous avez besoin d'un seul rôle analyst lié séparément aux ressources de chaque équipe. La majeure parte des difficultés attribuées au RBAC provient d'autorisations accordées à l'échelle du tenant alors que l'association aurait dû se faire sur une ressource unique.

Adopter une expressivité impossible à auditer. L'ABAC vous permet d'écrire une règle que votre équipe de conformité ne peut pas lire. Ce compromis vaut parfois la peine, mais ne doit jamais être fait par accident. Avant d'adopter un moteur de politiques, demandez-vous qui répondra au questionnaire de revue d'accès au trimestre prochain, et comment.

Oublier que les autorisations se cumulent. Un sujet peut détenir un accès directement et en hériter via une équipe ; en supprimer un ne supprime pas l'autre. La situation empire lorsqu'un moteur de politiques est superposé, car deux systèmes peuvent alors accorder des accès indépendamment.

Configurer les permissions de l'humain et ignorer l'agent. Tous les contrôles côté humain deviennent illusoires si l'agent qu'il a construit s'exécute avec un jeton de service partagé disposant d'un accès à l'ensemble du tenant.

Vous souhaitez voir l'accès restreint en pratique ?

Démarrez TrueFoundry et attribuez un rôle sur une ressource unique au lieu de tout le tenant — cela prend environ deux minutes.

Commencer gratuitement

Pourquoi les agents IA semblent justifier l'usage d'ABAC

Un agent IA est un sujet non humain dont l'autorité effective n'est pas fixe. Il peut lire un dépôt public à un instant T et accéder à un enregistrement client l'instant suivant. Il agit pour différentes personnes à différents moments. Ses entrées peuvent être malveillantes — le corps d'un ticket corrompu peut le diriger vers un outil qu'il ne devrait pas appeler. Et contrairement à un humain, il ne s'arrête pas pour se demander si une action est judicieuse.

Formulé sous forme de besoin, cela ressemble exactement à un cahier des charges ABAC : autoriser cet appel d'outil lorsque l'utilisateur agissant dispose d'un accès en amont à la cible, que l'outil n'est pas destructeur et que la requête ne provient pas d'un contenu non approuvé. Trois attributs, une règle. Alors pourquoi cette approche n'est-elle presque jamais déployée ?

Parce que les attributs ne sont pas disponibles de manière fiable au moment de la décision. « Cette requête provient-elle d'un contenu non approuvé » n'est pas un simple champ, c'est un sujet de recherche. « L'utilisateur agissant a-t-il un accès en amont » est vérifiable — mais le moyen le plus économique et exact de le savoir est d'appeler le système en amont avec les propres identifiants de cet utilisateur et de le laisser répondre, plutôt que de dupliquer son modèle de permission dans votre moteur de politiques en espérant que la copie reste à jour.

Le coût d'auditabilité pèse également le plus lourd précisément là où se trouvent les agents. Les permissions des agents sont ce que la revue de sécurité examine avec le plus de rigueur, et « la politique s'évalue comme autorisée sous ces conditions » est une réponse bien moins satisfaisante qu'un tableau indiquant que cet agent détient MCP Server User sur ces trois serveurs.

Ainsi : les agents ont besoin d'un accès plus restreint que les humains et plus inspectable que les humains. L'ABAC offre le premier aspect mais compromet le second. D'où la pratique observée : du RBAC avec une portée restreinte sur les ressources, combiné à quelques verrous contextuels là où le contexte importe réellement.

Comment cela fonctionne dans TrueFoundry

TrueFoundry implémente le RBAC avec des associations de rôles limitées aux ressources. Il ne s'agit pas d'un moteur de politiques ABAC, et il convient d'être clair à ce sujet. Le modèle répond à une question simple : qui peut faire quoi, et où ?

• Un sujet est l'identité qui reçoit l'accès : un utilisateur, une équipe, un compte virtuel ou un agent.
• Une ressource est l'élément auquel on accède : un compte de fournisseur de modèles, un serveur MCP, un agent, un cluster, un workspace, un dépôt ou un groupe de secrets.
• Un rôle est un ensemble nommé d'actions autorisées.

Assigner un rôle à un sujet pour une ressource crée une association de rôle (role binding). L'accès est géré indépendamment de la configuration de la ressource, vous pouvez donc modifier qui a accès sans rien redéployer.

Les attributions se font directement depuis la ressource — ouvrez son menu à trois points et sélectionnez Access Control :

Choisissez ensuite un ou plusieurs sujets et un rôle. Le panneau latéral liste les actions incluses dans chaque rôle, vous voyez donc ce que vous accordez avant de le valider :

Les rôles proposés dépendent du type de ressource : Manager et User sur un compte fournisseur de modèles ; MCP Server Manager, MCP Server User et MCP Server Approver sur un serveur MCP ; Agent Manager et Agent Access sur un agent. Les clusters, workspaces et groupes de secrets disposent chacun de leurs propres niveaux admin, member et viewer.

Trois portées, et non une seule

Les rôles s'appliquent à trois niveaux de portée, et bien les distinguer constitue l'essentiel de la méthode :

Admin et Read-Only Member ne peuvent pas être modifiés. Member peut l'être — c'est le niveau de base attribué à chaque utilisateur, qui n'inclut par défaut que cluster:ReadCluster, environment:ListEnvironments, settings:ListSettings, user:ListUsers, repository:CreateRepository, secret-group:CreateSecretGroup et agent:CreateAgent. Il ne donne accès à aucun modèle individuel, serveur MCP ou workspace — ceux-ci proviennent des associations de ressources ou de l'appartenance à une équipe.

Les rôles d'équipe sont ce qui se rapproche le plus d'une condition d'attribut ici, et la ressemblance est instructive. Team Member comporte virtual-account:ReadVirtualAccount, restreint aux comptes virtuels possédés par les équipes auxquelles l'utilisateur appartient réellement. La permission est identique pour tous ; l'ensemble des objets accessibles varie selon la personne.

Il s'agit d'une restriction par propriété et non d'ABAC : pas d'expression de politique, pas d'évaluation d'attributs, simplement une relation fixe entre une équipe et ce qu'elle possède. Cela couvre le cas d'usage classique qui pousse vers les attributs, tout en restant lisible.

Rôles personnalisés pour permissions fines

Lorsque les rôles intégrés au tenant sont trop larges ou trop restreints, créez les vôtres à partir du catalogue de permissions. Chaque permission suit un format ressource:Action, groupé par type de ressource :

Règle essentielle sur son utilisation : les permissions d'un rôle personnalisé s'appliquent à l'ensemble des ressources du type sélectionné. Un rôle personnalisé avec mcp-server:ReadMcpServer accède à tous les serveurs MCP, pas seulement à quelques-uns. Pour une seule ressource, utilisez plutôt la page Access Control de cette ressource. Inverser ce principe est la façon dont un rôle destiné à un seul serveur devient discrètement un accès en lecture sur tout le tenant.

Les verrous contextuels, nommés avec précision

TrueFoundry ajoute de la sensibilité au contexte à quatre endroits. Aucun ne constitue une politique d'attributs, et chacun est inspectable :

Le deuxième point effectue la majeure partie du travail attendu de l'ABAC. Lorsqu'un agent appelle un outil pour un utilisateur spécifique via l'OAuth par utilisateur, le service en amont évalue les véritables permissions de cet utilisateur. Vous n'avez pas modélisé les ACL de dépôt de GitHub dans un moteur de politiques ; vous avez délégué au système qui les détient, et cette copie ne peut pas devenir obsolète. Le modèle de contrôle d'accès MCP repose directement là-dessus.

Une limite : les jetons de compte virtuel (Virtual Account) donnent un accès identique à chaque requête. Ils conviennent aux appels de service à service mais ne sont pas adaptés là où les permissions par utilisateur comptent.

Exemple concret, deux approches

Deux scénarios réels issus de la documentation montrent le modèle en action selon deux perspectives opposées.

Accorder un accès en lecture seule à un auditeur. Assignez Read-Only Member depuis Access > Users. Il s'agit d'un rôle intégré au tenant, offrant un accès en lecture seule sur les types de ressources pris en charge, et non modifiable — ce qui est le but recherché, car un rôle d'audit modifiable discrètement n'est plus un rôle d'audit. Pour un groupe d'auditeurs, assignez-le à une équipe afin que les futurs membres en héritent. Si l'auditeur ne doit voir que des ressources sélectionnées, omettez le rôle de tenant et accordez le rôle viewer ou access sur chaque ressource.

Permettre la création de serveurs MCP sans accorder le rôle Admin. Le premier réflexe est d'attribuer Admin, car la création d'un serveur nécessite une permission que Member ne possède pas. Créez plutôt un rôle personnalisé contenant exactement mcp-server:CreateMcpServer :

Assignez-le ensuite depuis Access > Users ou Access > Teams :

Le comportement est la partie intéressante. Create MCP Server permet d'ajouter un nouveau serveur. Cela n'accorde pas d'accès aux serveurs existants. Après avoir créé un serveur, le propriétaire s'accorde lui-même le rôle MCP Server Manager depuis la page Access Control de ce serveur.

L'autorité de création et l'autorité d'accès sont distinctes, et aucune ne s'étend sur l'autre. Une politique ABAC pourrait exprimer la même chose, via une règle qu'il faudrait lire attentivement pour en être certain. Ici, il s'agit de deux lignes dans deux tableaux. Ce schéma s'adapte aussi à la baisse : pour permettre à tout le monde de voir les commandes du gateway sans Admin, modifiez Member et ajoutez gateway-controls:ListGatewayControls.

Prêt à définir la portée de votre premier agent ?

Créez un rôle personnalisé, liez-le à un serveur MCP et vérifiez exactement ce à quoi votre agent a accès.

Commencer gratuitement sur TrueFoundry

Pièges à connaître

Les autorisations se cumulent, et en supprimer une ne supprime pas l'autre. Un sujet peut recevoir un accès directement et via son appartenance à une équipe. Pour comprendre pourquoi quelqu'un voit encore un élément, vérifiez à la fois les associations directes et l'ensemble de ce qui est hérité des équipes. C'est le premier endroit à vérifier, à chaque fois.

Modifier le rôle par défaut d'une équipe le change pour toutes les équipes. Team Member et Team Manager sont modifiés sous Access > Default Roles, et la modification est globale. Ajouter virtual-account:ManageVirtualAccount pour qu'une équipe puisse récupérer des jetons l'accorde aux membres de toutes les équipes. Chaque personne reste limitée à ses propres équipes, mais la capacité s'étend partout.

Les rôles de tenant se cumulent avec les rôles de tenant des équipes. Un utilisateur possède un rôle de tenant assigné directement. S'il appartient également à une équipe détenant un rôle de tenant, ses permissions effectives sont l'union des deux — l'autorité réelle d'un utilisateur n'est donc pas visible sur sa seule fiche utilisateur. Les équipes peuvent être créées manuellement, provisionnées depuis votre IdP via SCIM, ou appliquées avec tfy apply sur un fichier YAML d'équipe, et une valeur de claim d'IdP peut s'associer directement à une équipe.

Lectures associées

• Authentification API et RBAC dans l'AI Gateway — comment ces rôles sont appliqués sur le trafic du gateway
• Contrôle d'accès MCP : Sécuriser les agents IA avec un MCP Gateway — permissions au niveau des outils et des serveurs en pratique
• Contrôle d'accès MCP en entreprise — passer le modèle à l'échelle sur de nombreux serveurs et équipes
• Qu'est-ce qu'un MCP Gateway : Architecture et cas d'usage — où se situe le point d'application
• Construire un cadre de gouvernance pour l'IA — la vision globale des politiques autour du contrôle d'accès

Conclusion

Le débat RBAC vs ABAC s'achève souvent sans conclusion tranchée. Cela ne devrait pas être le cas. L'ABAC est adapté lorsque l'accès dépend réellement d'un contexte d'exécution mesurable et fiable, et lorsque vous disposez d'un endroit où placer le code de politique ainsi que d'une personne pour la gérer. Pour tout le reste, le RBAC avec des associations correctement restreintes remplit son rôle et laisse une trace lisible par un humain.

Les agents IA semblent remettre cette règle en cause, et ils modifient en effet les standards de bonnes pratiques — des portées plus étroites que pour les humains, des identifiants par utilisateur plutôt que des jetons partagés, une validation humaine sur les opérations à risque. Rien de tout cela ne nécessite un moteur de politiques — uniquement des rôles liés à des ressources individuelles au lieu du tenant complet, et quelques contrôles ciblés lors de l'exécution.

C'est ce que TrueFoundry implémente, et le qualifier de RBAC plutôt que d'employer un terme plus pompeux en constitue tout l'intérêt. Lorsque votre prochaine revue d'accès demandera ce que cet agent peut atteindre, la réponse doit être une liste, pas une démonstration.

Définissez la portée de votre premier agent sur TrueFoundry

Gratuit pour démarrer