Seus dados são seus.
E permanecem assim.
Isolamento por conta imposto pelo banco de dados. Documentos e vetores em hardware nosso, no Brasil. A única etapa que sai do país é a geração da resposta, e ela está declarada — com nome, no DPA.
Postgres RLS
Row-Level Security ativo. Engine roda como role valorbrain_app com policies tenant-scoped enforced pelo banco. BYPASSRLS isolation pra migrations admin.
Token hashing
MCP tokens armazenados como SHA-256 hash. Raw token mostrado uma única vez no momento da criação. Per-token scopes granulares.
Backup diário
Dump do Postgres todos os dias, retido 14 dias, no mesmo perímetro físico do banco. Restauração já exercitada em incidente real. TLS 1.3 obrigatório em todo trânsito.
On-premise
Opcional no plano Empresa, incluído no Enterprise: o ValorBrain inteiro na sua infra, inclusive o modelo que gera a resposta. Nenhuma etapa sai do seu perímetro.
LGPD
Somos operadores; você é o controlador. DPO designado, DPA público, lista de subprocessadores aberta. Direitos de acesso, correção, exclusão e portabilidade pelo produto.
Registro de acesso
Quem pesquisou, quem abriu qual documento e quando, com user_id e timestamp. Fica disponível enquanto a conta existir e é exportável a qualquer momento.
Exclusão
Pedido de exclusão apaga conteúdo e vetores em até 30 dias. Backup segue rotação de 14 dias, então nenhuma cópia sobrevive além disso.
Onde os dados ficam
Documentos, vetores e banco em hardware nosso em Santa Catarina. Embedding, rerank e NER na GPU da mesma máquina. A exceção é a geração da resposta, que usa LLM em nuvem fora do país — declarada no DPA.
Incident transparency
3 incidents (TRUNCATE-prod) tratados em 24h em maio/2026. 4-layer defense ativa desde então. Postmortem público disponível mediante NDA.
Compliance status
Honestidade sobre onde estamos. Nada de claims sem proof.
Se a sua diligência exige certificação hoje, a resposta honesta é que não temos. O que temos é o DPA, a lista de subprocessadores e disposição para responder questionário de segurança linha por linha.
Como o multi-tenant funciona
1.Tenant ID em todo request
Toda chamada à engine carrega X-Tenant-ID derivado do JWT do usuário. Engine valida ownership antes de qualquer query.
2.Postgres RLS policies
Cada tabela com tenant_id tem RLS policy: USING (tenant_id = current_setting('app.tenant_id')). Engine roda como role valorbrain_app que respeita RLS.
3.Connection-level isolation
Cada connection seta SET LOCAL app.tenant_id = '...' no início da transaction. Connection pool não compartilha state cross-tenant.
4.Defense in depth
4 camadas: app-level filter → engine validation → Postgres RLS → BYPASSRLS guard em ops admin. Documentado em SAFETY.md do repo.
Tem dúvidas de security?
Falamos a sua linguagem. Questionário de segurança, detalhe de arquitetura, NDA — tudo disponível.