Un sujet sous-estimé en 2025-2026 : les agents IA sont des identités non humaines (NHI) qui agissent dans le SI. Si vous n'avez pas d'IAM pour les agents, vous avez un trou de gouvernance. Voilà comment je le structure en mission.
Pourquoi l'agent est une NHI à part entière
Un agent IA :
- A une identité (un identifiant unique, un nom).
- A des credentials (token API, clé MCP, parfois une certificate).
- A des permissions (accès à des données, des tools, des actions).
- Effectue des actions (lectures, écritures, appels externes).
- Est traçable (logs, audit trail).
C'est par définition une identité. Si vous ne la gérez pas comme telle, elle dérive : permissions excessives, credentials non rotatés, audit trail incomplet.
En 2026, beaucoup de programmes IAM commencent à intégrer les agents au même titre que les service accounts. C'est le bon réflexe.
Le canevas que je propose
Étape 1 — Inventaire des agents
Pour chaque agent en prod ou en POC :
- Nom et description.
- Owner (équipe métier).
- Owner technique (qui maintient le code).
- Cas d'usage métier.
- Modèle LLM utilisé.
- Accès aux données (RAG, bases, vector DB).
- Tools exposés (MCP, function calls).
- Niveau d'autonomie (humain-in-the-loop / supervisé / autonome).
Sans inventaire, pas de gouvernance.
Étape 2 — Identité formelle dans l'IAM
Créer pour chaque agent :
- Un compte de service dédié (jamais partagé entre agents).
- Des credentials gérées par le secrets manager (rotation planifiée).
- Une appartenance à des groupes/rôles avec ACL claires.
Idéalement, intégration dans le même IAM que les utilisateurs humains et les service accounts existants (Okta, Entra ID, AWS IAM, etc.).
Étape 3 — Permissions least-privilege
Pour chaque agent, le principe :
- Données : accès uniquement aux datasets/RAG strictement nécessaires.
- Tools : accès uniquement aux tools MCP / function calls strictement nécessaires (voir sécurité MCP).
- Actions externes : aucune par défaut, à activer explicitement avec workflow de validation humaine.
Revue trimestrielle des permissions, mêmes règles que pour les humains.
Étape 4 — Niveau d'autonomie explicité
Documenter et coder le niveau d'autonomie de chaque agent :
| Niveau | Description | Use case typique | |---|---|---| | L0 | Lecture seule, retourne du texte | Assistant Q&A | | L1 | Écriture interne sans effet externe (notes, logs) | Assistant rédaction | | L2 | Action externe avec validation humaine systématique | Assistant ops avec exécution | | L3 | Action externe autonome dans scope défini | Agent automation reportée | | L4 | Action externe autonome avec escalation conditionnelle | Agent autonome avancé |
Le niveau d'autonomie est une configuration de l'agent, pas une propriété immuable. On peut élever ou rabaisser selon les retours d'expérience.
Étape 5 — Rotation et expiration
- Credentials rotation tous les 90 jours minimum.
- Tokens d'agent à durée courte (heures, pas jours).
- Désactivation automatique des agents inactifs > N jours.
- Re-approbation périodique du périmètre de l'agent par son owner métier.
Étape 6 — Monitoring et alerting
- Métriques par agent : nombre d'actions/jour, taux d'erreur, taux de validation humaine.
- Alertes : volume anormal (×3 baseline), patterns suspects, échecs d'authentification.
- Dashboard global de l'IAM agents accessible au CISO/CTO.
Étape 7 — Procédure d'incident
- Si comportement suspect : kill-switch en < 30 secondes (voir migration chatbot vers agent).
- Si compromission confirmée : runbook 72h, gestion incident (voir incident sécurité IA).
Le cas spécifique des agents qui appellent des agents
Si vos agents s'appellent entre eux (orchestration multi-agents), chaque agent a sa propre identité. Pas d'identité "partagée orchestrateur". Sinon vous perdez la traçabilité.
Voir jailbreak transitif quand un agent appelle un autre LLM pour les risques techniques.
Les pièges que je vois revenir
Utiliser un compte humain pour l'agent
"On utilise mon compte API pour faire tourner l'agent". Mauvaise idée : permissions excessives, traçabilité polluée, rotation impossible. Toujours un service account dédié.
Pas d'inventaire des agents
Une équipe me dit "on a 3 agents". Trois mois plus tard, le scan IAM trouve 17 service accounts qui tapent sur les API LLM. Faire l'inventaire d'abord.
Permissions héritées du dev
L'agent a été développé avec un compte dev qui a tous les droits. Mis en prod sans réduction des permissions. Faire le least-privilege au moment du go-live, pas après.
Pas de revue périodique
L'agent était utile en 2025, plus en 2026, mais ses credentials et accès sont toujours actifs. Revue trimestrielle minimum.
Mélanger NHI agents et NHI service classiques
Les agents IA ont des spécificités (niveau d'autonomie, monitoring comportemental). Ils méritent une catégorie distincte dans l'IAM, pas une fusion avec les service accounts classiques.
Mon avis en 1 ligne
Un agent IA est une identité non humaine à gérer comme telle : inventaire, identité IAM dédiée, least-privilege, rotation, monitoring, kill-switch. Compter 4-6 semaines pour structurer l'IAM agents dans une organisation qui a déjà un IAM mûr, plus si l'IAM est immature ou shadow. C'est l'investissement qui rend les agents pilotables sans devenir une dette de sécurité.