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

HARNESS · CONFIANÇA · ATUALIZADA EM

O que o Harness garante, e o que ainda não.

Arquitetura, camadas de isolamento, limites declarados, chaves públicas dos recibos e como relatar uma vulnerabilidade. Escrito para quem compra e para quem audita.

Acesso antecipado, por convite. Ainda não há revisão de segurança externa nem certificação de terceiros. Quando houver, o resumo entra nesta página.

01 / ARQUITETURA

Cinco camadas entre o navegador e o servidor.

Cada camada responde por uma coisa. Nenhuma depende de a outra estar certa para negar.

  1. 01

    Borda

    TLS, cabeçalhos de segurança e política de conteúdo sem script inline em todas as páginas. Rota operacional sem credencial responde 401.

  2. 02

    Gateway

    Convite de uso único com 7 dias de validade, senha de 12 ou mais caracteres guardada com scrypt, cookie __Host- HttpOnly e SameSite=Strict, origem conferida em todo POST e no WebSocket, 10 tentativas de login por IP a cada 15 minutos e eventos só de inserção.

  3. 03

    Política antes da ação

    Hook gerenciado do Claude Code em toda ferramenta, inclusive MCP. A configuração fica em /etc/claude-code/managed-settings.json, numa raiz só leitura.

  4. 04

    Contêiner por pessoa

    Usuário sem privilégios, todas as capabilities removidas, no-new-privileges, raiz só leitura, /tmp em memória, teto de 1 vCPU, 2 GB e 512 processos. Sem tráfego entre workspaces; os serviços internos do servidor não são alcançáveis.

  5. 05

    gVisor

    O shell fala com um kernel próprio (runsc), não com o kernel do servidor.

Fig. 1 As camadas do IDE Cloud, de fora para dentro. Cada camada nega sozinha; nenhuma depende de a outra estar certa.Fonte: definição fixa do contêiner e configuração do gateway do IDE Cloud 0.4.0, em .

02 / GARANTIAS E LIMITES

O que a política garante, e o que não.

Os limites ficam escritos ao lado das garantias. Limite escondido é risco sem dono.

Garante

  • Toda ferramenta do Claude Code passa pela política antes de rodar. Inclusive MCP. Um deny da política vence qualquer allow de outro hook.AtivoProva: configuração gerenciada da imagem, com matcher: "*" no PreToolUse.
  • Falha fechada. Sem resposta do gateway, tempo esgotado ou erro, a ação é negada. Está no código do hook e na configuração do Claude Code ("onFailure": "block").AtivoProva: testes do prazo do hook e da configuração gerenciada, rodados a cada deploy da imagem.
  • Aprovação presa ao pedido. Dada só no navegador, com sessão e origem conferidas, ligada ao hash da entrada e válida uma vez. Se a entrada muda, a aprovação não vale. O token do workspace não aprova nada.AtivoProva: testes de governança do gateway, inclusive pedido alterado depois da aprovação.
  • Recibo de cada decisão. Decisão, aprovação e resultado entram na mesma cadeia, assinada com Ed25519. Mudar um campo quebra o hash, a assinatura e o elo seguinte.AtivoProva: conferência no painel Recibos do IDE e o script desta página.
  • Pessoa no envio externo. A política padrão pede aprovação para deploy, publicação, acesso remoto, requisição externa, WebFetch, conector MCP, dado pessoal ou confidencial na entrada e ferramenta desconhecida.AtivoProva: a mesma regra do runtime, com as cópias do gateway travadas por teste.
  • Branch protegida só muda com uma pessoa, também no próprio git. Commit, merge, rebase, reset ou push na main pedem aprovação na política. Além disso, o git de todo repositório do workspace pergunta ao Harness antes de um agente (Claude Code ou Codex) mudar uma branch protegida; sem aprovação humana recente, o git recusa. O agente não consegue desligar essa guarda.AtivoProva: autoteste da imagem a cada deploy (agente barrado na main, pessoa no terminal segue) e recibo ref de cada decisão.
  • No console, quem pede não aprova. O recibo guarda só impressões digitais (HMAC) do pedido e da resposta, nunca o texto.AtivoProva: testes de execução do runtime, inclusive aprovador igual ao solicitante.

Não garante

  • O Codex não tem hook equivalente. No IDE Cloud, as ações do Codex não passam pela política e não geram recibo. A guarda da main no git vale para ele: o Codex não muda uma branch protegida sem aprovação.
  • O dono do workspace pode contornar o hook no próprio contêiner. Por exemplo, rodando comandos fora do agente. O recibo prova o que passou pela política, não a ausência do que não passou.
  • Comando de shell classificado pelo texto é sinal, não prova. Na dúvida, a política pede uma pessoa. Por isso a main também é guardada no git, onde a branch muda de fato. Repositório que define os próprios hooks (por exemplo, husky) fica só com a política.
  • Internet aberta no workspace. APIs de IA, npm, GitHub e o resto. A lista de destinos permitidos é o próximo passo.
  • Sem cota rígida de disco. Há aviso na tela acima de 8 GB.
  • Mesmo servidor dos sites da Reveno. O gVisor reduz o risco; um servidor dedicado ao IDE separa o raio de impacto.
  • O gateway fala com o Docker, o que equivale a root no servidor. Por isso ele só cria contêineres por uma definição fixa, com nome tirado do id interno da pessoa, nunca de texto digitado.
  • No runtime, a execução alcança qualquer porta de 127.0.0.1. Risco aceito porque só roda código da Reveno e a saída do modelo nunca é executada.
  • Correção só chega ao workspace recriado. Um contêiner criado antes de uma correção segue na imagem antiga até ser recriado.
  • A demo pública não executa nada. Os recibos dela são de ensaio, encadeados por SHA-256 e sem assinatura.

03 / RECIBOS

Chaves públicas e como conferir.

Ninguém precisa confiar na tela da Reveno. A conferência roda com a chave pública e um recibo.

Chaves públicas Ed25519 dos recibos do Harness
ChaveAssinaSHA-256 da chave pública (SPKI DER)
k_2026-10-26_ad98e2c7Recibos do console do runtime691e69cb475f5cd6fda5ce9d52d174a50ae15019436b691993b2bc272c68505e
ide_4c194d4015439bccRecibos das ações do agente no IDE Cloudbf60db7332bf13395041b507e8ef5f98088aa44596c3df056ac481ab7bd9dc0c
Fig. 2 As chaves que assinam os recibos. Compare a impressão digital antes de confiar numa assinatura.Fonte: chaves ativas em , publicadas nos endereços abaixo.

Publicadas em /.well-known/harness-keys.json (runtime) e em /cloud/api/chaves (runtime e IDE Cloud, com JWK). Depois de uma troca, a chave antiga continua publicada para os recibos antigos seguirem conferíveis.

  1. Confira a chave

    Baixe a chave e compare a impressão digital com a tabela: openssl pkey -pubin -in chave.pem -outform DER | openssl dgst -sha256.

  2. Recalcule o hash

    SHA-256 do corpo canônico do recibo (chaves em ordem alfabética, sem espaços) tem de ser igual ao campo hash.

  3. Confira a assinatura

    Ed25519 sobre o texto do hash, com a chave indicada no recibo (chave_id no runtime, kid no IDE Cloud). A assinatura vem em base64url.

  4. Siga a cadeia

    Cada recibo aponta para o hash do anterior (hash_anterior no runtime, parent_attestation_id no IDE Cloud). O primeiro elo que não confere marca o ponto da alteração.

Fora do navegador, com Node 18 ou mais novo e nenhuma dependência:

// verificar.mjs  ·  uso: node verificar.mjs recibo.json chave.pem
import { createHash, createPublicKey, verify } from 'node:crypto';
import { readFileSync } from 'node:fs';

const canon = (v) => v === null || typeof v !== 'object' ? JSON.stringify(v ?? null)
  : Array.isArray(v) ? `[${v.map(canon).join(',')}]`
  : `{${Object.keys(v).filter((k) => v[k] !== undefined).sort().map((k) => `${JSON.stringify(k)}:${canon(v[k])}`).join(',')}}`;

const r = JSON.parse(readFileSync(process.argv[2], 'utf8'));
const corpo = typeof r.corpo === 'string' ? r.corpo : canon(r.corpo);
const hashOk = createHash('sha256').update(corpo).digest('hex') === r.hash;
const chave = createPublicKey(readFileSync(process.argv[3]));
const assinaturaOk = verify(null, Buffer.from(r.hash), chave, Buffer.from(r.assinatura, 'base64url'));
console.log(JSON.stringify({ hashOk, assinaturaOk }));
process.exit(hashOk && assinaturaOk ? 0 : 1);
Fig. 3 Verificação fora do navegador. Sai 0 quando hash e assinatura conferem e 1 quando não.Fonte: o mesmo texto que o teste do site roda contra um recibo assinado e um adulterado a cada build.

No navegador, o console confere hash, cadeia e assinatura dos recibos reais. Os recibos de ensaio da demo se conferem em Como funciona.

04 / STATUS

Saúde do ecossistema, à vista.

Os quatro produtos da Reveno, o Harness entre eles, têm a saúde conferida automaticamente e publicada numa página única, com o motivo de cada falha.

Ver o status do ecossistema

05 / DIVULGAÇÃO DE VULNERABILIDADES

Achou uma falha? Fale com a gente primeiro.

Relato de boa-fé é bem-vindo. Ajuda mais do que qualquer selo.

CONTATO

contact@thiagoholtz.com

Assunto: Segurança: Harness. Contato oficial da Reveno.

O que mandar
O que você encontrou, os passos para reproduzir, o impacto que enxerga, a URL e a versão (está no rodapé de cada página) e como falar com você. Não mande dado pessoal de terceiros; se a prova depender dele, descreva sem copiar.
Escopo
harness.reveno.com.br, incluindo o IDE Cloud (/cloud/), o runtime (/api/runtime/), as chaves públicas e a imagem do workspace. Serviços de terceiros, como provedores de modelo e o GitHub, ficam fora.
Regras de boa-fé
Teste só no seu próprio workspace e com contas de teste. Não acesse, altere nem guarde dado de outra pessoa. Nada de negação de serviço, teste de volume ou engenharia social. Dê tempo para a correção antes de publicar, com data combinada entre nós.
Como respondemos
Confirmamos o recebimento, contamos o que vamos fazer e, com a correção no ar, publicamos o aviso nesta página, com crédito a você se quiser. Hoje não há programa de recompensa em dinheiro.

06 / AVISOS RESOLVIDOS

O que já corrigimos, contado como foi.

Aviso resolvido fica publicado. Esconder correção ensina o comprador a desconfiar.

HX-2026-01

O hook de política podia deixar uma ação seguir quando estourava o tempo

Estado
Resolvido
Identificado
Resolvido
Afetava
IDE Cloud, hook reveno-harness do Claude Code (PreToolUse)
Encontrado por
Revisão interna da Reveno, não por relato externo

O que acontecia

Quando uma ação pedia aprovação e a rede estava lenta, o hook somava a espera da aprovação (até 118 segundos) ao tempo da primeira chamada ao gateway (até 8 segundos) e podia passar do teto de 130 segundos que o Claude Code dá a ele. Por padrão, o Claude Code trata um hook encerrado por tempo como falha que não bloqueia: a ação seguia para as permissões do próprio Claude Code, em vez de ser negada pelo Harness.

O alcance

Só ações que esperavam aprovação e cujo hook foi encerrado por tempo. Ações permitidas ou negadas direto pela política não mudavam. O Codex não estava coberto pela política antes nem depois, como diz a seção de limites.

A correção

Prazo rígido de 120 segundos contado desde o início do hook, cada chamada limitada ao tempo restante, uma vigia que nega antes do teto e negação em qualquer erro inesperado. Na configuração gerenciada, "onFailure": "block" faz o Claude Code bloquear se o hook falhar, e a versão mínima exigida passou a 2.1.295, a que tem essa opção. O teste da imagem confere a trava.

O que fazer

Nenhuma ação de quem usa. A correção vale para todo workspace criado ou recriado com a imagem atual.

COMO ENTRAR

Por convite, sem preço publicado.

O acesso antecipado abre workspace a workspace. O preço do Harness ainda não está publicado, e o custo do modelo de IA é da conta de quem usa. Para levar dono, política, aprovação e registro aos fluxos que a empresa já tem, a Reveno começa pelo Diagnóstico.

Entrar na lista Os quatro passos e os limites de cada workspace Solicitar o Diagnóstico
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.