Le modèle d'identité d'agent

Chaque agent IA est une identité de premier rang : un client OAuth 2.1 avec un propriétaire humain, une date d'expiration, un statut de cycle de vie calculé et une revue d'accès attestée.

Obexal donne à chaque agent IA une identité propre, gouvernée avec la même rigueur qu'un compte humain : un responsable nommé, une durée de vie, une trace d'activité et une revue périodique. Cette page décrit le modèle ; les pages suivantes montrent comment enregistrer un agent, déléguer au nom d'un utilisateur et le contraindre par une politique.

Pourquoi pas une clé d'API partagée

La clé d'API partagée est l'anti-modèle de la gouvernance d'agents : elle n'a pas de propriétaire (personne n'est responsable quand elle dérape), pas d'expiration (elle survit au projet pour lequel elle a été créée), pas de scopes (elle peut tout ce que son émetteur pouvait), pas d'attribution (les journaux aval montrent la clé, jamais la personne pour qui l'agent agissait), et sa révocation casse tous les consommateurs d'un coup. Un agent Obexal est l'inverse point par point : identifié individuellement, possédé, expirable, borné, attribuable et révocable seul, sans dommage collatéral.

Un agent, un client OAuth

Un agent est un client OAuth 2.1 confidentiel qui porte au moins un grant machine : client_credentials (l'agent agit en son nom propre) ou urn:ietf:params:oauth:grant-type:token-exchange (l'agent agit au nom d'un utilisateur). Tout ce qui vaut pour les clients vaut pour les agents : un client_id, un client_secret (seul son SHA-256 est stocké, la valeur en clair n'est montrée qu'une fois à la création), un périmètre de scopes, et l'isolation stricte par tenant.

L'inventaire d'administration, GET /v1/admin/agents (permission apps:manage), liste tous les clients de votre organisation portant au moins un de ces grants, avec leur identité, leur politique de gouvernance effective et leur statut calculé.

Un propriétaire humain et une date d'expiration

PUT /v1/admin/agents/{clientId}/identity pose les deux attributs d'identité (permission apps:manage, et un step-up MFA récent depuis la console) :

• owner : l'e-mail d'un utilisateur de votre organisation. Il est résolu dans l'annuaire et stocké comme une référence en base vers cet utilisateur, pas comme du texte libre. Si le propriétaire est ensuite retiré de l'annuaire, la référence est effacée et l'agent devient orphelin.
• expiresAt : une date RFC 3339. L'expiration est appliquée fail-closed à l'émission des jetons : une fois la date dépassée, toute demande de jeton par l'agent est refusée avec invalid_grant, quel que soit le grant, et chaque tentative est enregistrée comme une anomalie expired_agent. Une valeur vide signifie sans expiration.

Des statuts de cycle de vie calculés

Chaque émission de jeton touche l'horodatage lastUsedAt de l'agent. L'inventaire en dérive un statut, dans cet ordre de priorité :

Les agents dormants et orphelins sont exactement ceux que les revues d'accès existent pour attraper : toujours capables de s'authentifier, sans personne pour les surveiller.

Des revues d'accès attestées

POST /v1/admin/agents/{clientId}/review horodate une attestation humaine : un administrateur confirme avoir revu ce qu'est l'agent, qui le possède et ce qu'il peut faire. L'inventaire expose reviewedAt et un indicateur needsReview, vrai quand l'agent n'a jamais été attesté ou quand la dernière attestation date de plus de 90 jours. Chaque attestation est écrite dans le journal d'audit, ce qui vous donne la piste de preuve attendue par les programmes de revue périodique.

Un registre pour toutes les identités

GET /v1/admin/identities (permission users:view) renvoie le registre unifié de l'organisation : toutes les identités, quelle que soit leur nature, dans une seule liste. Chaque entrée porte un kind (human, service pour les clients machine sans grant d'agent, ou agent), un libellé, son responsable, son statut, sa dernière activité et son nombre d'anomalies ouvertes. Humains, services et agents IA se revoient à travers la même vitre.

Étapes suivantes

1. Enregistrer un agent : créer le client, poser l'identité, émettre un premier jeton.
2. La délégation par Token Exchange : laisser l'agent agir au nom d'un utilisateur, de façon attribuable.
3. La politique de gouvernance par agent : kill switch, plafond de TTL, plafond de scopes, allowlist d'audiences.