Observability
The decision trace of each call, the events export, the record of each token exchange and the attention signals that reach the administrator.
A policy is only trustworthy if you can see what it decided and why. Xokepoint records each tool call decision and each token exchange attempt, and turns denial patterns into signals for the administrator.
Decision trace
Each decision records the subject (issuer, subject, kind and connection), the verified agent, the server, the tool, the concrete resource when the mapping names one, the time, the decision and, on DENY, the reason: no_delegation, no_grant, no_resource or condition.
The evidence shows each step of the evaluation order, delegation, capability, resource and condition, with the state of each: passed, failed, not applicable or not evaluated. It also shows each relation checked and its result, and each condition with name, expression, bindings and result.
Evaluated values are never recorded. The evidence says that the refund limit condition was false, but it does not record the refund amount or the limit. Tool arguments and facts from customer APIs can contain sensitive data, and the trace must not become a copy of them.
Recording does not delay the call. The PEP hands the record to an in-memory buffer, and a background writer stores it in batches. Records older than the retention period are deleted.
Events export
The security team investigates incidents in the tool it already runs, such as Splunk, Datadog or the company SIEM. Xokepoint sends the trace there: each allowed or denied call, each token exchange and each harness login goes out as an OpenTelemetry log record, over OTLP, or as a signed webhook.
Each event carries the agent, the person it acted for, the tool, the result and, on a denial, the Reference code. With the code, the analyst goes from the event in the SIEM to the same denial in Quick incident.
The export follows the rule of the trace: evaluated values, tool arguments and facts from customer APIs are not in the event. Events export shows the destinations, the event fields, the webhook signature and the delivery.
Issuance record
The token exchange is the only place where Xokepoint sees that a user lost access in the IdP, because it does not synchronize user lifecycle (Revocation). So each exchange is recorded with time, subject, agent, result and reason. Harness logins and refreshes are recorded in the same place, with the presence (interactive) and the grant of the machine; a refused login also keeps the reference code that the person sees, so a search finds it:
| Reason | Cause |
|---|---|
invalid_client | The agent client assertion failed |
subject_token_expired | The subject token has a valid signature and is expired |
subject_token_invalid | Another subject token failure: signature, issuer or audience |
subject_connection_disabled | The subject identity connection is disabled |
no_delegation | The subject did not delegate to the agent |
invalid_authorization_details | The instance asked for limits with a bad shape, or for a tool the agent cannot call |
no_group | Harness login: the person is not in an eligible group |
blocked | Harness login: the person is blocked on the agent |
not_allowed_client | Harness login: the harness is not allowed for the agent |
code_reuse | An authorization code was used twice; the machine was revoked |
refresh_reuse | A refresh token was used twice; the machine was revoked |
dpop_invalid | The DPoP proof is missing, invalid or from another key |
The subject is recorded only when the signature of its token is valid. Recording the sub of a forged token would put in the record a name that nobody proved. Tokens and assertions are never recorded.
Attention signals
A job groups denials by server, tool, agent, reason and UTC hour and raises a signal for each group. Denied exchanges become signals per agent, reason and hour, and also per subject when the subject token was expired or invalid. The administrator sees the signals in the Admin Inbox, reviews them and marks them as resolved.
A signal stores IDs, never names. The Inbox reads the name of the agent, and the name of the subject from the identity directory, when it shows the signal. A renamed agent shows its current name, and a directory that is down only leaves the raw subject on screen; it never fails the Inbox.