Agents IA en entreprise : cloisonner les accès avec RBAC et MCP pour ne pas donner les clés du bâtiment

Déployer un agent IA autonome dans une application métier, c'est un peu comme embaucher un prestataire très efficace... sans lui avoir expliqué ce qu'il n'a pas le droit de toucher. Sans garde-fous, l'agent a potentiellement accès à tout : les données de vos clients, celles de vos concurrents hébergés sur la même instance, les actions critiques réservées aux administrateurs. Le résultat peut être catastrophique, surtout dans un contexte SaaS multi-tenant.

Un article publié sur DEV Community par Nasrul Hazim Bin Mohamad pose exactement la bonne question : comment donner à un agent IA les clés dont il a besoin, sans lui donner accès à tout le bâtiment ? La réponse s'articule autour de deux piliers — le contrôle d'accès basé sur les rôles (RBAC) et des outils MCP (Model Context Protocol) cloisonnés par organisation — illustrés dans un contexte Laravel. Les principes s'appliquent tout aussi bien à Symfony et à l'écosystème PHP en général.

Pourquoi le cloisonnement est non négociable en contexte multi-tenant

Dans une architecture SaaS classique, plusieurs organisations (tenants) cohabitent sur la même infrastructure. Chaque tenant a ses utilisateurs, ses données, ses règles métier. Lorsqu'un agent IA entre en jeu, la surface d'attaque s'étend considérablement : l'agent peut être invoqué par un utilisateur d'un tenant A, mais s'il n'est pas correctement isolé, rien ne l'empêche — techniquement — d'interroger ou de modifier des données appartenant au tenant B.

Ce n'est pas une faille hypothétique. C'est le comportement par défaut si l'on branche naïvement un LLM sur une API sans restreindre son périmètre d'action. Les PME qui adoptent des agents IA pour automatiser des tâches (support client, génération de rapports, actions CRUD assistées) s'exposent à ce risque dès la première mise en production.

Le principe de moindre privilège — donner à chaque acteur uniquement les droits strictement nécessaires à sa mission — doit s'appliquer aux agents exactement comme il s'applique aux utilisateurs humains.

RBAC : définir ce que l'agent a le droit de faire

Le contrôle d'accès basé sur les rôles (RBAC) est une approche éprouvée pour structurer les permissions. Appliqué aux agents IA, il consiste à associer à chaque agent (ou à chaque session agent) un rôle explicite, avec des permissions granulaires.

Concrètement, cela signifie :

• Identifier les actions exposées : quelles opérations l'agent peut-il déclencher ? Lecture seule, création, modification, suppression ?
• Associer des rôles aux agents : un agent de support peut lire les tickets, pas les supprimer. Un agent de reporting peut agréger des données, pas les modifier.
• Vérifier les permissions à chaque appel d'outil : chaque outil MCP exposé à l'agent doit vérifier en amont que l'agent (et l'utilisateur qui le pilote) dispose bien des droits requis.

Dans Laravel, des packages comme spatie/laravel-permission permettent de modéliser finement ces rôles et permissions. Le même outillage existe côté Symfony avec symfony/security-bundle et des voters personnalisés. L'important n'est pas le framework : c'est que la vérification des droits soit systématique, centralisée, et non contournable par l'agent.

MCP scoped : l'outil ne voit que ce que le tenant lui autorise

Le Model Context Protocol (MCP) est un standard émergent qui définit comment un LLM interagit avec des outils externes — bases de données, APIs, systèmes de fichiers. Chaque outil expose des fonctions que le modèle peut appeler. C'est puissant, et c'est précisément là que le cloisonnement doit s'opérer.

L'approche présentée dans l'article source consiste à rendre chaque outil MCP org-scoped : avant d'exécuter la moindre requête, l'outil résout le contexte organisationnel de l'appelant et filtre automatiquement toutes les données en conséquence. L'agent ne reçoit jamais de données hors de son périmètre — non pas parce qu'on espère qu'il ne les demandera pas, mais parce que techniquement, il ne peut pas y accéder.

Quelques principes d'implémentation :

1. Résolution du tenant en entrée de chaque outil : identifier l'organisation de l'utilisateur courant avant tout traitement.
2. Filtrage systématique des requêtes : toutes les requêtes base de données incluent un filtre sur l'identifiant du tenant, sans exception.
3. Aucune donnée cross-tenant dans le contexte de l'agent : le LLM ne voit jamais d'informations appartenant à un autre tenant, même partiellement.
4. Journalisation des appels d'outils : tracer ce que l'agent a fait, quand, et pour quel tenant — indispensable pour l'audit et la détection d'anomalies.

Cette architecture garantit que même si le modèle était compromis ou produisait des requêtes inattendues, les garde-fous structurels limitent le rayon d'impact.

Transposer ces principes à Symfony et PHP

Bien que l'article original soit ancré dans l'écosystème Laravel, les patterns décrits sont directement transposables à Symfony. Les voters Symfony permettent une gestion fine des permissions, y compris pour des entités custom comme un "agent IA" ou une "session MCP". Le composant Security offre tous les hooks nécessaires pour intercepter et valider chaque action avant exécution.

Pour le cloisonnement multi-tenant, des bibliothèques comme stancl/tenancy (Laravel) ont leurs équivalents conceptuels dans Symfony via des listeners Doctrine, des filtres SQL natifs, ou des solutions comme symfonycasts/rbac-bundle. L'essentiel est de ne jamais laisser le filtrage tenant à la discrétion de la couche applicative appelante — il doit être garanti au niveau de l'infrastructure d'accès aux données.

Enfin, si vous construisez votre propre serveur MCP en PHP, chaque outil déclaré doit embarquer sa propre logique d'autorisation. Ne pas déléguer cette responsabilité au client ou au LLM : l'outil est la dernière ligne de défense.

Conclusion : sécuriser l'IA, c'est sécuriser la confiance de vos clients

L'adoption des agents IA en entreprise n'est plus une question de si, mais de comment. Et le comment détermine si cette adoption crée de la valeur ou des incidents de sécurité. Pour les PME qui opèrent des plateformes SaaS, la question du cloisonnement des données n'est pas optionnelle : c'est une obligation contractuelle, réglementaire, et de réputation.

Donner à un agent IA les clés dont il a besoin — pas plus, pas moins — est l'approche viable. RBAC pour définir ce que l'agent peut faire. MCP scoped pour garantir qu'il ne voit que les données auxquelles il a droit. Et une architecture où ces contraintes sont structurelles, pas optionnelles.

Source originale : Giving an AI agent the keys without giving it the building: RBAC + org-scoped MCP tools in Laravel — Nasrul Hazim Bin Mohamad, DEV Community.