L'identité des agents est une infrastructure de production

L'identité est descendue sous la boîte de chat

L'IA agentique ne se contente plus de répondre. Elle choisit des outils, appelle des API, touche des fichiers et peut modifier un état externe. L'authentification à l'entrée ne suffit donc plus. La question de production devient : quelle identité agit, pour qui, avec quelle capacité, pour quelle tâche et pour combien de temps ?

En août 2026, NIST décrit un schéma connu : les organisations privilégient la vitesse produit avant une base d'identité solide pour les agents. Avec des agents, cette lacune peut devenir action non autorisée, accès excessif, approbation introuvable ou secret qui survit à la tâche.

Le modèle ne doit pas devenir le principal

Le principal de sécurité doit être une identité de charge bornée créée par le harness pour une tâche précise. Le modèle propose ; l'environnement autorise. L'autorisation reste ainsi hors du prompt et de la mémoire contrôlée par le modèle.

La chaîne utilisateur, session produit, exécution d'agent, appel d'outil et service aval doit porter ses preuves : dépôt, branche, raison, identifiant de tâche et fenêtre temporelle pour un accès code ; contenu exact et effet exact pour une publication.

• Séparer identité utilisateur et identité de charge de l'agent
• Émettre des identifiants courts par tâche
• Autoriser les outils côté serveur
• Journaliser décision, entrée, sortie et rollback pour chaque écriture

La capacité est l'unité du moindre privilège

Les rôles sont trop larges pour les agents. Une exécution a souvent besoin d'un dépôt, d'une branche et de quelques opérations. Chaque outil doit être une capacité avec entrées typées, préconditions, postconditions, budgets et expiration.

Cette approche réduit aussi la fatigue d'autorisation. Les lectures sûres et contrôles déterministes n'ont pas besoin d'interrompre l'utilisateur ; gardez l'humain pour publier, supprimer, dépenser, accorder un accès ou transmettre des données sensibles.

L'audit trail doit survivre à l'incident

Il faut conserver intention, versions du modèle et du prompt, preuves, capacités accordées, entrées et sorties d'outils, décisions de politique, ids fournisseur et effets finaux. Sinon impossible de distinguer suggestion défaillante, bug de harness, identifiant volé ou mauvaise approbation.

L'incident Hugging Face publié par OpenAI en juillet 2026 montre l'intérêt de reconstruire les trajectoires : Hugging Face a reconstitué des milliers d'actions sur plusieurs jours. Identité et télémétrie doivent précéder le premier incident sérieux.

La checklist de production

Commencez par deny-by-default. Donnez un identifiant à chaque run, attachez des capacités explicites, passez les secrets par un broker au dernier moment, limitez le réseau et rendez les écritures idempotentes. Répétez révocation, quarantaine et conservation des preuves sans fuite de secret.

Un bon système est explicable : quelle identité a agi, pourquoi, ce qui a changé, comment revenir en arrière et quelle alerte se déclenchera la prochaine fois.