Conectar um harness de código

Um harness de código, como o Claude Code ou o Codex, se conecta ao Xokepoint sem arquivo de chave. O desenvolvedor adiciona uma URL, entra com o provedor de identidade da empresa no navegador e autoriza o agente. Depois o harness chama as tools que o agente permite, com uma pessoa presente atrás de cada chamada.

Esta página é o modo interativo. Para um agente que roda como serviço com chave própria, veja Integrar o agente.

O que você precisaCopiar link da seção

• A URL MCP de cada server, que o administrador entrega. O card Harness login do agente mostra uma URL para cada server (Identidade do agente):

  Copiar texto

  <origin>/api/v1/mcp/<workspace>/<ambiente>/<server_id>

• Uma conta no provedor de identidade da empresa, num grupo que o administrador liberou para o agente (Quem pode delegar).

• Um harness que o administrador liberou para o agente. Claude Code e Codex estão no catálogo. Outro harness funciona quando o fornecedor publica um client metadata document e o administrador adiciona a URL dele.

Adicionar a URL ao harnessCopiar link da seção

Claude Code:

claude mcp add --transport http acme-issues <URL MCP>

Depois rode /mcp no Claude Code e escolha o server para entrar.

Codex:

codex mcp add acme-issues --url <URL MCP>
codex mcp login acme-issues

O login abre o navegador.

Adicione uma entrada para cada server. O token é para o ingress MCP do ambiente, não para um server, então vale para todos os servers do agente. Mesmo assim o harness pode pedir um login para cada entrada; cada login é uma máquina própria.

O que o harness fazCopiar link da seção

O harness segue a especificação de autorização do MCP. Nada nele é específico do Xokepoint:

1. Descoberta. Todo 401 do ingress traz WWW-Authenticate com um challenge Bearer e um DPoP, cada um com resource_metadata, a URL do protected resource metadata (RFC 9728). O challenge DPoP lista em algs os algoritmos de prova aceitos (Validação do token). Um harness que começa o login sem uma requisição, como o claude mcp login, monta a mesma URL a partir da URL MCP. Ele aponta o authorization server do ambiente, cujo metadata (RFC 8414) lista o authorization endpoint, os grants e client_id_metadata_document_supported.
2. Identidade do cliente. O harness envia como client_id a URL HTTPS do seu Client ID Metadata Document (CIMD): um arquivo público do fornecedor com o nome do harness e as redirect URIs dele. O Xokepoint aceita só as URLs que o administrador liberou para um agente. Não há registro dinâmico de cliente.
3. Requisição de autorização. Authorization code com PKCE S256 (RFC 7636), uma redirect URI loopback (http://127.0.0.1, http://[::1] ou http://localhost, qualquer porta, RFC 8252) listada no documento CIMD, e resource igual ao ingress MCP do ambiente (RFC 8707). Um client_id desconhecido ou uma redirect URI inválida param numa página de erro, antes de qualquer login.
4. Token. O harness troca o code no token endpoint com o seu code_verifier. O code vale 60 segundos e é usado uma vez.

Entrar e consentirCopiar link da seção

O navegador abre páginas servidas pelo authorization server do Xokepoint, com a marca Xokepoint e os nomes do workspace e do ambiente:

1. Sign in to continue: só quando mais de um provedor de identidade aceita harness login. Escolha o seu.
2. Login no provedor de identidade da empresa, como em qualquer app da empresa.
3. Choose how {harness} works for you: só quando você é elegível para mais de um agente deste harness, por exemplo "Claude Code — Developers" e "Claude Code — SRE". Cada opção mostra os servers e o grupo que te torna elegível.
4. Allow {agente} to act for you?: o harness, com quem você entrou e por qual grupo, It will be able to use (servers, tools e resources) e a validade: "Valid for {n} days, until {data}." O consentimento vale só para este computador, e o administrador pode revogá-lo a qualquer momento. Allow ou Deny.
5. You are connected: volte ao harness e feche a aba.

Toda chamada continua verificada pelo Xokepoint com as regras do agente. O consentimento diz que você deixa o agente agir por você; não muda o que o agente pode fazer.

Quando você é recusadoCopiar link da seção

Toda página de recusa termina com "Contact your administrators with the code {código}, workspace {workspace}, environment {ambiente}." Mande os três. O administrador abre esse ambiente e cola o código no Quick incident, que mostra por que o login foi recusado.

Uma tool call que o Xokepoint nega também mostra um código, na mensagem de erro do harness: "Access denied. Reference {código}." Mande do mesmo jeito.

Tokens e refreshCopiar link da seção

• O access token dura 5 minutos, como no modo headless. Ele carrega chokepoint_subject.presence: interactive e o grant_id desta máquina (Token exchange).
• O harness renova o token com um refresh token. O refresh token gira a cada uso, termina depois de 24 horas sem uso e nunca dura mais que o consentimento. Quando ele termina, o harness pede para você entrar de novo.
• Um refresh token ou code usado duas vezes revoga a máquina na hora. Um token roubado e reusado para de funcionar para as duas cópias, e o reuso aparece no Investigate como refresh_reuse ou code_reuse.
• Cada login é uma máquina. O administrador vê a máquina em Harness sessions e pode revogá-la sozinha.

DPoP (opcional)Copiar link da seção

Quando o harness envia uma prova DPoP (RFC 9449) na troca do code, o token fica preso à chave dele (cnf.jkt). A partir daí o harness precisa chamar com Authorization: DPoP e uma prova nova em cada requisição e cada refresh; um token copiado sem a chave é recusado com 401 invalid_dpop_proof no ingress (Validação do token). No token endpoint, uma troca do code ou um refresh com prova inválida, ou um refresh de grant preso sem prova, fica registrado como dpop_invalid. Um harness sem DPoP recebe um token bearer. Uma condição de chamada pode exigir um token preso com context.chokepoint.binding == "dpop" (Condições).