Tu colles une clé API dans ton agent. Une ligne dans un fichier .env. Ça marche tout de suite.
Mais cette clé, c'est la tienne. Tes accès, ta portée, ton nom sur chaque appel.
Tu viens de donner ton identité à un logiciel qui écrit ses propres commandes.
Un agent n'est pas toi. C'est un nouvel acteur sur ton système. Il lui faut la sienne.
TL;DR : une clé API statique dans un agent, c'est ton identité que tu prêtes. Large, sans date de fin, partagée, impossible à tracer. Un agent IA est une identité non-humaine, un acteur à part entière. Donne-lui la sienne : un jeton court, limité à son besoin, révocable, et attribuable dans les logs. La direction de l'industrie porte un nom, l'identité de workload, type SPIFFE. Pas un secret partagé qui traîne dans un
.env.
Cet article est pour les devs et les DevSecOps qui mettent un agent IA en production, avec accès à de vrais systèmes. Pas en démo.
Le contexte
Un agent IA, c'est un modèle de langage qui appelle des outils et agit à ta place. J'en construis un en Go, dans un projet perso.
La stack est classique. Go pour le code. Postgres pour les données. Un cluster Kubernetes pour l'héberger. Et l'API d'Anthropic pour le modèle.
Pour ses secrets, l'agent ne lit aucune clé écrite à la main. Il porte une identité machine dédiée. Elle est limitée à un projet, un environnement, un chemin. J'auto-héberge Infisical pour ça. Infisical est un gestionnaire de secrets : un coffre qui range et distribue les clés.
Je viens de la sécurité, et je suis un peu parano. Certifié pentester, ancien Top 1% sur TryHackMe. Donner mon identité à un agent, c'était non.
Une clé API statique, c'est ton identité que tu prêtes
Regarde ce que fait une clé API statique. Elle prouve qui tu es, une fois pour toutes. Et souvent, la même clé sert partout.
# .env : la mauvaise idée
ANTHROPIC_API_KEY=sk-ant-...
DATABASE_URL=postgres://app:motdepasse@db/prod
STRIPE_KEY=sk_live_...Une clé comme ça a quatre défauts. Elle est large : elle ouvre tout ce que ton compte peut faire. Elle est éternelle : aucune date de fin. Elle est partagée : le même secret sert à dix endroits. Et elle est muette : un log dit « la clé a agi », jamais « l'agent a agi ».
Le problème explose en 2026. Les secrets liés à l'IA sont la catégorie de fuites qui grimpe le plus vite. GitGuardian en a compté 1,27 million rien qu'en 2025, soit 81 % de plus qu'en 2024. Pire : 64 % des secrets valides fuités en 2022 n'étaient toujours pas révoqués début 2026.
Pourquoi l'IA aggrave tout ? Parce qu'elle multiplie les acteurs. Plus d'agents, plus de services, plus de jetons qui traînent. Chaque clé posée à la main est une fuite qui attend son heure.
Ton agent est une identité non-humaine, traite-le comme tel
En sécurité, on sépare deux mondes. Les identités humaines : toi, tes utilisateurs. Et les identités non-humaines : les services, les scripts, les robots.
Une identité non-humaine, la NHI, c'est tout ce qui s'authentifie sans être une personne. Un agent IA en fait partie. C'est un acteur à part entière, comme un compte de service.
Et ces acteurs sont déjà les plus nombreux. Dans un cloud moderne, les machines dépassent les humains de plusieurs dizaines pour un. L'agent IA est juste le petit dernier. Le plus rapide, et le plus imprévisible.
Attention à ne pas confondre deux identités. Il y a l'utilisateur au nom de qui l'agent agit. Et il y a l'agent lui-même. Ce sont deux choses distinctes. L'agent a besoin de sa propre identité, séparée de la tienne et de celle de l'utilisateur.
Dans mes services, ça donne deux chemins. Quand l'agent agit pour un utilisateur, je propage le jeton de cet utilisateur, de bout en bout. Quand c'est une tâche système, sans personne derrière, un jeton de service à service prend le relais. Jamais les deux sur le même appel. L'agent n'invente jamais d'identité. Soit il porte celle de l'utilisateur, soit la sienne.
Donne-lui un jeton court, jamais un secret éternel
La première règle est simple. Remplace le secret éternel par un jeton court.
On appelle ça un jeton juste-à-temps, ou JIT. L'idée : l'agent ne garde pas une clé pour toujours. Il prouve qui il est, reçoit un jeton qui vit quelques minutes, puis ce jeton meurt.
Le gain se voit le jour d'une fuite. Un secret statique volé marche jusqu'à ce que tu le remarques. Souvent, des mois plus tard. Un jeton court, lui, est déjà mort quand le voleur arrive.
Dans mon projet, l'agent ne connaît aucune clé de prod. Il porte une identité machine. Avec elle, un opérateur va chercher ses secrets et les renouvelle tout seul, en continu.
# L'identité machine de l'agent, limitée à son périmètre
projectSlug: mimmo
envSlug: prod
secretsPath: /backend/mimmo-ai # rien d'autre
resyncInterval: 60 # renouvelé en continuMême logique côté outillage. Pour mes automatisations, je préfère une app qui fabrique un jeton à la volée, pas un jeton personnel qui traîne. L'app prouve son identité, reçoit un jeton qui vit une heure, agit, puis le jeton expire. Rien de permanent à stocker, rien à faire fuiter.
Deux réflexes vont avec. Un : fais tourner les identifiants souvent, c'est la rotation. Deux : garde un bouton rouge. Le jour où un agent part en vrille, tu dois pouvoir couper son identité en une commande, sans casser les neuf autres.
Limite l'identité à ce dont l'agent a besoin
Un jeton court, c'est bien. Un jeton court et étroit, c'est mieux.
Le principe est le moindre privilège : donne juste les droits utiles, rien de plus. Appliqué à l'identité, ça donne une règle nette. Une identité par agent. Pas une clé unique partagée par toute ta flotte.
Pourquoi ? Une injection, c'est un texte piégé qui détourne l'agent de sa tâche. Si elle réussit, l'attaquant hérite des droits de l'agent en cours. Avec une identité étroite, les dégâts s'arrêtent là. Avec la clé maîtresse, tout tombe.
J'ai vu l'autre approche de près, sur une plateforme d'identité à grande échelle. Les droits n'y étaient pas de simples rôles figés. Ils se décidaient par attributs, à chaque requête. On appelle ça l'ABAC. Qui es-tu, dans quel contexte, pour quelle ressource : la réponse se calcule à la demande.
Un agent mérite le même traitement. Son identité ne dit pas juste « c'est un agent ». Elle porte des attributs : quel agent, quel environnement, quel périmètre. Et l'accès se décide à partir de là.
Rends chaque action attribuable à l'agent
Une identité propre offre un cadeau : la traçabilité.
Avec une clé partagée, ton log dit « le compte de service a supprimé le dossier ». Merci, mais qui ? Quel agent, quelle session, sur ordre de quel humain ?
Avec une identité par agent, la réponse est dans la ligne de log. Tu sais quel acteur a agi, quand, et pour qui. C'est la non-répudiation : personne ne peut nier son action.
Ce n'est pas mon idée. Le NIST pousse un cadre pour l'identité des agents. Il tient en quatre mots : identifier l'agent, l'autoriser, l'auditer, et lier chaque action à l'humain qui l'a permise.
Concrètement, chaque appel de mon agent part dans un log structuré : quelle identité, quel outil, quelle décision. Le jour d'un incident, je réponds à une seule question. Qu'a fait cet agent, exactement ?
La cible : une identité de workload, type SPIFFE
Où va tout ça ? Vers une identité cryptographique pour chaque charge de travail. En anglais, workload identity.
Le standard qui monte s'appelle SPIFFE, avec sa mise en œuvre SPIRE. L'idée est belle. Chaque service reçoit une identité vérifiable, prouvée par la cryptographie, et à durée de vie courte. Plus de secret partagé à copier d'un endroit à l'autre.
# Une identité de workload, pas une clé partagée
spiffe://mimmo.app/agent/legal-advisor
# → un identifiant court, renouvelé tout seul, vérifiableEt pour les agents IA ? La bascule est en cours, en haut lieu. Le NIST a lancé une initiative dédiée aux agents en février 2026. Son texte sur l'identité des agents cite OAuth, OpenID Connect et SPIFFE. Un brouillon à l'IETF décrit un modèle d'identité pour les agents, l'AIMS, bâti sur ces mêmes standards. Et l'OWASP classe l'excès d'autonomie parmi les grands risques des applications à agents.
Sois honnête sur la maturité. SPIFFE en production pour des agents, c'est jeune. Je regarde cette direction de près, sans prétendre l'avoir déployée partout. Mais le principe, lui, est déjà applicable. Identité courte, étroite, révocable, tracée. Tu n'as pas besoin d'un standard final pour arrêter de coller ta clé dans un .env.
La checklist avant de donner un accès
Avant de brancher ton agent IA sur de vrais systèmes, passe son identité au crible.
- L'agent a sa propre identité, séparée de la tienne et de celle de l'utilisateur
- Aucune clé statique dans un
.envni dans le code - Un jeton court à la place du secret éternel, renouvelé tout seul
- Une identité par agent, jamais une clé maîtresse partagée
- L'identité est limitée : un projet, un environnement, un périmètre
- L'accès se décide par attributs, pas par un rôle figé (ABAC)
- Un bouton rouge : tu peux révoquer une identité en une commande
- Rotation régulière des identifiants
- Chaque action est loggée avec l'identité de l'agent, pour la non-répudiation
- Les secrets vivent dans un gestionnaire dédié, scannés à chaque commit
- La cible : une identité de workload vérifiable, type SPIFFE
Ce qu'il faut retenir
Une clé API répond à « quel accès ». Une identité répond à « qui agit ». Ton agent a besoin de la seconde.
Ne lui prête pas ton identité. Donne-lui la sienne : courte, étroite, révocable, tracée. C'est la différence entre un acteur que tu contrôles et un secret que tu pries de ne pas voir fuiter.
Les standards arrivent. Les identités machines explosent. Les devs qui savent donner une identité propre à un agent, et pas juste une clé, vont rester rares un moment.
Tu mets un agent IA en production ? Tu veux revoir comment il s'authentifie, avant qu'une clé ne fuite ? C'est exactement ce que je fais. Écris-moi.