Audit des délégations

Chaque délégation à un agent IA laisse une trace attribuable : qui a délégué, à quel agent, avec quels scopes et quelle audience, consultable par les admins et visible par les utilisateurs eux-mêmes.

Quand un agent obtient un jeton qui agit au nom d'un utilisateur via le Token Exchange, la question qui compte ensuite est : qui a agi au nom de qui, sur quoi, et quand. Obexal y répond à trois niveaux : un journal forensic bâti sur le journal d'audit immuable, l'attribution dans le jeton lui-même, et une visibilité en libre-service pour chaque utilisateur.

Ce qui est consigné

Chaque délégation réussie écrit un événement oauth.token.exchange au journal d'audit :

l'acteur est l'utilisateur délégant (l'humain dont le jeton a été échangé) ;
la cible est l'agent, sous la forme agent:<clientId> ;
les métadonnées portent agent (client id), agentName, scope (les scopes réellement accordés après downscoping), audience (le resource server cible), et chained: true quand le subject token était lui-même déjà délégué (délégation imbriquée).

La vue des délégations est reconstruite depuis ces événements d'audit : il n'existe pas de table mutable séparée qui pourrait diverger du journal.

Le jeton lui-même porte aussi l'attribution : sub est l'utilisateur, et le claim act identifie l'agent, avec un chaînage act.act pour la délégation imbriquée. Les resource servers le voient dans le JWT et dans la réponse d'introspection.

Consulter le journal des délégations

GET /v1/admin/agents/delegations (permission apps:manage) liste les délégations, les plus récentes d'abord, filtrables par ?agent= (client id) et ?user= (id utilisateur), avec ?limit= jusqu'à 500 (200 par défaut). La console affiche la même vue dans la section Agents IA. Si votre organisation utilise un domaine personnalisé, il remplace accounts.obexal.com.

curl -sS "https://accounts.obexal.com/v1/admin/agents/delegations?agent=agent-support-bot&limit=50" \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN"

{
  "delegations": [
    {
      "at": "2026-07-02T09:14:03Z",
      "agentClientId": "agent-support-bot",
      "agentName": "Support bot",
      "userId": "8c1e35a2-90d7-4b2e-b6a1-53d92f7c44e0",
      "userEmail": "alice@example.eu",
      "audience": "https://api.example.eu",
      "scopes": "tickets:read tickets:write",
      "chained": false
    }
  ]
}

Exporter vers votre SIEM

Les délégations sont des événements d'audit ordinaires : elles sortent de la plateforme avec le reste du journal. GET /v1/admin/audit/export produit une pièce jointe CSV ou JSON, plafonnée à 10000 événements. Filtrez sur l'action oauth.token.exchange dans votre SIEM. Voir Journal d'audit pour l'export et le flux temps réel.

Les utilisateurs voient et révoquent leurs agents

La délégation n'est pas une affaire réservée aux admins : chaque utilisateur peut voir et révoquer les agents autorisés à agir en son nom, sans ouvrir de ticket.

Dans l'espace compte du domaine de connexion, la section Agents IA autorisés les liste avec leurs scopes.
Via l'API, avec la session de l'utilisateur : GET /v1/agent-authorizations liste les autorisations, POST /v1/agent-authorizations en accorde une ({"agentClientId": "...", "scopes": [...]}, bornée aux scopes de l'agent), et DELETE /v1/agent-authorizations/{clientId} la révoque (idempotent).

{
  "authorizations": [
    {
      "agentClientId": "agent-support-bot",
      "agentName": "Support bot",
      "scopes": ["tickets:read"],
      "authorizedAt": "2026-06-12T10:02:44Z"
    }
  ]
}

La révocation coupe les délégations futures pour cet utilisateur (l'échange exige l'autorisation et est borné à ses scopes) et révoque aussi les refresh tokens existants du couple utilisateur et agent. Seuls les agents soumis à autorisation utilisateur apparaissent ici : les agents first-party de confiance délèguent sans autorisation individuelle.

La revue d'accès attestée, en complément

Le journal forensic dit ce qui s'est passé ; la revue d'accès atteste qu'un humain a vérifié ce qui devrait être permis. Chaque agent porte un horodatage reviewedAt et un drapeau needsReview (jamais revu, ou revu il y a plus de 90 jours), et un admin atteste la revue depuis l'inventaire. Voir Identité des agents.