Hermes en entreprise : l'agent IA doit d'abord devenir une identité maîtrisée
Un agent capable d'enchaîner des actions sur le SI ne pose pas d'abord une question de modèle, mais une question d'identité, de mandat et d'autorisation.
Nous abordons Hermes par l'IAM
Hermes peut disposer d'une mémoire, de skills, de profils indépendants, de tâches planifiées, de connexions MCP et d'un accès à des outils ou à des API. Dès qu'il entre dans un SI d'entreprise, la question n'est donc plus longtemps « que sait répondre l'IA ? ».
Elle devient : quelle est son identité ? Qui l'autorise à agir ? Au nom de qui ? Sur quelles ressources ? Pour quelle action ? Et dans quelles conditions ?
Un agent doit être considéré simultanément comme une identité non humaine, un client API, éventuellement le mandataire d'un utilisateur humain, et un processus autonome capable d'enchaîner plusieurs actions sans reprendre son souffle. Ces quatre lectures n'appellent pas les mêmes contrôles, et c'est précisément ce qui rend le sujet intéressant.
Un agent Hermes doit avoir une identité
Un profile Hermes possède sa propre configuration, ses credentials, sa mémoire, ses sessions, ses skills et ses tâches planifiées. C'est déjà une base de séparation très utile.
Une nuance s'impose toutefois : un profile est une séparation logique de l'état Hermes, pas nécessairement une frontière de sécurité du système d'exploitation. Si l'agent utilise un backend terminal local, le profile n'empêche pas à lui seul l'accès au reste du filesystem. Les environnements sensibles doivent donc s'appuyer aussi sur une isolation adaptée : conteneur Docker, machine virtuelle, backend SSH dédié, permissions système.
Dans une architecture d'entreprise, chaque agent important devrait avoir un identifiant propre, un propriétaire humain ou métier, une finalité, un environnement, des credentials distincts, des droits documentés, une durée de vie et une politique de revue et de révocation.
Le modèle à éviter tient en une phrase entendue régulièrement : « voilà mon token personnel, fais tout ce que je peux faire ». Un agent Finance, un agent SEO et un agent Delivery n'ont aucune raison de partager le même compte technique parce qu'ils tournent sur le même VPS.
C'est exactement le raisonnement de l'IAG appliqué aux identités non humaines : elles ont elles aussi un cycle de vie, des habilitations, des propriétaires et des revues d'accès.
« Agir en mon nom » n'oblige pas à lui donner tous mes droits
Hermes peut utiliser des connecteurs et parfois agir avec une identité déléguée : lire du courrier, consulter des documents, créer un événement. Sur beaucoup d'usages, c'est parfaitement acceptable et cela fait gagner un temps réel.
Sur les ressources importantes, nous préférons souvent un autre modèle : faire passer l'agent par une API explicitement conçue pour les opérations qu'il est autorisé à réaliser.
Plutôt que de donner un accès générique à SharePoint et de compter sur le prompt pour que l'agent reste raisonnable, on expose searchDocuments, readDocument et readMetadata — et on n'expose simplement pas deleteDocument, changePermissions ou shareExternally.
On renonce éventuellement à un peu du confort offert par certains connecteurs natifs. Mais une fois cette API construite, l'entreprise maîtrise réellement ce que l'agent peut faire, indépendamment de la formulation de ses instructions.
Le moindre privilège ne suffit plus : viser la moindre capacité d'action
Un agent est rapide et autonome. Il faut donc contrôler ce à quoi il accède, mais aussi ce qu'il peut faire et à quelle échelle.
- 01
Agent documentaire
Autorisé à lire les documents de trois espaces précis. Pas de suppression, pas de changement de permissions, pas de partage externe, une limitation de volumétrie, et une anomalie levée si plusieurs milliers de documents sont consultés soudainement.
- 02
Agent mail
Il peut lire certaines boîtes, rechercher et préparer un brouillon. L'envoi peut être autorisé automatiquement en interne, mais demander une validation pour un destinataire externe ou une opération sensible.
- 03
Agent Finance
Le fait qu'un utilisateur humain puisse modifier une donnée financière ne signifie pas que son agent doive pouvoir la modifier sans validation. Le droit de l'utilisateur reste nécessaire ; il ne doit pas toujours être suffisant.
L'identité humaine et l'identité de l'agent doivent pouvoir participer ensemble à la décision.
Mettre un PEP entre l'agent et le SI
L'API Gateway est un excellent endroit pour devenir Policy Enforcement Point. Elle se trouve sur le chemin réel de l'appel et intercepte la demande avant qu'elle n'atteigne la ressource. Elle peut vérifier l'identité de l'agent, éventuellement l'identité humaine au nom de laquelle il agit, l'API appelée, la méthode, les paramètres et la volumétrie, puis demander une décision au PDP.
Le Policy Decision Point décide. Axiomatics est un exemple naturel dans notre écosystème. La question posée n'est plus « cet agent possède-t-il le rôle SharePointReader ? », mais « l'agent hermes-research peut-il lire ce document classé Interne, dans ce site précis, pour cet utilisateur précis, dans le cadre de cette tâche, avec ce niveau de risque et cette volumétrie ? ».
Le PDP renvoie une décision, le PEP l'applique : permit, deny, et selon l'architecture limitation, masquage ou obligation de validation. On est bien dans une logique ABAC / PBAC. Le couple PDP/PEP est l'architecture de référence issue de XACML, ce qui ne signifie pas que toutes les intégrations modernes échangent du XACML brut : les interfaces REST/JSON conviennent parfaitement aux architectures API actuelles.
Le prompt décrit ce que l'agent devrait faire. L'autorisation détermine ce qu'il peut réellement faire.
Demande initiale, tâche planifiée
Agent + identité technique propre
Appel outillé vers le SI
Point d'application : intercepte, contextualise, applique
Décision ABAC / PBAC : permit, deny, obligation
La ressource n'est atteinte qu'après décision
Le contrôle intervient avant que la donnée n'entre dans le contexte du modèle, pas après coup sur sa réponse.
Exemple concret : Hermes doit lire SharePoint
Le mauvais raccourci consiste à donner à l'agent un accès très large à SharePoint parce que « de toute façon l'utilisateur y a accès ». Le blast radius change pourtant d'échelle : un humain ouvre quelques documents, un agent peut en parcourir plusieurs centaines en quelques minutes.
L'architecture que nous préférons enchaîne Hermes Research, une Enterprise Documents API, l'API Gateway qui joue le PEP, le PDP Axiomatics, puis Microsoft Graph et SharePoint.
Pour SharePoint Online, Microsoft Graph permet notamment des permissions Selected, qui limitent une application à certaines ressources plutôt que de lui donner un accès global. Les contrôles existent aux niveaux site, liste, élément, dossier ou fichier selon le scope employé. L'identité applicative utilisée derrière l'API ne dispose alors que d'un droit de consultation sur quelques sites autorisés.
Hermes demande « lire document-123 ». Le PEP transmet au PDP les attributs de la demande.
Axiomatics évalue la politique. Si la réponse est Permit, l'API appelle Microsoft Graph. Sinon, le document n'atteint jamais le contexte de l'agent — et c'est le point essentiel : le contrôle doit intervenir avant que la donnée sensible soit transmise au modèle, pas seulement en tentant de filtrer sa réponse après coup.
human = utilisateur demandeur
agent = hermes-research
action = read
resource = document-123
classification = internal
site = sales
purpose = customer-research
risk = low
volume_last_15_minutes = 12Autorisation fine et dynamiquePartenariat AxiomaticsAccess management et CIAMBlast radius — définition au glossaire
Utiliser aussi les protections natives de Hermes
Hermes n'est pas intrinsèquement dangereux. Il embarque déjà plusieurs contrôles utiles : autorisation des utilisateurs pouvant parler à l'agent, validation des commandes dangereuses, restrictions d'écriture, isolation par conteneur ou backend distant, séparation des credentials MCP. Ils doivent être utilisés.
Mais ils répondent surtout à la sécurité du runtime. L'architecture IAM décrite ici répond à une autre question : même si Hermes fonctionne exactement comme prévu, quelles actions l'entreprise accepte-t-elle de lui laisser exécuter ? Les deux couches sont complémentaires, et aucune ne remplace l'autre.
Cette architecture vaut aussi pour Emergent Wingman
Wingman propose des connecteurs vers de nombreux SaaS et possède ses propres contrôles : permissions de connecteurs, politiques d'actions, confirmations, sandboxing, protection des tâches planifiées et journaux d'audit.
La différence tient à la frontière de confiance : l'agent est opéré hors du SI. Pour des opérations à faible risque, un connecteur natif est souvent suffisant. Pour une opération sensible, le même pattern — Wingman, puis API d'entreprise, puis API Gateway / PEP, puis PDP, puis ressource — permet de garder la décision d'autorisation sous le contrôle de l'entreprise.
Il n'y a donc pas à opposer Hermes et Wingman : l'architecture est réutilisable pour les deux, avec une porte d'entrée encore plus structurante pour un agent extérieur au SI.
Architecture minimale recommandée avant la production
- Une identité distincte par agent ou domaine de responsabilité.
- Un propriétaire et un cycle de vie gouvernés.
- Des credentials courts et les moins privilégiés possible.
- Des API explicites pour les actions sensibles.
- Un PEP capable d'interroger un PDP d'autorisation fine.
- De la journalisation permettant de relier humain → agent → décision → API → ressource.
Un agent autonome n'a pas besoin d'être administrateur du SI pour être utile. Une bonne architecture consiste justement à lui donner beaucoup d'autonomie dans un périmètre d'autorisation très maîtrisé.
Ce qu'il faut retenir
L'IAG gouverne les identités et les habilitations dans la durée. L'Access Management gère l'authentification et l'accès. L'autorisation fine prend la décision contextuelle au runtime. Un agent IA a besoin des trois, et pas seulement d'un bon prompt système.
La valeur d'un agent vient de son autonomie. Le rôle de l'IAM n'est pas de la réduire, mais de la rendre enforceable : un périmètre clair, décidé ailleurs que dans les instructions de l'agent.
Cadrer vos agents avant de les mettre en production
Nous aidons les équipes à définir les identités de leurs agents, les API qu'elles souhaitent réellement exposer, les points d'application et les politiques d'autorisation associées — en partant des usages métier, pas d'un catalogue d'outils.