Identité des agents IA : Okta pose 3 questions le 2 septembre 2026 — le produit d'AppH y répond déjà, sans plateforme dédiée
Le 2 septembre 2026, Security Boulevard a publié une tribune d'Okta/GuidePoint Security : les agents IA sont une nouvelle classe d'identité qui traverse l'entreprise sans les contrôles déjà en place pour les humains — d'où trois questions que peu d'organisations savent répondre : où sont mes agents, à quoi peuvent-ils se connecter, que peuvent-ils faire. Chez les grandes entreprises, la réponse passe par une plateforme d'identité dédiée (Okta, dans ce cas). Chez AppH, les mêmes trois réponses existent déjà — pas en option payante, dans le produit lui-même.
Selon Ariel Zommer (Okta, Security Boulevard, 2 septembre 2026), les agents IA se répandent dans l'entreprise plus vite que n'importe quelle vague technologique précédente, souvent sans la responsabilité qu'on exige déjà des humains et des applications. La tribune cite un incident réel : une connexion OAuth compromise entre un compte d'entreprise et un outil IA tiers a ouvert un chemin vers des systèmes internes (clés API, jetons, variables d'environnement) — pas une faille logicielle, un problème d'identité. Elle cite aussi une statistique dure (Stanford SACR, mars 2026) : 53 % des serveurs MCP publics utilisent des secrets statiques, et seulement 8,5 % implémentent OAuth. La tribune propose trois questions comme fondation : où sont mes agents ? à quoi peuvent-ils se connecter ? que peuvent-ils faire ? — avec, pour la troisième, une recommandation explicite de contrôles humain-dans-la-boucle pour les actions à enjeu élevé (changer un environnement de production, accéder à des données réglementées, initier une action financière).
La solution que propose la tribune — une plateforme d'identité dédiée aux agents, avec inventaire, permissions courtes et révocables, workflows d'approbation, journaux centralisés — est la bonne réponse pour une grande entreprise qui fait tourner des dizaines d'agents de fournisseurs différents. Mais construire ou acheter cette plateforme est hors de portée pour une PME, qui n'a ni l'équipe sécurité ni le budget pour un projet Okta dédié. AppH répond aux trois mêmes questions autrement : pas par une couche d'identité séparée à administrer, mais parce que le produit est construit avec les réponses déjà dedans. Où sont mes agents ? — chaque action automatisée d'AppH (email trié, brouillon de relance, mise à jour de statut) laisse une trace dans le même journal d'audit que les actions humaines, avec un acteur identifié, consultable module par module (panneau d'historique déjà en place sur plus de dix verticaux). À quoi peuvent-ils se connecter ? — chaque module a un périmètre de données borné à son propre domaine (un agent qui gère la facturation ne touche pas les dossiers cliniques), et les connexions externes (webhooks, clés API) ont leurs propres secrets rotables et une alerte automatique si une clé reste active sans usage. Que peuvent-ils faire ? — c'est le clic d'approbation humaine sur toute action à conséquence réelle, déjà couvert dans notre pièce du jour sur la tribune Forbes : l'argent qui bouge, une réservation annulée, une communication qui part vers un client, une donnée sensible qui change de main.
Pour AppH
- Les trois questions que la tribune pose comme fondation d'une stratégie d'identité agentique — où, à quoi, quoi faire — trouvent une réponse déjà construite chez AppH, sans qu'un client PME ait à évaluer ou acheter une plateforme d'identité séparée.
- L'attribution par acteur dans le journal d'audit (déjà en production sur plus de dix modules) correspond exactement à ce que la tribune décrit comme le standard à atteindre : des journaux « attribuables, auditables et actionnables ».
Contre / la limite honnête
- AppH n'a pas de répertoire formel d'identités d'agents avec propriétaire et cycle de vie déclarés par agent — parce que tous les agents d'AppH appartiennent au même produit, un cas plus simple que la prolifération multi-fournisseurs que vise la tribune ; le jour où AppH laisserait des agents tiers se connecter via API, cette lacune deviendrait réelle.
- Pas de « kill switch » pour couper d'un coup l'accès d'un agent précis à travers tous les systèmes connectés — la brique la plus proche qu'AppH a aujourd'hui est l'alerte sur une clé API dormante, pas une révocation immédiate et centralisée.
Ce qui frappe dans cette tribune, ce n'est pas la nouveauté du risque — l'identité mal gérée est un vieux problème de sécurité — c'est la vitesse à laquelle les agents IA le font réapparaître à une échelle que peu d'équipes sécurité ont anticipée. Pour une grande entreprise, la réponse est un projet : évaluer, déployer, administrer une plateforme d'identité dédiée. AppH part d'un principe différent, plus modeste mais tout aussi défendable : une PME n'a ni le temps ni le budget pour ce projet, donc les réponses doivent être dans le produit dès le premier jour, pas dans une case à cocher plus tard. On ne prétend pas couvrir tous les cas que couvre une plateforme comme celle que décrit la tribune — le répertoire d'agents manquant et le kill switch en sont la preuve honnête. Mais sur les trois questions posées, aucune n'attend une réponse chez AppH : elle existe déjà, et un humain reste la dernière étape avant que quoi que ce soit de coûteux à défaire ne se produise.
Vérifié par un humain d'AppH