Pular para o conteúdo
reveno / Harness
ENEntrar na lista

HARNESS · COMO FUNCIONA

A política decide antes de qualquer ação.

Cada pedido de agente passa pelas mesmas verificações, na mesma ordem. Se uma falha, o pedido é negado e o motivo vira recibo.

EM UMA IMAGEM

A decisão vem antes da ação.

Cada pedido sai permitido, à espera de uma pessoa ou negado. Não existe uma quarta saída.

A decisão antes da açãoO pedido do agente chega à política, que confere dono identificado, escopo para o dado, limite do workspace, provider permitido e se a ação é sensível. Há três saídas. Permitir: a ação segue. Pedir aprovação: uma pessoa decide no navegador, e recusa ou prazo esgotado viram negação. Negar: a ação não roda e o motivo fica registrado. Cada decisão vira um recibo assinado com Ed25519 e encadeado ao anterior. Se a política não responde, o tempo se esgota ou há erro, a ação é negada mesmo sem recibo.Pedido do agenteferramenta, entradae hash da entradaA política decidedono identificadoescopo para o dadodentro do workspaceprovider permitidoação sensível?Permitira ação segueno workspacePedir aprovaçãouma pessoa deciderecusou ou expirou: negaNegara ação não rodamotivo registradoFalha fechadasem resposta, tempoesgotado ou erro: negaRecibo assinadoEd25519, encadeadoao recibo anteriorA decisão antes da açãoO pedido do agente chega à política, que confere dono identificado, escopo para o dado, limite do workspace, provider permitido e se a ação é sensível. Há três saídas. Permitir: a ação segue. Pedir aprovação: uma pessoa decide no navegador, e recusa ou prazo esgotado viram negação. Negar: a ação não roda e o motivo fica registrado. Cada decisão vira um recibo assinado com Ed25519 e encadeado ao anterior. Se a política não responde, o tempo se esgota ou há erro, a ação é negada mesmo sem recibo.Pedido do agenteferramenta, entrada e hash da entradaA política decidedono identificadoescopo para o dadodentro do workspaceprovider permitidoação sensível?Permitira ação segue no workspacePedir aprovaçãouma pessoa deciderecusou ou expirou: negaNegara ação não rodamotivo registradoFalha fechadasem resposta, tempoesgotado ou erro: negaRecibo assinadoEd25519, encadeadoao recibo anterior
Fig. 1 A decisão antes da ação. Todo pedido sai por uma de três portas, e cada decisão deixa um recibo assinado. Quando a política não consegue decidir, a resposta é não, com ou sem recibo.Fonte: regra do gateway do IDE Cloud 0.4.0 (no ar desde 02/11/2026) e do runtime 0.1.0. Desenho próprio, gerado no build.

O que falha fechada quer dizer para quem compra

Se a política não responde, demora demais ou dá erro, a ação não acontece. O risco de uma falha técnica é um agente parado, nunca um agente solto. Quando o próprio caminho cai, pode não sobrar recibo, mas a falta de recibo nunca vira permissão.

Como isso está montado no IDE Cloud

O hook gerenciado do Claude Code tem um prazo rígido de 120 segundos contado desde o início, limita cada chamada ao tempo restante e nega antes do teto. A configuração gerenciada manda o Claude Code bloquear se o próprio hook falhar ("onFailure": "block") e exige a versão que tem essa opção. Os limites que continuam abertos estão na página de confiança.

01 / ORDEM DAS VERIFICAÇÕES

Falha fechada, em seis passos.

É a regra do plano de controle do Harness, a mesma em Python e em JavaScript.

  1. 01

    Identidade

    O pedido tem um dono autenticado? Sem dono, nada roda.

    authentication_required
  2. 02

    Escopo para o dado

    O papel do dono cobre a classe do dado: pública, interna, confidencial ou pessoal?

    scope_required
  3. 03

    Runtime

    Executar exige o runtime habilitado. Planejar não.

    runtime_not_enabled
  4. 04

    Isolamento do workspace

    O alvo fica dentro da raiz do workspace? Travessia de diretório é negada.

    workspace_boundary_violation
  5. 05

    Provider

    A skill usa um provider conhecido e habilitado? Rede de saída direta fica bloqueada.

    external_provider_blocked
  6. 06

    Aprovação

    Ações sensíveis esperam uma pessoa, e quem pede não aprova.

    human_approval_required
Fig. 2 A ordem das verificações. A primeira que falha decide, e o código dela vai para o recibo.Fonte: /policy-engine.js, a mesma regra que a demo usa, travada pelos vetores de teste do plano de controle.

02 / MOTIVOS REGISTRADOS

Todo resultado tem um código.

O código vai para o recibo. É assim que a decisão pode ser auditada depois.

Códigos de decisão do plano de controle
CódigoO que significaResultado
preview_onlyPlanejar ou ler foi permitido; nada foi alterado.permitido
execution_not_implementedTodas as verificações passaram; nesta fase a execução é simulada.simulado
human_approval_requiredAção sensível sem aprovação de uma pessoa.espera
authentication_requiredPedido sem dono identificado.negado
scope_requiredO papel do dono não cobre a classe do dado.negado
runtime_not_enabledExecutar sem runtime habilitado.negado
workspace_boundary_violationAlvo fora da raiz do workspace.negado
external_provider_blockedSkill com rede de saída direta.negado
provider_disabledProvider bloqueado na política.negado
Fig. 3 Os códigos de decisão. Três resultados possíveis além da negação: permitido, simulado e à espera de uma pessoa.Fonte: códigos de motivo de /policy-engine.js; o verify-release.sh recusa publicar se algum faltar.

03 / VERIFICAR UM RECIBO

Cole o JSON e recalcule.

Exporte os recibos na demo e cole aqui. O verificador recalcula cada hash no seu navegador e aponta o primeiro recibo que não confere. Hoje o recibo é um hash SHA-256 encadeado; a assinatura por chave chega com o acesso antecipado.

Gerar recibos na demo

Descobrir · aberto e gratuitoAgents & SkillsSkills, agents e servidores MCP com origem e triagem.Operar · acesso antecipadoHarnessO IDE cloud onde cada agente roda com dono e recibo.Decidir · acesso antecipadoEvidenceDados sintéticos para testar a decisão antes de investir.