Observabilidade
O decision trace de cada chamada, o events export, o registro de cada token exchange e os sinais de atenção que chegam ao administrador.
Uma política só é confiável se dá para ver o que ela decidiu e por quê. O Xokepoint registra cada decisão de tool call e cada tentativa de token exchange, e transforma padrões de negação em sinais para o administrador.
Decision trace
Cada decisão registra o sujeito (issuer, subject, tipo e connection), o agente verificado, o server, a tool, o recurso concreto quando o mapping nomeia um, a hora, a decisão e, no DENY, o motivo: no_delegation, no_grant, no_resource ou condition.
A evidência mostra cada passo da ordem de avaliação, delegation, capability, resource e condition, com o estado de cada um: passou, falhou, não se aplica ou não avaliado. Também mostra cada relação consultada e o resultado, e cada condição com nome, expressão, bindings e resultado.
Os valores avaliados nunca são gravados. A evidência diz que a condição de limite de reembolso deu falso, mas não grava o valor do reembolso nem o limite. Argumentos de tools e fatos de APIs do cliente podem ter dados sensíveis, e o trace não deve virar uma cópia deles.
A gravação não atrasa a chamada. O PEP entrega o registro a um buffer em memória, e um escritor em segundo plano grava em lotes. Registros mais velhos que o período de retenção são apagados.
Events export
O time de segurança investiga incidentes na ferramenta que já opera, como Splunk, Datadog ou o SIEM da empresa. O Xokepoint envia o trace para lá: cada chamada permitida ou negada, cada token exchange e cada harness login sai como log record OpenTelemetry, por OTLP, ou como webhook assinado.
Cada evento leva o agente, a pessoa em nome de quem ele agiu, a tool, o resultado e, numa recusa, o código Reference. Com o código, o analista vai do evento no SIEM até a mesma recusa no Quick incident.
O export segue a regra do trace: valores avaliados, argumentos de tools e fatos de APIs do cliente não saem no evento. A página Events export mostra os destinos, os campos do evento, a assinatura do webhook e a entrega.
Registro de emissão
O token exchange é o único lugar onde o Xokepoint vê que um usuário perdeu acesso no IdP, porque não sincroniza o ciclo de vida dos usuários (Revogação). Por isso cada troca é registrada com hora, sujeito, agente, resultado e motivo. Harness logins e refreshes ficam registrados no mesmo lugar, com a presença (interactive) e o grant da máquina; um login recusado também guarda o código de referência que a pessoa vê, então uma busca o encontra:
| Motivo | Causa |
|---|---|
invalid_client | A client assertion do agente falhou |
subject_token_expired | O token do sujeito tem assinatura válida e venceu |
subject_token_invalid | Outra falha no token do sujeito: assinatura, issuer ou audience |
subject_connection_disabled | A identity connection do sujeito está desabilitada |
no_delegation | O sujeito não delegou para o agente |
invalid_authorization_details | A instância pediu limites com formato inválido, ou para uma tool que o agente não pode chamar |
no_group | Harness login: a pessoa não está num grupo elegível |
blocked | Harness login: a pessoa está bloqueada no agente |
not_allowed_client | Harness login: o harness não está liberado para o agente |
code_reuse | Um authorization code foi usado duas vezes; a máquina foi revogada |
refresh_reuse | Um refresh token foi usado duas vezes; a máquina foi revogada |
dpop_invalid | A prova DPoP falta, é inválida ou é de outra chave |
O sujeito só é registrado quando a assinatura do token dele é válida. Gravar o sub de um token forjado poria no registro um nome que ninguém provou. Tokens e assertions nunca são gravados.
Sinais de atenção
Um job agrupa as negações por server, tool, agente, motivo e hora UTC e levanta um sinal para cada grupo. Trocas negadas viram sinais por agente, motivo e hora, e também por sujeito quando o token do sujeito estava expirado ou inválido. O administrador vê os sinais no Inbox do Admin, revisa e marca como resolvidos.
Um sinal guarda IDs, nunca nomes. O Inbox lê o nome do agente, e o nome do sujeito no diretório de identidade, na hora de mostrar o sinal. Um agente renomeado aparece com o nome atual, e um diretório fora do ar só deixa o sujeito cru na tela; nunca derruba o Inbox.