Votre entreprise a probablement déployé des agents IA cette année. Robots de support client, agents de codage, ouvriers de pipelines de données, assistants d'achat. Chacun s'est connecté à des systèmes, a appelé des API, lu des bases de données et pris des actions en votre nom. Maintenant, répondez à une question : qui sont-ils, et que sont-ils exactement autorisés à faire ?
Pour la plupart des organisations, la réponse honnête est nous ne savons pas. Et cet écart est devenu discrètement l'une des plus grandes expositions de sécurité de 2026.
Le problème du 82 contre 1
Une étude de Rubrik Zero Labs a révélé que les agents IA et autres identités non humaines (NHI) dépassent désormais les utilisateurs humains de 82 contre 1 dans l'entreprise moyenne. Chaque employé humain doté d'un identifiant est doublé par des dizaines d'identités machine : comptes de service, clés API, identifiants de charge de travail, et maintenant des agents autonomes capables de raisonner, planifier et agir.
Le problème, c'est que ces identités n'ont jamais été conçues pour être gouvernées comme des personnes. Les chiffres donnent à réfléchir :
- 97% des identités non humaines possèdent des privilèges excessifs, et environ 90% des agents déployés ont plus d'autorisations que nécessaire.
- 44% des organisations authentifient encore les agents avec des clés API statiques, et 43% s'appuient sur de simples combinaisons identifiant/mot de passe.
- Seules 21% maintiennent un registre en temps réel de leurs agents, ce qui signifie que quatre entreprises sur cinq ne peuvent même pas produire une liste à jour de ce qui tourne.
- 78% n'ont aucune politique documentée pour créer ou supprimer une identité d'agent.
Lorsqu'une enquête de la Cloud Security Alliance et d'Oasis Security de janvier 2026 a demandé aux responsables de la sécurité leur niveau de confiance dans la gestion des identités d'agents, seuls 18% ont déclaré une grande confiance, et 84% doutaient de pouvoir réussir un audit de conformité sur le comportement des agents et les contrôles d'accès. Dans le même temps, 88% avaient déjà subi un incident de sécurité confirmé ou suspecté lié à un agent IA.
Voilà la crise de l'identité à l'ère des agents : une adoption explosive superposée à un modèle d'identité conçu pour les humains et les comptes de service rudimentaires.
Pourquoi la logique du « compte de service » échoue avec les agents
Pendant deux décennies, l'identité machine signifiait un compte de service : un identifiant statique, des permissions larges et un mot de passe que personne ne renouvelait. Ce modèle a survécu parce que les comptes de service étaient prévisibles. Ils exécutaient une tâche, selon un calendrier, contre un système.
Les agents IA brisent chacune de ces hypothèses :
- Ils sont dynamiques. Un agent décide au moment de l'exécution quels outils appeler et quels systèmes toucher. Son schéma d'accès n'est pas un script figé.
- Ils délèguent. Une seule requête utilisateur peut engendrer des sous-agents, chacun héritant de la portée d'accès aux données de l'agent parent. Un seul agent racine sur-privilégié contamine tout l'arbre.
- Ils sont conversationnels. Les agents acceptent des instructions en langage naturel, ce qui signifie qu'une injection de prompt peut transformer une identité de confiance en mandataire d'un attaquant.
- Ils prolifèrent sans coordination. Des équipes isolées lancent des agents à travers les clouds, le SaaS et l'on-premise sans approbation centrale : la définition même du shadow IT, désormais doté d'autonomie.
Les traiter comme des comptes de service revient à confier à un initié privilégié un badge permanent en espérant qu'il se comporte bien. Seules 34% des organisations appliquent aux agents IA les mêmes contrôles de sécurité qu'aux employés humains. Les deux tiers restants avancent à l'aveugle.
Ce que « identité d'agent » signifie réellement en 2026
Le consensus émergent est simple à énoncer et difficile à mettre en œuvre : chaque agent IA devrait être une identité de premier ordre, avec son propre cycle de vie, ses propres identifiants et ses propres permissions étroitement délimitées, distinct à la fois de l'humain qui l'a déclenché et des comptes de service du passé.
Une véritable identité d'agent possède des attributs qu'une clé API statique n'a jamais eus :
- Une identité unique et vérifiable (cryptographique, pas un secret partagé)
- Une équipe propriétaire et un parrain humain responsables
- Une portée déclarée : quels systèmes, quelles actions, quelles données
- Une chaîne de délégation prouvant au nom de qui il agit
- Une expiration et un déclencheur de déprovisionnement automatique
C'est là que l'industrie a avancé vite en 2026, les normes convergeant au lieu de se fragmenter :
- Le brouillon IETF AIMS (Agent Identity Management System), publié le 2 mars 2026, compose trois normes existantes — WIMSE pour l'identité des charges de travail, SPIFFE/SPIRE pour l'identité cryptographique et OAuth 2.0 pour la délégation — en un cadre unifié.
- L'initiative NIST NCCoE « Accelerating Adoption of Software and AI Agent Identity » (5 février 2026) nomme les briques candidates : Model Context Protocol, OAuth 2.0/2.1, OIDC, SPIFFE/SPIRE et SCIM.
- La proposition OIDC-A 1.0 de l'OpenID Foundation étend OpenID Connect avec des revendications propres aux agents pour la vérification de la chaîne de délégation et l'autorisation fine.
Les analystes s'attendent à une stabilisation dans les 12 à 18 mois. L'enseignement pratique pour toute équipe qui construit aujourd'hui : concevez pour l'interopérabilité avec ces normes, pas pour un verrouillage propriétaire.
Un guide pratique à démarrer ce trimestre
Pas besoin d'attendre la finalisation des normes. Les étapes suivantes correspondent directement aux endroits où le risque se concentre.
1. Découvrir avant de gouverner
On ne peut pas sécuriser ce qu'on ne voit pas. Commencez par un inventaire complet de chaque agent, à travers chaque mode de déploiement : cloud, SaaS et on-premise. Sans énumération, tout contrôle en aval reste incomplet. Construisez un registre qui consigne, pour chaque agent : l'équipe propriétaire, le parrain humain, les systèmes accédés, la portée des privilèges et la date d'expiration.
2. Éliminer les identifiants statiques
Remplacez les clés API à longue durée de vie par des identifiants éphémères et individuellement délimités. Les deux outils clés :
- Pour les agents délégués par l'utilisateur, utilisez les flux OAuth 2.0 On-Behalf-Of afin que l'agent agisse avec la permission limitée de l'utilisateur, et non avec une clé toute-puissante.
- Pour les agents machine autonomes, émettez des SVID SPIFFE/SPIRE : des identités cryptographiques qui se renouvellent automatiquement et ne peuvent être copiées depuis un fichier de configuration.
3. Adopter le privilège permanent nul (Zero Standing Privilege)
Le changement architectural le plus important : les agents n'obtiennent aucun accès permanent aux ressources sensibles. Les permissions sont accordées juste-à-temps pour une tâche précise, puis automatiquement révoquées. Un agent compromis au repos n'a accès à rien. Ce seul modèle neutralise la sur-attribution de privilèges qui affecte 90% des déploiements.
4. Placer des humains aux points de contrôle à fortes conséquences
L'autonomie totale n'est pas l'objectif partout. Insérez une vérification humaine avant qu'un agent n'exécute une transaction financière, ne modifie une configuration de production, n'accède à des données réglementées ou n'envoie une communication externe. Autonomie pour le routinier, point de contrôle pour l'irréversible.
5. Construire le coupe-circuit avant d'en avoir besoin
Rédigez le plan de réponse aux incidents dès maintenant : comment identifier l'activité d'un agent en plein incident, comment révoquer ses identifiants sans faire tomber les services qui en dépendent, comment reconstituer ce qu'il a fait de manière forensique. Un coupe-circuit instantané et chirurgical fait la différence entre un événement maîtrisé et une violation.
Ce que cela signifie pour les entreprises de la région MENA
Pour les organisations de Tunisie, d'Arabie saoudite et de la région MENA au sens large, l'identité des agents n'est pas un problème d'entreprise lointain : c'est le ticket d'entrée pour déployer l'IA en toute sécurité sous des régimes de protection des données de plus en plus stricts. La PDPL saoudienne et des cadres similaires traitent l'accès non autorisé aux données comme un manquement à la conformité, qu'un humain ou un agent en soit la cause. Un agent sur-privilégié qui lit des dossiers clients dont il n'avait pas besoin constitue un incident à déclarer.
La bonne nouvelle : les organisations qui adoptent l'IA maintenant peuvent intégrer la gouvernance de l'identité dès le premier jour, plutôt que de la rajouter sur une nuée d'agents fantômes. Traitez chaque agent comme une identité de premier ordre, éphémère et étroitement délimitée dès le premier déploiement, et vous éviterez la crise de nettoyage que vivent aujourd'hui les adoptants plus grands et plus précoces.
En résumé
Les agents IA sont des initiés privilégiés que vous provisionnez en quelques secondes et oubliez en quelques minutes. Le ratio de 82 contre 1 ne fera que croître, et le modèle de sécurité doit croître avec lui. Les organisations qui gagnent en 2026 ne sont pas celles qui déploient le plus d'agents, mais celles capables de répondre, à tout moment : qui sont leurs agents, à quoi ils peuvent toucher, et comment les arrêter.
Commencez par la découverte, supprimez les clés statiques, n'accordez le privilège que lorsqu'il est nécessaire, et gardez un humain aux décisions irréversibles. Voilà à quoi ressemble l'identité d'agent quand elle est bien faite.
Vous intégrez des agents IA à votre activité et voulez les gouverner dès le premier jour ? Noqta aide les organisations de la région MENA à concevoir des systèmes d'agents sécurisés et conscients de l'identité. Contactez-nous.