Pourquoi les agents fantômes sont une bombe à retardement pour la gouvernance

Toute entreprise qui a dépassé le stade du pilote en IA rencontre le même problème silencieux : les agents se multiplient plus vite qu'on ne peut les nommer. Une équipe relie un modèle à un outil pour gagner un après-midi. Un script obtient une clé de service pour lire un CRM. Six semaines plus tard, du logiciel lit des dossiers clients, appelle des API internes et dépense de l'argent — et personne ne peut dire qui en est propriétaire, ce qu'il a le droit de toucher, ni si une seule de ses actions a jamais été enregistrée.

Nous appelons cela des agents fantômes. Ils ne sont pas malveillants. Ils sont le résultat naturel d'une capacité puissante rencontrant une organisation qui n'a aucun runtime pour la gouverner. Et comme tout système non surveillé qui touche à de vraies données et pose de vrais actes, ils constituent une bombe à retardement — la défaillance n'est visible qu'une fois qu'elle coûte cher.

Ce qui rend un agent fantôme dangereux

Un agent n'est pas un chatbot. Il lit des données, choisit des outils et agit en votre nom — il déplace de l'argent, modifie des enregistrements, envoie des messages à des clients. Le danger s'accumule sur trois axes que la sécurité applicative traditionnelle ne surveille jamais :

• Aucune identité. L'agent s'exécute sous une clé empruntée ou un compte de service au périmètre large : aucun propriétaire, aucune finalité métier, aucune expiration, aucun niveau de risque ne lui sont attachés.
• Aucun contrôle des dépenses. Rien ne plafonne le nombre d'appels de modèles ou d'invocations d'outils qu'il peut accumuler avant que quelqu'un ne remarque la facture — ou l'incident de rate-limit.
• Aucun enregistrement. Quand il agit, l'action ne laisse aucune trace à altération détectable. Si un régulateur, un auditeur ou un intervenant en cas d'incident demande ce qu'il a fait et pourquoi, la réponse honnête est : nous ne savons pas.

Un agent fantôme est le seul collaborateur capable de déplacer de l'argent, de lire chaque dossier client et d'agir mille fois par heure — sans badge, sans responsable et sans aucune trace de ce qu'il a fait.

La gouvernance est une propriété du runtime, pas un document de politique

Le réflexe est d'écrire une politique : « tous les agents doivent être enregistrés ». Mais un PDF n'empêche pas un agent non enregistré d'émettre un jeton à 2 heures du matin. La gouvernance ne fonctionne que lorsqu'elle est appliquée sur le chemin d'exécution lui-même — lorsque c'est le runtime, et non un comité, qui décide si une action s'exécute.

C'est le principe de conception qui sous-tend Cortex. Chaque action d'agent traverse huit verrous fail-closed avant de pouvoir atteindre un modèle ou un outil. Le refus est le comportement par défaut. Un agent sans identité gouvernée n'obtient jamais de credential ; une identité expirée est arrêtée avant l'exécution avec un vrai code, pas avec un avertissement qui défile dans un log :

POST /v1/agent-identities/<id>/tokens
  -> 403 IDENTITY_EXPIRED

# pas d'identité gouvernée, pas de jeton.
# pas de jeton, pas d'exécution. le refus est le défaut.

De la prolifération à l'inventaire

La première chose qu'apporte un runtime gouverné est précisément ce qu'un parc fantôme ne peut pas offrir : un inventaire. Dans Cortex, chaque agent est une identité d'entreprise à part entière, avec un propriétaire, un département, une finalité métier, un niveau de risque, une date d'expiration et un ensemble explicite de modèles, d'outils et d'environnements autorisés. Les identités sont recertifiées selon un cycle ; la Control Tower indique combien il en existe, combien sont en retard de revue et combien ont déjà expiré.

Cet inventaire n'est pas de la paperasse — il est appliqué. Une identité dont la liste de modèles autorisés exclut un modèle se voit refuser l'appel à l'exécution avec 403 MODEL_NOT_ALLOWED. Une identité suspendue ne peut pas s'exécuter. La liste des agents que vous voyez est, par construction, la liste des agents qui peuvent s'exécuter.

Désamorcez-la avant qu'elle n'explose

Le cadrage honnête est le suivant : les agents fantômes ne sont pas un risque futur, ils sont un risque présent, et le coût de l'inaction augmente chaque semaine à mesure qu'ils se multiplient. On ne peut pas gouverner ce que l'on ne voit pas, et on ne peut pas prouver ce que l'on n'a jamais enregistré. Un runtime gouverné corrige les deux au même endroit — l'instant de l'exécution — en donnant à chaque agent une identité, un budget, un jeu de garde-fous et un enregistrement à altération détectable de tout ce qu'il a fait. C'est la différence entre un parc que l'on administre et une bombe sur laquelle on est assis.