Agents IA dans le SI : MCP, permissions et traçabilité

Un agent IA est un système dans lequel un modèle de langage décide lui-même quels outils appeler, dans quel ordre et avec quels paramètres, pour atteindre un objectif : interroger une base, créer un ticket, modifier un enregistrement, envoyer un message. Le risque se déplace donc de ce que le modèle dit vers ce qu'il fait. Intégrer des agents IA dans le SI sans perdre le contrôle repose sur quatre garde-fous : des outils et des permissions au plus juste, une identité et une autorisation explicites pour chaque accès, une validation humaine pour les actions à impact, et une traçabilité de bout en bout.

L'OWASP résume le problème sous le nom d'« agentivité excessive », avec trois causes : des fonctionnalités excessives (un outil capable de supprimer alors qu'il ne devait que lire), des permissions excessives sur les systèmes en aval et une autonomie excessive, quand les actions à fort impact ne sont pas vérifiées avant exécution 1.

Le protocole MCP standardise désormais la connexion entre agents et outils. C'est un progrès pour l'intégration, mais pas un dispositif de sécurité en soi : il faut encore décider qui peut faire quoi, et le prouver.

Ce qui change quand un modèle peut agir

Avec un assistant conversationnel, une erreur produit une mauvaise réponse qu'un humain lit avant d'agir. Avec un agent, une erreur produit directement une action dans un système de production. Et l'erreur n'est pas seulement accidentelle : un agent lit des courriels, des pages web, des tickets ou des documents qui peuvent contenir des instructions malveillantes, et ces contenus peuvent détourner son objectif.

La conséquence d'architecture est simple : la décision d'autoriser une action ne doit jamais reposer sur le modèle. L'OWASP recommande une « médiation complète », c'est-à-dire l'application des contrôles d'autorisation dans les systèmes en aval plutôt que de compter sur le LLM pour juger si une action est permise, ainsi que l'exécution des outils dans le contexte de l'utilisateur concerné, avec des privilèges minimaux 1.

Le protocole MCP : un standard de connexion, pas une politique de sécurité

Le Model Context Protocol (MCP) définit, sur la base de messages JSON-RPC 2.0, la communication entre des hôtes (les applications d'IA), des clients intégrés à ces hôtes et des serveurs qui exposent des ressources, des prompts et des outils. La spécification en vigueur à la date de rédaction porte la version 2026-07-28 2. Initié par Anthropic, le protocole a été confié en décembre 2025 à l'Agentic AI Foundation, un fonds dirigé hébergé par la Linux Foundation 3.

La spécification pose des principes clairs : consentement explicite de l'utilisateur avant l'exposition de données et avant l'invocation de tout outil, et prudence vis-à-vis des descriptions d'outils, à considérer comme non fiables sauf si elles proviennent d'un serveur de confiance. Elle précise surtout que MCP ne peut pas imposer ces principes au niveau du protocole : c'est aux implémentations de construire les flux de consentement, d'autorisation et de contrôle d'accès 2.

Authentifier et autoriser les serveurs MCP

Pour les transports HTTP, la spécification d'autorisation s'appuie sur OAuth 2.1. Le client doit indiquer le serveur visé grâce aux indicateurs de ressource (RFC 8707), le serveur doit vérifier que chaque jeton a bien été émis pour lui, et il lui est interdit d'accepter ou de relayer d'autres jetons. Pour un serveur local en transport stdio, les identifiants proviennent de l'environnement 4.

Le guide de bonnes pratiques de sécurité du protocole détaille les attaques à prévenir : relais de jetons (token passthrough), problème du « député confus » pour les serveurs MCP qui servent de mandataire vers des API tierces, compromission de serveurs locaux exécutant du code sur le poste. Il recommande des portées minimales au départ, élevées progressivement au moment où une opération privilégiée est tentée, et proscrit les portées génériques du type « tout accès » 5.

La décision d'autoriser une action ne doit jamais reposer sur le modèle lui-même.

Permissions : concevoir les outils au plus juste

L'essentiel de la sécurité d'un agent se joue dans la conception de ses outils. Le Top 10 OWASP des applications agentiques, publié en décembre 2025, place parmi les risques majeurs le détournement d'objectif de l'agent, le mésusage d'outils, l'abus d'identité et de privilèges et les vulnérabilités de la chaîne d'approvisionnement agentique 6. Les règles de conception suivantes réduisent directement ces risques :

Des outils étroits et spécialisés plutôt que génériques : « créer un ticket dans telle file » plutôt qu'un accès libre à l'API ou à un interpréteur de commandes.
La lecture seule par défaut, l'écriture uniquement là où elle est nécessaire, et jamais de suppression sans validation.
Une identité propre à chaque agent, distincte des comptes de service partagés, et des actions exécutées avec les droits de l'utilisateur pour lequel l'agent travaille.
Un registre interne des serveurs MCP autorisés, avec revue de sécurité avant inscription et version figée, plutôt que l'installation libre de serveurs trouvés en ligne.
Des flux sortants filtrés pour limiter ce qu'un agent détourné pourrait exfiltrer.
Une revue régulière des droits accordés aux agents, au même titre que ceux des comptes à privilèges.

L'ANSSI formule une exigence voisine pour les outils d'IA générative intégrés aux applications métier : effectuer une revue régulière de la configuration de leurs droits 7.

Validation humaine : où placer le curseur

Faire tout valider par un humain annule l'intérêt de l'agent ; ne rien faire valider expose à des actions irréversibles. L'ANSSI recommande de proscrire l'usage automatisé de systèmes d'IA pour des actions critiques sur le SI et de limiter les actions automatiques déclenchées par un système d'IA qui traite des entrées non maîtrisées 7. L'OWASP préconise une approbation humaine pour les actions à fort impact 1. Une classification simple des actions permet de placer le curseur :

Lecture et recherche dans le périmètre de l'utilisateur : exécution automatique, journalisée.
Écriture réversible et interne (brouillon, ticket, commentaire) : exécution automatique avec notification, ou validation par échantillonnage.
Action irréversible, financière, ou visible de l'extérieur (paiement, suppression, envoi à un client, modification de droits) : validation humaine systématique.
Action critique sur le SI (configuration, déploiement, gestion des accès) : hors du périmètre des agents autonomes.

La validation elle-même doit être conçue avec soin. Le Top 10 agentique de l'OWASP identifie l'exploitation de la confiance entre l'humain et l'agent comme un risque à part entière 6 : un écran de validation qui affiche le résumé rédigé par l'agent, plutôt que les paramètres réels de l'action (destinataire, montant, enregistrement modifié), finit par être approuvé machinalement.

Traçabilité : reconstituer les décisions des agents IA

En cas d'incident, il faut pouvoir répondre à des questions précises : quel utilisateur a lancé la tâche, quelle version de l'agent et de ses prompts était active, quels contenus il a lus, quels outils il a appelés avec quels paramètres, qui a validé quoi. L'ANSSI recommande de journaliser l'ensemble des traitements réalisés au sein d'un système d'IA 7.

Les conventions sémantiques d'OpenTelemetry pour l'IA générative, encore au statut de développement, prévoient des métriques spécifiques aux agents et aux outils, comme la durée d'exécution d'un agent, le nombre d'appels d'outils par exécution ou la durée de chaque appel d'outil 8. S'appuyer sur ce vocabulaire ouvert, avec un identifiant de corrélation propagé de l'agent jusqu'à l'API appelée, permet de relier une action en base de données à la conversation qui l'a déclenchée.

Avant d'ouvrir un agent en production, vérifiez au minimum que :

chaque outil exposé a un propriétaire, un périmètre documenté et des droits minimaux ;
l'agent agit avec une identité traçable et, pour le compte d'un utilisateur, avec les droits de celui-ci ;
les actions à impact passent par une validation qui affiche les paramètres réels ;
les jetons sont émis pour un serveur donné et ne sont jamais relayés ;
chaque appel d'outil est journalisé avec l'identité, les paramètres, le résultat et la validation éventuelle ;
un interrupteur permet de suspendre l'agent immédiatement sans arrêter le service métier.

Conclusion

Les agents IA apportent un gain réel lorsqu'ils enchaînent des tâches répétitives à travers plusieurs systèmes, mais ils transforment chaque faille de permission en risque opérationnel. MCP facilite la connexion ; la maîtrise vient de la conception des outils, de l'autorisation déléguée, d'une validation humaine bien placée et d'une traçabilité exploitable. DATASWING accompagne ces projets de la définition des cas d'usage jusqu'à l'intégration sécurisée des agents dans le SI existant.

agents IA Model Context Protocol sécurité des agents IA validation humaine

— Questions fréquentes

Ce qu'on nous demande souvent

Qu'est-ce que le protocole MCP ?

Le Model Context Protocol est un protocole ouvert qui standardise la connexion entre les applications d'IA et des sources de données ou des outils externes. Il repose sur JSON-RPC 2.0 et distingue hôtes, clients et serveurs, qui exposent ressources, prompts et outils. Confié fin 2025 à l'Agentic AI Foundation de la Linux Foundation, il ne fournit pas à lui seul de politique de sécurité.

Comment sécuriser un agent IA en entreprise ?

En limitant ses outils au strict nécessaire, en lui donnant une identité propre et des droits minimaux, en faisant appliquer les autorisations par les systèmes cibles plutôt que par le modèle, en imposant une validation humaine pour les actions irréversibles ou externes, et en journalisant chaque appel d'outil. Les serveurs MCP utilisés doivent être inscrits dans un registre interne après revue.

Faut-il une validation humaine pour toutes les actions d'un agent IA ?

Non. Une classification des actions permet d'automatiser la lecture et les écritures réversibles, tout en exigeant une validation humaine pour les actions irréversibles, financières ou visibles de l'extérieur. L'ANSSI recommande d'exclure l'automatisation des actions critiques sur le SI. L'écran de validation doit montrer les paramètres réels de l'action, pas un résumé rédigé par l'agent.

Quels sont les principaux risques des agents IA ?

Le Top 10 OWASP des applications agentiques cite notamment le détournement de l'objectif de l'agent par des contenus malveillants, le mésusage d'outils, l'abus d'identité et de privilèges, les vulnérabilités de la chaîne d'approvisionnement, l'exécution de code inattendue, l'empoisonnement de la mémoire et les défaillances en cascade entre agents.

— Sources