Une identité vérifiable et gouvernée pour chaque agent IA.

Vos agents IA accèdent à vos systèmes comme vos collaborateurs. Obexal leur donne une identité de premier rang : un propriétaire humain, une date d'expiration, des permissions plafonnées et une traçabilité complète de chaque action menée en votre nom.

L'essentiel

Identité	Un client OAuth 2.1 confidentiel par agent ; propriétaire humain nommé ; date d'expiration
Statuts	Actif, dormant, expiré, orphelin ; revue d'accès attestée tous les 90 jours
Délégation	Token Exchange (RFC 8693), claim act chaîné ; audience liée (RFC 8707)
Plafonds	Scopes, durée de vie des jetons, allowlist d'audience ; le tout fail-closed
Détection	6 règles déterministes ; auto-confinement en dérive extrême
Kill switch	Immédiat ; les jetons déjà émis deviennent inertes à l'introspection
Journal	Forensic des délégations : qui a agi, quand, pour le compte de qui
Offre	Business

Un agent est une identité

Un agent qui lit votre CRM, ouvre des tickets ou déplace de l'argent est une identité non humaine à portée réelle. Trop souvent, il s'authentifie avec une clé d'API partagée, copiée dans un coffre ou une variable d'environnement. Cette clé n'a pas de propriétaire, pas de date d'expiration et ne laisse aucune trace attribuable de ce que l'agent fait. Quand l'incident arrive, personne ne sait à qui appartient la clé, ni comment la couper sans casser autre chose.

Obexal referme cette faille. Chaque agent devient un client OAuth 2.1 confidentiel à part entière, doté de ses propres identifiants et rattaché à un propriétaire humain nommé et responsable. Il porte une date d'expiration, si bien qu'un agent oublié cesse de fonctionner au lieu de subsister indéfiniment. Son statut est lisible d'un coup d'œil : actif, dormant, expiré ou orphelin (propriétaire parti). Une revue d'accès attestée revient tous les 90 jours : un agent non revu remonte de lui-même pour décision.

Le tout vit dans un registre unifié, aux côtés de vos utilisateurs et de vos services. Les humains, les comptes de service et les agents IA figurent dans un seul inventaire, soumis aux mêmes exigences de propriété, d'expiration et de revue.

Délégation attribuable : agir au nom d'un utilisateur

Un agent agit rarement seul : il agit pour quelqu'un. Quand l'assistant de Sarah interroge le CRM en son nom, le jeton ne doit pas effacer Sarah au profit du robot. Obexal s'appuie sur le Token Exchange (RFC 8693) : l'agent échange le jeton de l'utilisateur contre un jeton délégué où l'utilisateur reste le sujet (sub) et où l'agent est identifié dans le claim act (act.sub). Vous savez donc toujours qui a agi, et pour le compte de qui.

Le claim act se chaîne : lorsqu'un agent délègue à un autre, chaque maillon reste visible dans le jeton. Le périmètre demandé est réduit par intersection (downscoping) : jamais plus que ce que l'utilisateur détient, jamais plus que ce que l'agent peut porter, jamais plus que le plafond autorisé. Chaque jeton est en outre lié à son destinataire par une audience (RFC 8707), de sorte qu'un jeton délégué pour le CRM ne vaut rien ailleurs. Et l'utilisateur qui délègue donne un consentement explicite, borné à des scopes précis et révocable à tout moment. Chacun retrouve dans son portail la liste des agents qui agissent en son nom, avec un bouton pour couper.

Une gouvernance appliquée par agent

La gouvernance ne vit pas dans une page de wiki : elle s'applique à l'émission même des jetons. Chaque agent porte une politique qui définit ce qu'il peut obtenir, et cette politique est fail-closed. Si elle ne peut pas répondre, l'émission est refusée plutôt qu'accordée par défaut.

• Plafond de scopes : l'agent peut réduire son périmètre, jamais dépasser le plafond fixé pour lui.
• Plafond de durée de vie des jetons (TTL) : chaque jeton reçoit une durée maximale, courte par défaut, pour qu'un jeton fuité ne reste pas exploitable des heures.
• Allowlist d'audience : l'agent n'obtient de jetons que pour les resource servers explicitement autorisés, ce qui cantonne toute compromission aux applications prévues.

Le secret de l'agent se renouvelle en un appel ou en un clic. Le nouveau secret n'est affiché qu'une seule fois et l'ancien cesse aussitôt d'être accepté. Vous pouvez lui fixer une durée de vie, et s'authentifier avec un secret expiré est refusé et signalé. La rotation et l'expiration des secrets deviennent une routine tracée, pas une opération risquée que personne n'ose lancer.

Détecter les dérives, puis les contenir

Six règles déterministes et explicables surveillent chaque agent, sans modèle statistique opaque :

• Réveil d'agent dormant : un agent resté silencieux se remet soudain à émettre.
• Usage d'un agent expiré : l'agent continue de s'authentifier après sa date d'expiration.
• Usage d'un secret expiré : l'authentification s'appuie sur un secret dont la durée de vie est dépassée.
• Usage malgré un kill switch : des tentatives se poursuivent alors que l'agent est coupé.
• Horaires inhabituels : l'activité sort des plages observées dans l'historique de l'agent.
• Pic de volume : le volume d'émission monte très au-dessus de la moyenne de l'agent.

En dérive extrême, l'agent est confiné automatiquement, sans attendre une intervention humaine. Chaque délégation est par ailleurs consignée dans un journal forensic : qui a agi, quand, pour le compte de qui, exportable pour vos audits.

Quand quelque chose cloche, vous n'avez pas besoin d'une migration : un interrupteur suffit. Le kill switch est immédiat, et c'est une pause, pas une démolition. Il bloque toute nouvelle émission, client_credentials comme Token Exchange, et rend inertes les jetons déjà en circulation : à l'introspection, ils répondent inactifs, si bien que les APIs qui valident par introspection les refusent aussitôt. La politique de l'agent (plafonds, allowlist) est préservée, et vous le réactivez en un clic une fois l'incident clos. Chaque bascule est journalisée.

Bâti sur des standards ouverts

Pas de SDK propriétaire, pas d'enfermement : un agent Obexal est un client OAuth 2.1 standard, que votre stack sait déjà parler. Le grant client_credentials lui donne son identité machine ; les Pushed Authorization Requests (PAR) poussent les paramètres d'autorisation côté serveur avant l'émission ; la preuve de possession DPoP empêche de rejouer un jeton volé depuis une autre machine. Vos APIs vérifient les jetons par introspection (RFC 7662), et la réponse expose le claim act, si bien que votre service voit à la fois le sujet (l'utilisateur) et l'acteur (l'agent), même en délégation chaînée.

L'enregistrement d'un agent et la pose de sa politique passent par l'API d'administration, authentifiée par un jeton scopé de la forme obx_ et décrite par un contrat OpenAPI 3.1 public. Tout framework capable d'un POST vers le point de jeton fonctionne, qu'il s'agisse de LangChain, d'un serveur MCP ou d'un simple script. La documentation détaille chaque appel.

Traçabilité et AI Act

Soyons honnêtes : aucun fournisseur d'identité ne rend un système d'IA conforme à lui seul, et nous ne vous le promettrons pas. Obexal contribue à vos obligations en fournissant les contrôles techniques sur lesquels elles s'appuient : une identité attribuable pour chaque agent avec un responsable humain nommé, un journal des délégations qui retrace qui a agi et pour le compte de qui, une révocation immédiate par le kill switch, et un journal d'audit exportable. La démarche de conformité reste la vôtre ; Obexal vous en fournit les preuves.

Cette gouvernance repose sur une base souveraine. Obexal est hébergé en France, dans un datacenter en région parisienne, avec une résidence des données dans l'Union européenne et aucune dépendance hors UE dans le chemin des requêtes. Les agents s'inscrivent dans le même socle d'identité que le reste de votre organisation : voir la gestion des identités et des accès pour vos collaborateurs, le CIAM pour vos clients, et la gouvernance des agents IA pour la lecture sécurité et conformité. L'identité et la gouvernance des agents font partie de l'offre Business : voir la page tarifs.

Questions fréquentes

---

Continuer : IAM, l'identité de vos collaborateurs · CIAM, l'identité de vos clients · La gouvernance des agents pour votre SOC