# O que seu cliente verifica antes de enviar os dados dele

> Um deploy confidencial que ninguém confere é um deploy comum com custo extra. Esta é a lista que uma contraparte séria executa, o que o seu lado precisa publicar para passar por ela, e os limites que vale dizer você mesmo antes de perguntarem.

2026-09-20 · https://synsema.com/pt/blog/o-que-seu-cliente-verifica-antes-de-enviar-os-dados


"A gente roda num TEE" é uma afirmação. Do outro lado da mesa existe alguém cujo trabalho é transformar afirmações em verificações, e essa pessoa vai fazer três perguntas: *que código está rodando, quem garante isso, e o que esse código faz com os meus dados?*

A boa notícia é que as três têm resposta mecânica. O trabalho é publicar essas respostas antes da reunião, e não durante.

## A lista que eles executam

**1. Buscar a identidade.** Um serviço atestado publica `GET /.well-known/attestation`: o documento assinado pela plataforma, a chave pública, o hash do programa e o hash da configuração sob a qual ele roda.

**2. Verificar o documento.** Assinatura, cadeia de certificados até a raiz da plataforma, janela de validade — falhando fechado na primeira dúvida. Com Synsema no cliente isso é uma chamada, com o relógio passado explicitamente em vez de lido do host:

```synsema
let v be attestation_verify(bytes(seen["document"], "base64"),
    {"format": seen["format"], "now": floor(now()),
     "expect": {"measurements": {"pcr0": PINNED}}})
```

**3. Recalcular a amarração.** O documento se compromete com `sha256(chave_pública ‖ program_sha ‖ config_sha)`. Um documento que verifica mas amarra *outra* chave ou outro programa não vale nada; uma chave que bate mas não tem documento é só uma chave. A ordem importa: verificar, recalcular, comparar e **só então** enviar.

**4. Ler a configuração.** `config` carrega o teto sob o qual o programa rodou, se os rótulos de fluxo de informação estavam ligados, o perfil, e se a chave anunciada é a que termina o TLS. O hash dela está dentro do payload assinado, então não dá para atestar uma configuração endurecida e servir uma frouxa.

**5. Perguntar o que sai.** Esta é a pergunta que o hardware não responde, e a que decide o negócio. `synsema code check --json` lista cada `declassify` do programa com a linha e a frase que quem escreveu registrou:

```json
"declassify": [
  {"line": 11, "reason": "the yes/no is what the lender asked for; the score stays inside"}
]
```

Uma entrada, uma frase, aplicada em tempo de execução: todo o resto que for privado é recusado na resposta, no log e no arquivo — antes de o efeito acontecer.

## O que o seu lado publica

Coloque estas quatro coisas onde um desconhecido consiga achar sem te perguntar:

- **O `program_sha`** da versão, e a **medição esperada da plataforma** (PCR0 no Nitro, MRTD/RTMRs no TDX, `measurement` no SEV-SNP) tirada da própria etapa de build da plataforma.
- **A procedência do motor.** `gh attestation verify synsema-linux-x86_64 --repo kitecosmic/synsema` responde com o workflow, o commit e a tag que produziram exatamente aqueles bytes. Atestar um programa executado por um interpretador de origem desconhecida atesta a metade errada, e um bom revisor sabe disso.
- **A lista de desclassificações** da versão que você está rodando, em palavras.
- **Um verificador que eles possam rodar** — vinte linhas, sem SDK, sem conta.

Uma página com essas quatro coisas vale mais numa conversa de compras do que qualquer quantidade de prosa sobre isolamento por hardware.

## Os limites — diga você primeiro

Marcar a fronteira você mesmo é o que separa uma afirmação de engenharia de uma de marketing, e quem revisa percebe:

- **Uma atestação prova que código roda, não que o código é bom.** É exatamente por isso que a lista de desclassificações fica ao lado.
- **Ela não impede o operador de recusar o serviço, descartar uma requisição ou desligar a máquina.** Confidencialidade e disponibilidade são propriedades diferentes.
- **Canais laterais não são cobertos por uma assinatura.** Tempo, tamanhos e a quantidade de linhas que um programa imprime vazam, e por isso a linguagem trata um print dentro de um ramo que dependeu de dados privados como violação em vez de redigir o valor — mas ninguém deveria afirmar que a classe está fechada.
- **O suporte de verificação varia por plataforma.** Hoje o Synsema verifica documentos do Nitro contra a raiz da AWS fixada; quotes de TDX e SEV-SNP são produzidos pelo motor e verificados com o material do fabricante no lado do cliente. Diga à contraparte qual dos dois ela está recebendo.

## Quem pede isso

O padrão se repete em setores que não se parecem em nada:

- **Salas limpas de dados** — duas empresas cruzam suas listas de clientes e cada uma vê só a interseção.
- **IA confidencial** — um hospital roda o modelo de um terceiro sobre prontuários que o fornecedor não pode reter, e os pesos do fornecedor também continuam ilegíveis.
- **Custódia e assinatura** — uma chave que pode ser usada e nunca exportada, com cada uso registrado.
- **Matching privado** — ordens casadas sem que ninguém veja o livro antes do casamento.

São a mesma arquitetura: um programa pequeno, dados que ninguém de fora pode ler, e um valor que sai com um motivo anexado.

## Por onde começar

Construa primeiro a versão pequena: uma rota, uma decisão, os rótulos ligados, um documento de identidade e o verificador nas mãos de um cliente amigo. Todo o resto — o site, o cadastro, o dashboard, os jobs, a cobrança — é trabalho de produto comum que fica fora da caixa, e é implantado aqui com um comando.

A referência do lado do motor é [Atestação](https://synsema.dev/en/0.6.x/24-attestation) e [Rótulos de fluxo de informação](https://synsema.dev/en/0.6.x/23-labels).