Obexal Docs

Docs/AI agents/Delegation audit trail

Delegation audit

Every delegation to an AI agent leaves an attributable trace: who delegated, to which agent, with which scopes and audience, queryable by admins and visible to the users themselves.

When an agent obtains a token that acts on behalf of a user through Token Exchange, the question that matters later is: who acted on behalf of whom, on what, and when. Obexal answers it at three levels: a forensic log built on the immutable audit trail, attribution inside the token itself, and self-service visibility for every user.

What gets recorded

Every successful delegation writes an oauth.token.exchange event to the audit log:

  • the actor is the delegating user (the human whose token was exchanged);
  • the target is the agent, as agent:<clientId>;
  • the metadata carries agent (client id), agentName, scope (the scopes actually granted after downscoping), audience (the target resource server), and chained: true when the subject token was itself already delegated (nested delegation).

The delegation view is reconstructed from these audit events: there is no separate mutable table that could drift from the log.

The token itself carries the attribution too: sub is the user, and the act claim identifies the agent, with act.act chaining for nested delegation. Resource servers see it in the JWT and in the introspection response.

Query the delegation log

GET /v1/admin/agents/delegations (permission apps:manage) lists delegations, most recent first, filterable by ?agent= (client id) and ?user= (user id), with ?limit= up to 500 (200 by default). The console shows the same view in the AI agents section. If your organization uses a custom domain, it replaces 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
    }
  ]
}

Export to your SIEM

Delegations are ordinary audit events, so they leave the platform with the rest of the log: GET /v1/admin/audit/export produces a CSV or JSON attachment, capped at 10000 events. Filter on the action oauth.token.exchange in your SIEM. See Audit log for the export and the real-time stream.

Users see and revoke their agents

Delegation is not an admin-only affair: every user can see and revoke the agents authorized to act on their behalf, without opening a ticket.

  • In the account area of the sign-in domain, the section Authorized AI agents lists them with their scopes.
  • Over the API, with the user's own session: GET /v1/agent-authorizations lists authorizations, POST /v1/agent-authorizations grants one ({"agentClientId": "...", "scopes": [...]}, bounded by the agent's scopes), and DELETE /v1/agent-authorizations/{clientId} revokes it (idempotent).
{
  "authorizations": [
    {
      "agentClientId": "agent-support-bot",
      "agentName": "Support bot",
      "scopes": ["tickets:read"],
      "authorizedAt": "2026-06-12T10:02:44Z"
    }
  ]
}

Revocation cuts future delegations for that user (the exchange requires the authorization and is bounded by its scopes) and also revokes existing refresh tokens for that user and agent pair. Only agents subject to user authorization appear here: first-party trusted agents delegate without a per-user grant.

The attested access review, as a complement

The forensic log tells you what happened; the access review attests that a human checked what should be allowed. Every agent carries a reviewedAt timestamp and a needsReview flag (never reviewed, or reviewed more than 90 days ago), and an admin attests the review from the inventory. See Agent identity.