L’arrivée des agents IA connectés aux données d’entreprise change profondément la manière d’aborder la cybersécurité. Un agent ne doit plus être considéré comme un simple assistant conversationnel : dès lors qu’il peut lire, créer, modifier ou transmettre des informations, il devient un nouvel utilisateur du système d’information.
La question n’est donc plus seulement « que sait il répondre ? », mais également « que peut-il voir, que peut-il faire et comment l’arrêter ? »
Encadrer l’agent comme un utilisateur interne
Un agent IA doit être encadré en fonction des données auxquelles il peut accéder et des actions qu’il peut réaliser. Une mauvaise maîtrise de ses capacités peut conduire à des erreurs, des suppressions ou des fuites de données. Les connexions MCP pourraient amplifier ce phénomène parce que le déclenchement d’actions dépend désormais d’un LLM. L’entreprise PocketOS en a fait les frais quelques mois plus tôt lorsqu’un agent a supprimé l’ensemble des données de l’entreprise et leurs sauvegardes… alors même qu’ils lui avaient défendu de le faire !
En effet, le MCP, en tant que protocole de communication, ne fournit pas à lui seul toutes les couches de sécurité nécessaires. Autrement dit, adopter le MCP ne dispense pas d’appliquer les politiques dédiées de sécurité, d’identité, de segmentation et de supervision. Et oui, c’est bien à vous de construire votre propre politique autour des agents IA.
En outre, le piège serait de considérer que la menace ne vient que de l’extérieur, par exemple avec des prompts injection malveillants. Ce n’est pas nécessairement le cas : un agent IA mal circonscrit à un périmètre pourrait, en répondant à une demande légitime d’un collaborateur, causer tout autant de dégâts qu’une attaque externe.
Une chaîne de confiance fondée sur l’identité
Le premier principe consiste à aligner les capacités de l’agent uniquement avec les droits de l’utilisateur : c’est le principe de moindre privilège.
Il serait notamment recommandé :
- de vérifier l’identité de l’utilisateur
- de restreindre les outils visibles selon les permissions et droits de l’utilisateur en utilisant des jetons aux droits limités
- de ne publier dans le serveur MCP que le minimum nécessaire afin de limiter les actions
Le but est alors d’éviter qu’un agent permette à un utilisateur d’accéder à davantage de données que celles auxquelles il a normalement droit. Cette logique vise à rendre certains outils visibles et utilisables uniquement lorsque le jeton de la session l’autorise.
Prenons un exemple : l’utilisateur utilise un agent IA qui déclenche un client MCP. Un fournisseur d’identité du SI délivre alors un jeton d’accès qui est présenté au serveur MCP. Ce dernier valide ou non ce jeton, puis n’expose que les outils auxquels celui-ci donne droit. Chaque session est ainsi associée à des permissions déterminant les capacités effectivement accessibles à l’agent, et donc à l’utilisateur sous-jacent.
Ce mécanisme répond à une question centrale : comment éviter qu’un agent connecté à plusieurs outils puisse tous les utiliser indistinctement ?
Segmenter pour limiter les conséquences d’une compromission
La gouvernance technique devrait également prévoir des environnements dédiés, comme le fait d’héberger les serveurs MCP sur des réseaux isolés, sans privilèges administrateur et avec des accès filtrés.
Limiter l’exposition d’un serveur par des règles réseau ou des adresses autorisées permet aussi de réduire les possibilités d’exploitation en cas de compromission. En n’autorisant par exemple que les adresses provenant d’agents on limite les risques vis-à-vis des attaques visant les serveurs MCP. Avec ces protections, et à date, les pirates préfèrent d’ailleurs s’attaquer aux utilisateurs disposant de droits plutôt qu’aux serveurs directement.
Installer plusieurs niveaux de sécurité et d’arrêt d’urgence
Un agent capable d’enchaîner des actions doit pouvoir être interrompu rapidement. Voici plusieurs niveaux d’arrêt pouvant être mis en place :
- côté agent, avec un bouton d’interruption semblable au bouton « arrêt » présent sur les LLM grand public. Il permet alors à l’utilisateur d’arrêter sa session s’il soupçonne une certaine errance de l’agent.
- côté client, en mettant en place une durée maximale session, limitant de ce fait une trop longue exposition à un assaillant.
- côté serveur MCP, avec la possibilité de couper les accès d’une session. Un serveur pourrait contenir des règles sur le nombre d’appels APIs ou encore le volume de données maximal autorisé par session, permettant de couper les accès (circuit breaking).
- côté système d’information, avec un mécanisme permettant d’invalider les jetons en cas de compromission d’un utilisateur ou d’un poste.
- côté métier, avec une validation humaine avant certaines actions. Le recours à une validation est particulièrement pertinent pour les actions sensibles. Un agent peut, par exemple, préparer un email sans être autorisé à l’envoyer tant que l’utilisateur ne l’a pas validé.
L’objectif n’est pas de supprimer toute autonomie, mais de définir une autonomie proportionnée, observable et révocable. (voir mon autre article Gouverner les serveurs MCP : Sept règles pour passer du prototype à l’échelle pour une vue d’ensemble)
