Contexte et limites des IAM traditionnels

Les plateformes d’identité classiques décrivent les accès au moment de la conception (gestion du cycle de vie, définition de politiques, workflows d’on‑boarding) et au moment de l’exécution (authentification SSO, contrôle au périmètre). Elles ne capturent pas les actions réelles d’un agent autonome une fois à l’intérieur d’une application. Cette lacune, qualifiée d’écart « intent‑to‑execution », apparaît clairement dans le OWASP Top 10 pour les modèles de langage large (LLM06), qui identifie le risque d’« excessive agency » lorsqu’un agent dispose de permissions plus larges que son mandat.

Cycle de vie et risques des identités d’agents IA

Les identités d’agents sont souvent créées par des pipelines d’automatisation ou des équipes d’infrastructure, contournant ainsi les processus RH qui alimentent les contrôles humains. Le texte recense cinq modes d’échec récurrents : absence de propriétaire nommé, secrets persistants (clés API statiques), délégation non bornée, instanciation invisible et absence d’expiration. Chaque mode correspond à une couche de contrôle que le cadre IAM doit couvrir. Par exemple, les secrets à longue durée de vie augmentent la surface d’attaque car ils ne sont pas liés à un événement de rotation lors de la retraite de l’agent.

Composants essentiels d’un cadre IAM pour agents IA

Le cadre se décompose en trois axes : identité de l’agent, autorisation fine‑grained et traçabilité d’audit. L’identité doit être unique, jamais partagée avec un compte de service ou un credential humain, afin de garantir l’attribution des actions. Le OAuth 2.0 Token Exchange (RFC 8693) est recommandé pour déléguer des droits tout en conservant la distinction entre l’identité de l’agent et celle de l’utilisateur :

POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
subject_token=eyJhbGci...
subject_token_type=urn:ietf:params:oauth:token-type:access_token
resource=api.example.com

Du côté de l’autorisation, les contrôles NIST SP 800‑53 Rev. 5 (AC‑6, AC‑5, etc.) s’appliquent sans modification, mais le point d’application doit être rapproché de l’action. Les stratégies proposées incluent : octroi limité à la tâche (expiration synchronisée), listes blanches d’outils, frontières de données et seuils d’action nécessitant une approbation humaine.

Mise en œuvre et contrôles d’audit

Le NIST AI Risk Management Framework (AI 100‑1) exige que la traçabilité permette de reconstruire la séquence d’actions, pas seulement l’existence d’une politique. Ainsi, la collecte de télémétrie comportementale (analyse des appels d’API, séquences de prompts) doit être couplée à des journaux d’audit détaillés. Les contrôles d’audit (famille AU du SP 800‑53) sont validés uniquement si l’environnement peut démontrer ce que l’agent a réellement exécuté, par exemple via des traces de provenance de données ou des signatures de requêtes. En l’absence de visibilité, le cadre ne fournit que l’intention, pas la preuve d’exécution, ce qui limite la capacité de réponse aux incidents.