Agents IA : qui contrôle leurs accès ?

Le vrai risque : des droits trop larges, jamais revus

Dans la majorité des déploiements, l'agent hérite d'un compte de service ou d'une clé d'API créée « pour aller vite ». Ce secret donne souvent accès à bien plus que le nécessaire, n'expire jamais et n'apparaît dans aucune revue d'habilitations.

Ajoutez l'injection de prompt (un document piégé qui pousse l'agent à exfiltrer des données) et vous obtenez un compte à privilèges piloté par du texte non maîtrisé.

Les bons réflexes IAM appliqués aux agents

Les standards existent déjà : il s'agit de les appliquer avec rigueur.

• Une identité propre par agent, enregistrée dans l'annuaire ou l'IDP, avec un propriétaire métier identifié.
• OAuth 2.0 avec délégation (token exchange, RFC 8693) : l'agent agit au nom de l'utilisateur, jamais avec plus de droits que lui.
• Des jetons courts et des scopes minimaux plutôt que des clés d'API permanentes.
• Une autorisation fine à l'exécution (ABAC, OPA) pour les actions sensibles, avec validation humaine si nécessaire.
• Une traçabilité complète : quel agent, pour quel utilisateur, quelle action, sur quelle donnée.

Et MCP dans tout ça ?

La spécification MCP s'appuie sur OAuth 2.1 pour autoriser les clients auprès des serveurs MCP. C'est une bonne nouvelle : vos serveurs MCP peuvent se brancher sur votre IDP existant (Entra ID, Okta, Keycloak, Ping…) au lieu de réinventer un mécanisme d'authentification.