Quand l’IA passe à l’action: contrôle d’accès et Identity Access Management

Une bonne identité d’agent ne répond pas seulement à la question «Qui est-ce?». Elle se penche aussi sur trois autres questions qui, dans le cas des identités humaines, trouvent généralement une réponse implicite:

1. Qui est responsable (Owner)?
2. Pendant combien de temps l’identité est-elle valable (procédure)?
3. Au nom de qui l’agent agit-il actuellement (délégation)?

Tout comme un collaborateur dispose d’un compte utilisateur avec des attributs définis, l’agent IA dispose d’un profil propre complet. L’exemple suivant illustre l’identité d’un agent dans le service d’annuaires:

Le principe de base bien connu du moindre privilège (Least Privilege) s’applique également aux agents IA, mais il doit être repensé pour tenir compte de la réalité pratique hybride moderne entre l’homme et la machine.

Le principe du moindre privilège est le suivant: chaque entité ne reçoit plus que les autorisations dont elle a impérativement besoin pour une tâche concrète. Pour les utilisateurs humains ou les comptes système classiques, c’est une problématique largement résolue. Dans le cas des agents IA, ce modèle ne fonctionne plus dans sa forme classique, car trois hypothèses fondamentales ne sont plus valables:

• Les tâches ne sont pas prévisibles. Un agent reçoit souvent des instructions générales et décide lui-même des outils qu’il utilise pour s’acquitter de ses tâches.
• Les autorisations ne relèvent pas d’une décision binaire. Un agent autorisé à lire des e-mails peut, dans certaines circonstances, également envoyer, transférer ou supprimer des e-mails, en fonction de la granularité de l’API.
• Le contexte modifie le besoin de manière dynamique. Ce dont un agent a besoin pour la tâche A n’a pas d’importance pour la tâche B, mais l’autorisation reste valable.
  
  
  
  

A) Autorisations basées sur les tâches plutôt que sur les rôles
L’IAM classique attribue des rôles (p. ex. «Manager RH»). Pour les agents IA, une approche basée sur les tâches est plus efficace: l’agent ne reçoit que les autorisations nécessaires à la tâche actuelle spécifique, et celles-ci expirent automatiquement une fois la tâche terminée.

À la place: l’agent a un accès permanent enlecture à toutes les données financières
Mieux : l’agent obtient pour la tâche X un accès en lecture aux factures du T2 2026; valable pendant 15 minutes.

B) Scoped Tokens au lieu de clés API permanentes
Les clés API dotées d’un scope étendu sont l’équivalent d’une clé passe-partout. Pour les agents IA, il convient plutôt
d’utiliser des tokens de courte durée et strictement délimités, à l’instar des scopes OAuth, mais définis de manière plus granulaire au niveau des ressources.

C) Autorisations sau niveau des outils
Chaque outil mis à la disposition d’un agent doit être validé individuellement et explicitement, et non sous forme de
paquet. La règle d’or: si un outil n’est pas impérativement nécessaire pour le cas d’application défini, il n’est pas disponible.

D) Autorisations d’agent hiérarchiques dans les architectures multi-agents
Si un agent orchestrateur coordonne plusieurs sous-agents, aucun sous-agent ne peut obtenir plus d’autorisations que l’orchestrateur lui-même (voir la partie 1 de cette série). Les autorisations peuvent être déléguées, mais jamais transmises à un échelon supérieur. Dans la littérature spécialisée, ce principe est appelé le confinement des privilèges (Privilege Containment).

La réponse, courte, est la suivante: non, pas automatiquement. Seulement si l’architecture l’impose explicitement. Il s’agit là d’un point important qu’un CISO ne devrait pas minimiser: La traçabilité complète n’est pas une caractéristique propre aux agents IA. C’est une décision en matière d’architecture qui doit être intégrée activement. Sans ces précautions, trois lacunes apparaissent généralement:

1. Les chaînes de délégation se perdent. L’agent A mandate l’agent B, qui mandate à son tour l’agent C – si chaque transmission n’est pas explicitement consignée, il ne reste au final que la trace de ce qui s’est passé, sans que l’on sache pourquoi ni pour le compte de qui. Un agent n’agit pas simplement pour le compte d’une unité définie, mais reçoit une autorisation déléguée pour chaque action.

2. Le raisonnement n’est pas déterministe. Deux demandes identiques peuvent conduire à des actions différentes. Le «Pourquoi l’agent a-t-il décidé ainsi» ne peut souvent être reproduit qu’au moyen des étapes intermédiaires consignées (reasoning trace), mais cela n’est ni fiable ni précis.

3. Les outils de fournisseurs tiers sont des boîtes noires. Dès qu’un agent appelle une API externe ou un outil SaaS, sa propre visibilité s’arrête à la frontière du système.

La traçabilité est ainsi possible, mais uniquement avec des points de contrôle explicites tout au long de la chaîne
(delegation chain). Le fait est que sans une architecture solide, l’utilisation d’agents IA se transforme rapidement en une chasse aux indices en matière de d’analyse forensique, ce qui peut coûter cher.

C’est justement parce qu’IA agentique prend des décisions de manière autonome, utilise des outils et interagit avec des systèmes périphériques qu’il faut une provenance des décisions et des actions: chaque action pertinente doit être traçable sur les plans technique, organisationnel et professionnel. Cela s’inscrit également dans l’approche Zero Trust, qui vérifie chaque accès, ainsi que dans les approches de gouvernance de l’IA et de TRiSM, qui exigent surveillance, traçabilité, contrôle des données et des risques.

Alors que les facteurs 2 à 4 décrits sont axés sur la prévention, le facteur Accountability fournit la visibilité sans laquelle les principes du Least Privilege, le Context et la Continuous Verification resteraient aveugles. L’Accountability déploie un effet préventif apparaît dès lors qu’elle est associée à une évaluation en temps réel. La simple documentation devient ainsi un déclencheur de contre-mesures automatiques.

C’est là que les solutions SIEM/XDR entrent en jeu, en tant que trait d’union qui transforme l’Accountability orientée vers la détection en un contrôle réactif, en partie préventif, et placent les actions des agents dans le champ de vision du SOC. Pas sous forme de logs d’IA exotiques dans n’importe quelle pièce annexe, mais intégrées dans: SIEM, SOAR, XDR, IAM, DLP, journaux d’audit ERP, journaux de passerelle API, contexte CASB/SASE. SIEM (corrélation des logs) et XDR (détection et réponse intersystèmes) sont les niveaux qui tissent une image cohérente à partir de différentes tracesd’audit et en déduisent des actions.

Concrètement, il s’agit des quatre axes d’action suivants:

A) Corrélation au-delà des limites du système
Un accès d’agent unique au système A semble anodin. Ce n’est que lorsque SIEM découvre que le même agent accède dans les 90 secondes au système A, puis B, puis C, c’est-à-dire à des systèmes qui n’ont rien à voir entre eux sur le plan technique, qu’un schéma de «mouvement latéral» se forme. Cette corrélation est précisément ce qui rend exploitables la chaîne de délégation et les différents journaux d’agents.

B) Établissement d’un profil comportemental de base pour les agents
XDR apprend le comportement normal d’un agent: à quels systèmes un agent spécifique accède-t-il habituellement? À quelle fréquence? À quelles heures? Si le comportement diffère (comme l’accès à un système financier qui ne s’est jamais produit dans le profil normal), le système s’active. Il s’agit là d’une détection d’anomalies appliquée aux identités non humaines.

C) Réponse automatique comme levier préventif
C’est là qu’a lieu la transformation: on passe de quelque chose qui a été identifié à quelque chose qui est empêché. Ainsi, des playbooks définis peuvent par exemple être déclenchés immédiatement, par exemple en cas de mouvement latéral détecté:

• Invalider immédiatement le token de l’agent
• Isoler la session de l’agent / la mettre en quarantaine
• Bloquer temporairement les systèmes concernés pour cet ID d’agent
• Déclencher une escalade vers un opérateur humain

Point décisif: cette réponse automatisée intervient en quelques secondes, c’est-à-dire pendant l’incident, et non des heures plus tard lors de l’analyse du journal. Cela permet d’éviter tout autre mouvement latéral, même si le premier a déjà eu lieu. La propagation est empêchée, et le rayon d’impact est ainsi efficacement limité.

D) Impact sur Least Privilege, Context et Continuous Verification
Les résultats SIEM/XDR sont réinjectés dans le Policy Engine: un agent détecté peut automatiquement être soumis à des règles de Continuous Verification plus strictes ou être rétrogradé au niveau de ses autorisations (Least Privilege). La boucle entre les contrôles de détection et les contrôles préventifs est ainsi bouclée.

Pour l’architecture, cela signifie concrètement que: les journaux d’Accountability n’ont aucune valeur s’ils sont uniquement enregistrés dans une archive que personne n’évalue en temps réel. La valeur n’apparaît qu’au moment du couplage. Les traces d’audit des agents doivent être intégrées de manière native et structurée au pipeline SIEM/XDR, avec l’ID de l’agent, la chaîne de délégation et le contexte comme champs de corrélation. Ce n’est qu’ensuite que l’on passe de «Nous savons qui est responsable.» à «Nous l’arrêtons pendant que cela se passe.»

Ce que cela signifie concrètement pour vous en tant que CISO
Le principe du moindre privilège reste valable, mais il doit être mis en œuvre pour les agents IA.
Trois mesures avec effet immédiat:

1. Introduire l’accès  «just in time»: les autorisations sont délivrées à la demande pour une période et un champ d’application définis, puis retirées automatiquement.
2. Créer un Agent Identity Registry: chaque agent IA reçoit sa propre identité unique dans le service d’annuaires, avec des autorisations, un propriétaire et un cycle de révision définis.
3. Établir les audits d’autorisation pour les agents en tant que processus régulier: pas chaque année, mais à chaque modification du profil des tâches d’un agent.

En principe, l’objectif ne devrait pas être de limiter les autorisations des agents IA mais de garantir la plus petite surface d’attaque possible avec une fonctionnalité maximale. Est-ce une question de philosophie de la sécurité? Non. C’est une question d’architecture du système. La question centrale n’est plus: «De quelles autorisations un agent IA a-t-il besoin?», mais: «Quel degré de confiance cet agent bénéficie-t-il pour quelle tâche et à quelles conditions?»

Il en résulte un modèle d’autorisation moderne reposant sur cinq principes clés, que l’on peut résumer dans la formule suivante, laquelle sert de fil conducteur structurel :
Identity × Least Privilege × Context × Continuous Verification × Accountability = capacité d’action contrôlée des agents IA
La logique multiplicative de l’enchaînement «Qui → Quoi → Pourquoi → Encore valable? → Qui est responsable» montre qu’un seul facteur négligé réduit à néant la sécurité globale. Un agent IA peut être parfaitement identifié, disposer des autorisations strictement nécessaires, être sensible au contexte et faire l’objet d’une vérification complète. Si aucune responsabilité ne peut être attribuée en cas de sinistre (Accountability = 0), l’ensemble du modèle est sans valeur du point de vue de la gouvernance.

Résumé des principes de base:

1. Identity first: chaque agent possède une identité unique.
2. Least Privilege: droits minimaux liés aux tâches au lieu d’accès forfaitaires. 
3. Context: les autorisations changent en fonction de la situation, du risque et de l’objectif.
4. Continuous Verification: il s’agit de l’ancrage Zero Trust, c’est-à-dire que chaque action est contrôlée et autorisée en continu.
5. Full Accountability: chaque décision et chaque action d’un agent sont traçables et attribuées à un service responsable.

Ce modèle suit l’approche de sécurité Zero Trust et s’associe facilement à des concepts actuels tels que l’Agentgent Identity, la gouvernance de l’IA et l’AI TRiSM (AI Trust, Risk and Security Management), qui s’établissent de plus en plus comme référence pour une utilisation sûre del’intelligence artificielle agentique.

Les bonnes pratiques suivantes servent de guide pour les agents IA dans le cadre de l’IAM:

• Human-in-the-Loop (HITL): les actions critiques (p. ex. l’envoi d’offres ou de modifications de contrat) doivent être approuvées par des collaborateurs humains avant leur exécution.
• Utilisation de passerelles IA: utilisez des interfaces et des passerelles standardisées (p. ex. passerelles IA) pour surveiller et consigner les accès de l’IA.