Pular para o conteúdo
Novo

DeepSeek V4.1 Flash grátis por 7 dias: 10M tokens por dia após qualquer recarga. Até 30/11.

Como funciona

Os controles que rodam, e os que ainda não construímos.

Por onde passa uma requisição, como as organizações ficam separadas, qual chave protege o quê e o que ainda não certificamos. Esta página descreve o que roda em produção hoje.

/.well-known/security.txt
Contact
mailto:[email protected]
Expires
2027-11-01T00:00:00.000Z
Preferred-Languages
en, pt, es
Canonical
https://notholy.com/.well-known/security.txt
Policy
https://notholy.com/en/security

Uma requisição de API, salto a salto

Cada parte que trata a requisição e o que ela consegue ler. A parte contornada é a que operamos.

  1. Seu cliente

    Consegue ler

    Seu prompt e sua chave de API, enviados por TLS.

    Guarda

    O que suas próprias ferramentas salvarem.

  2. Borda da Cloudflare

    Consegue ler

    A requisição inteira, decifrada em trânsito, e seu endereço IP. O TLS termina aqui em todos os hostnames, inclusive api.notholy.com, e uma nova conexão TLS leva a requisição até nossa origem.

    Guarda

    Definido pelos termos da própria Cloudflare.

  3. Gateway NotHoly

    Consegue ler

    A requisição, em memória. Ele confere o HMAC da chave, o orçamento e as listas de permissão, depois roteia a chamada.

    Guarda

    Metadados de uso: ID da requisição, organização, chave, modelo, tokens, custo, status e tempos. Esse registro não tem prompt, resposta nem endereço IP. A resposta de uma chamada sem streaming com Idempotency-Key fica na memória por 24 horas.

  4. Parceiro de data center de IA

    Consegue ler

    Mensagens, ferramentas e parâmetros do modelo, por HTTPS e com a nossa chave. Sua organização, seu ID de usuário e seu IP não são repassados. O parceiro fica nos Estados Unidos ou na China e pode usar subcontratados próprios.

    Guarda

    Nada. O parceiro confirmou à NotHoly que não retém, não armazena nem usa o conteúdo da inferência, e a NotHoly o checa periodicamente.

Isolamento entre organizações

As organizações são separadas na aplicação: todo caminho de consulta filtra por org_id.

Chaves
Cada organização tem a própria chave de criptografia, então a chave de uma não abre os dados selados de outra.
Ledger
Alterações de saldo são só de inserção, garantidas por um gatilho no banco. Webhooks de pagamento precisam de assinatura válida.

Identidade e acesso

Login de clientes, chaves de API e acesso da equipe têm controles próprios.

Senhas
De 12 a 256 caracteres, com e-mail verificado obrigatório.
Segundo fator
TOTP com códigos de backup, e passkeys.
Novos dispositivos
Entrar com senha em um dispositivo não confiável exige um código único por e-mail. O código fica guardado como hash com chave, vale 10 minutos, funciona uma vez e permite 5 tentativas.
Dispositivos confiáveis
Lembrados por 30 dias, guardados com hash e revogáveis.
Sessões
14 dias em cookie HttpOnly, Secure e SameSite=Lax. Você pode listar suas sessões e revogá-las.
Checagem contra bots
Cloudflare Turnstile em login, cadastro e redefinição de senha, verificado no servidor. Em produção, se falhar, bloqueia.
Chaves de API
Guardadas como HMAC-SHA-256 com pepper no servidor e mostradas uma vez. A chave pode ter listas de IPs e modelos permitidos, orçamento e validade. A revogação é imediata.

Acesso da equipe

Login no admin
Só com passkey. A sessão dura 8 horas e termina após 30 minutos ociosa, e há lista de IPs opcional.
Alterações no admin
Registradas com o autor, a ação, o alvo e os valores antes e depois.
Ajustes no ledger
Qualquer valor acima de US$ 100 precisa de uma segunda aprovação.
Personificação
A equipe não tem recurso para agir como cliente.

Criptografia

Chats, projetos e arquivos são cifrados no servidor, com chaves que nós guardamos. Deciframos para rodar seu chat, portanto a criptografia é do lado do servidor e não é de ponta a ponta.

Hierarquia de chaves de chats e arquivos
  1. Chave mestra

    Fica no ambiente do servidor. Envolve todas as chaves de organização.

  2. Chave da organização

    Uma por organização. Envolve as chaves de dados daquela organização.

  3. Chave de dados

    Uma por conversa e uma por arquivo.

  4. Conteúdo selado

    AES-256-GCM com nonce de 12 bytes. Cobre títulos de chat, mensagens, raciocínio, projetos, nomes de arquivo, bytes do arquivo e texto extraído.

Em trânsito
TLS do navegador até a Cloudflare, com HSTS de 2 anos e preload, depois TLS da Cloudflare até nossa origem. O gateway fala por HTTPS com parceiros de data center de IA nos Estados Unidos e na China. Os serviços dentro da nossa rede privada conversam em texto claro.
Senhas
Senhas de conta, de bloqueio de chat e de compartilhamento usam scrypt. Tokens de compartilhamento ficam como SHA-256.
Chats efêmeros
Os eventos de execução usam uma chave aleatória de 32 bytes por execução, só na memória do processo.
Sem criptografia por coluna
Nome, e-mail, telefone, endereço de cobrança, CPF ou CNPJ, endereço IP e metadados de uso são colunas comuns do banco.

O que acontece com seu conteúdo

O conteúdo de inferência da API não é gravado em banco, fila, log ou trace. Chats salvos ficam guardados e cifrados até você apagar.

Inferência da API

Conteúdo que guardamos
Nenhum. Prompts e respostas existem na memória do gateway enquanto a requisição roda.
Proteção
TLS em trânsito.
Remoção
Ao fim da requisição, exceto o cache de idempotência descrito abaixo.
O que fica
Metadados de uso.

Chat salvo

Conteúdo que guardamos
Títulos, mensagens, raciocínio, citações e arquivos anexados.
Proteção
AES-256-GCM, com uma chave por conversa e uma por arquivo.
Remoção
Quando você apaga a conversa. Os arquivos anexados não saem junto.
O que fica
Um registro de exclusão da conversa, registros de execução, rótulos das etapas de ferramenta, arquivos anexados e metadados de uso.

Chat efêmero

Conteúdo que guardamos
Nenhuma conversa e nenhuma mensagem. Eventos de execução cifrados, além de qualquer arquivo enviado.
Proteção
Os eventos de execução usam uma chave aleatória por execução, só na memória do processo. Arquivos enviados usam uma chave por arquivo, envolvida pela chave da organização.
Remoção
Os eventos de execução são apagados 1 hora depois do fim da execução.
O que fica
Um registro de execução, rótulos das etapas de ferramenta, arquivos enviados e metadados de uso.
Cache de idempotência
Se você envia um Idempotency-Key em uma chamada sem streaming, a resposta completa fica na memória do processo do gateway por 24 horas, para que uma nova tentativa receba a mesma resposta. Ela nunca vai para o disco, só sua organização consegue reaproveitá-la e um reinício apaga tudo.
Rótulos das etapas de ferramenta
As execuções de chat registram em texto claro o alvo de cada chamada de ferramenta, sem expiração automática: a consulta de busca na web, a consulta de busca em arquivos, a consulta de CVE, o nome do arquivo ou o hostname do read_url. As URLs de citação também ficam em texto claro.
Treinamento de modelos
Não usamos conteúdo de clientes para treinar modelos de IA nem para análise de modelos. Metadados são analisados para cobrança, monitoramento de abuso e operação.
Parceiros de data center de IA
Todos os parceiros ficam nos Estados Unidos ou na China e confirmaram à NotHoly que não retêm, não armazenam nem usam o conteúdo da inferência. A NotHoly os verifica e checa periodicamente.

Tratamento de arquivos

Sandbox inativo em produção

Todo envio é tratado como hostil e nenhum arquivo de usuário é executado. A análise foi feita para um sandbox descartável que a produção ainda não roda. Isso vale para envios no chat, /v1/files e a ferramenta MCP analyze_file.

Em repouso
Nome, bytes e texto extraído são selados com uma chave por arquivo antes de serem guardados. A análise grava o arquivo decifrado em um diretório temporário e o remove ao terminar. O registro do arquivo mantém só o hash, o tamanho e o tipo MIME em texto claro, e o nome do arquivo pode aparecer em um rótulo de etapa de ferramenta.
Desenho do sandbox
Cada análise ganha um contêiner novo sem rede, com raiz somente leitura, limites de memória, CPU e processos, todas as capabilities removidas, usuário sem privilégio e nenhum segredo.
Em produção hoje
O harness de produção não tem o executor do sandbox, e nada mais analisa os envios. O arquivo fica selado no armazenamento, marcado como rejeitado, e não é analisado até o sandbox ser ligado.

Rede e SSRF

A origem só aceita a Cloudflare nas portas públicas. O único recurso do servidor que busca URLs roda atrás de uma proteção contra SSRF.

Origem
As portas 80 e 443 só aceitam conexões das faixas de endereços da Cloudflare. Os serviços internos escutam em loopback.
Acesso ao servidor
SSH somente por chave, com fail2ban.
read_url
Só http e https públicos, nas portas 80 e 443. Cada endereço resolvido é conferido, a conexão fica presa ao IP conferido e cada redirect é conferido de novo. Nenhum cookie é enviado, tamanho e tempo têm limite e o robots.txt é respeitado.
Tráfego para terceiros
Nossos servidores não fazem scan, exploração nem tráfego ativo contra sistemas de terceiros. O read_url só lê páginas públicas. Os comandos do CLI rodam na sua máquina, depois que você aprova.

Endurecimento da aplicação

Estes são os cabeçalhos de resposta que notholy.com envia hoje. Os source maps do navegador não são servidos publicamente.

curl -sI https://notholy.com/en
Strict-Transport-Security
max-age=63072000includeSubDomainspreload
Content-Security-Policy
default-src 'self'script-src 'self' 'unsafe-inline' https://static.cloudflareinsights.com https://challenges.cloudflare.comstyle-src 'self' 'unsafe-inline'img-src 'self' data: blob: https:font-src 'self' data:connect-src 'self' https://api.notholy.com https://cloudflareinsights.commedia-src 'self' blob:worker-src 'self' blob:manifest-src 'self'frame-src https://challenges.cloudflare.comframe-ancestors 'none'object-src 'none'base-uri 'self'form-action 'self'upgrade-insecure-requests
X-Frame-Options
DENY
X-Content-Type-Options
nosniff
Referrer-Policy
strict-origin-when-cross-origin
Permissions-Policy
camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()
Cross-Origin-Opener-Policy
same-origin

A diretiva destacada é o ponto fraco: nosso CSP não usa nonce, e o script-src ainda permite 'unsafe-inline'.

Monitoramento e trilha de auditoria

Métricas e painéis ficam no nosso próprio host, e nenhum rastreador de erros de terceiros está ativo.

Métricas
Prometheus e Grafana no nosso próprio host, presos ao loopback. As métricas têm só rótulos e contagens, e ficam 30 dias.
Logs da aplicação
IDs de requisição, status e erros, nunca o corpo da requisição. Rotacionados por tamanho, em 3 arquivos de 10 MB por contêiner.
Auditoria da equipe
Autor, ação, alvo, valores antes e depois, endereço IP e user agent.
Auditoria da organização
Organizações do tipo empresa podem ver os últimos 100 registros em Configurações, se o papel permitir.

Backups e recuperação

O banco tem backup uma vez por dia, cifrado e guardado fora do servidor.

Criptografia
AES-256, com chave derivada por PBKDF2 em 200.000 iterações.
Retenção
14 cópias diárias, 8 semanais e 12 mensais. Dados que você apaga podem continuar em um backup por cerca de 12 meses.
Teste de restauração
Um teste por script restaura o backup mais recente em um banco descartável, confere o checksum e verifica se cada tabela existe e não tem mais linhas que a do banco em uso. Ele ainda não roda em horário agendado.
Janela de perda
Uma falha entre backups pode perder até um dia de gravações.

Reporte uma vulnerabilidade

Esperamos que pesquisadores testem a gente. Veja como reportar o que encontrar.

Onde
[email protected]. Nosso security.txt fica em /.well-known/security.txt.
O que mandar
A URL ou o componente afetado, os passos para reproduzir e o impacto que você observou.
Escopo
notholy.com, api.notholy.com e docs.notholy.com. Não teste dados de outros clientes, não faça teste de negação de serviço e pare quando tiver mostrado o impacto.
Do nosso lado
Confirmamos o recebimento, mantemos você informado enquanto corrigimos e não vamos processar pesquisa de boa-fé que siga estas regras.
Recompensas
Não temos programa de bug bounty pago.

O que ainda não fizemos

Se a sua avaliação depende de algum destes itens, fale com a gente antes de confiar na NotHoly.

  • Certificações

    A NotHoly não tem SOC 2, ISO 27001 nem outra certificação ou atestado de segurança.

  • Pentest independente

    Não temos relatório de pentest de terceiros para compartilhar.

  • Criptografia de ponta a ponta

    O servidor guarda as chaves e decifra chats e arquivos para processá-los.

  • Isolamento garantido pelo banco

    O isolamento entre organizações está nas consultas da aplicação. O banco não acrescenta uma segunda camada hoje.

  • Sandbox de arquivos em produção

    O sandbox está pronto e não roda em produção, então os envios ficam guardados e não são analisados.

  • Exclusão automática

    Envios têm data de expiração e organizações do tipo empresa podem escolher um prazo de retenção de chats, mas nenhuma tarefa aplica isso hoje. Metadados de uso e registros de auditoria não têm tarefa de exclusão, então ficam guardados sem data final. Registros de sessão expirados, que têm endereço IP e user agent, não são apagados por nenhuma rotina.

  • 2FA para toda a organização

    O dono ainda não consegue exigir segundo fator de todos os membros.

  • Exportação e imutabilidade de logs

    A auditoria da organização não pode ser exportada, e nossos logs não são de gravação única.

  • Recuperação a um ponto no tempo

    Os backups são dumps diários sem arquivamento contínuo, e não incluem os objetos de arquivos enviados.

Pergunte tudo o que o seu escopo permite.

Crie a conta, adicione créditos a partir de US$ 10 e faça a primeira pergunta no chat ou no terminal.

  1. 1/3

    Crie a conta

    Individual ou empresa. Dá para virar empresa depois sem perder saldo nem chaves.

    Pessoa físicaEmpresa
  2. 2/3

    Adicione créditos

    No cartão, a partir de US$ 10. Você paga por token, sem assinatura.

    $10.00recarga mínima
  3. 3/3

    Pergunte

    No chat, ou instale o CLI e rode notholy login no terminal.

    $ notholy login