Agentes
O agente é uma identidade própria, registrada no Xokepoint e verificada em cada chamada.
O agente é o software que decide quais tools chamar: um assistente, um copiloto, um worker de automação. No Xokepoint ele tem identidade própria, separada do sujeito por quem age.
Um token emitido pelo IdP do cliente às vezes traz um client_id ou um azp. Parece suficiente para saber qual agente está chamando, mas esses campos dizem só qual aplicação pediu o token. Eles não provam que aquele agente tem autorização da pessoa para agir por ela. O Xokepoint não usa esses campos para decidir acesso.
Dois modos
Um agente obtém o token Xokepoint em um de dois modos. Um agente pode usar os dois, e o token diz qual modo o emitiu (presence).
| Modo | Quem roda o agente | Como obtém o token | Presence |
|---|---|---|---|
| Headless | Um serviço, sem pessoa no teclado | Prova quem é com a chave e troca o token do sujeito (Token exchange) | headless |
| Interativo | Uma pessoa, a partir de um harness de código como o Claude Code | O harness se identifica pela URL do client metadata, a pessoa entra com o IdP da empresa e consente, e cada login é um grant de uma máquina (Conectar um harness de código) | interactive |
No modo interativo, o harness não é o agente. O administrador cria o agente (por exemplo "Claude Code — Developers"), com tools e regras, e libera para ele a URL do client metadata do harness. Cada pessoa que entra é um grant desse agente, e as regras são as mesmas para todas. O mesmo harness pode ser liberado para vários agentes, escolhidos no login pelos grupos da pessoa.
O agente prova quem é
Esta seção é o modo headless.
Cada agente tem um registro de cliente no authorization server do Xokepoint, com uma chave pública. A chave privada fica com o agente, e o Xokepoint nunca a recebe. Para se autenticar, o agente assina um JWT curto, a client assertion, e o AS confere a assinatura com a chave registrada. É o método private_key_jwt do RFC 7523. Não há segredo compartilhado que possa vazar de um dos lados.
Um agente tem uma chave por vez: EC P-256 (ES256) ou RSA de 2048 bits ou mais (RS256). O Admin pode gerar o par no navegador, e aí a chave privada só existe no arquivo que o administrador baixa, ou registrar uma chave pública que o cliente já guarda num cofre. Trocar a chave invalida a anterior na hora. Não há janela de sobreposição: tokens já emitidos continuam valendo até expirar, o que leva no máximo 5 minutos.
O agente em cada chamada
O token que o agente usa nas tool calls leva o agente no claim act, definido no RFC 8693. Em cada chamada o PEP confere que o agente ainda existe no mesmo workspace e ambiente e que o status dele está ativo. Num token headless, o agente ainda precisa ter uma chave. Num token interativo, o grant da máquina e o consentimento da pessoa ainda precisam estar ativos.
O status é o kill switch. Desativar um agente recusa a próxima troca de token, harness login ou refresh e a próxima tool call dele, mesmo com um token que ainda tem minutos de vida. Nada mais muda: delegações, permissões e chave ficam como estavam, então reativar o agente o devolve exatamente como era. É o jeito mais rápido de parar um agente que se comporta mal enquanto o time descobre o porquê.
O agente também tem um modo de enforcement. Em Enforce, o padrão, todo deny da política dele bloqueia a chamada. Em Report-only, um deny da política (uma tool sem grant, um recurso fora dos concedidos, uma regra de chamada falsa) não bloqueia: a chamada roda e o registro marca Would deny; delegação, token, identity connection, kill switch e qualquer erro de avaliação continuam bloqueando. Como o status, o modo é lido a cada chamada, então uma troca vale já na próxima, mesmo com um token ainda válido. Report-only mostra como usar.