Política de segurança
Nosso compromisso com a transparência, a coordenação de vulnerabilidades, o reconhecimento de pesquisadores e uma postura de conformidade honesta.
security.txt conforme a RFC 9116: /.well-known/security.txt
Hall da Fama de Segurança
Reconhecimento a pesquisadoresSomos sinceramente gratos aos pesquisadores independentes de segurança que divulgaram vulnerabilidades de forma responsável para ajudar a manter a zn e o ecossistema de IA seguros.
Falha de autorização no plano de controle dos handlers de políticas e consenso
Constatou-se que os endpoints do plano de controle (/api/v1/policies* e /api/v1/consensus*) validavam a autenticação da API do tenant, mas não faziam verificações de autorização em nível de função, o que permitia que chaves de tenant sem perfil de administrador alterassem políticas ou o estado do consenso. A correção aplicou verificações rígidas do perfil SuperAdmin e a verificação das testemunhas do consenso.
Revogação insuficiente de sessões e tokens na redefinição de senha (CWE-613)
Constatou-se que alterar ou redefinir a senha de uma conta não invalidava as autorizações ativas, os refresh tokens nem as sessões simultâneas no navegador. A correção implementou a revogação imediata, no servidor, das autorizações e dos refresh tokens do Auth0 nos eventos de redefinição de senha, o encerramento das sessões em todos os dispositivos existentes e a redução da validade dos access tokens.
Revogação de sessão incompleta na troca de senha (continuação de CWE-613)
Identificou-se de forma independente que a troca da senha da conta não invalidava imediatamente as outras sessões ativas no navegador: os access tokens já emitidos continuavam válidos até expirar, mesmo com as concessões de refresh token revogadas. A correção acrescentou uma época de revogação por usuário, verificada pela API em cada requisição, de modo que os tokens emitidos antes de uma troca de credenciais são rejeitados na hora; reduziu a validade do access token de 24 horas para 15 minutos; estendeu a mesma revogação ao fluxo de redefinição de senha; e adicionou o controle “Sair de todos os dispositivos” e o encerramento automático da sessão quando ela é rejeitada.
Reforço do fluxo de encerramento de sessão (redirecionamentos de logout e tratamento de erros)
Constatou-se que o fluxo global de logout dependia de um destino pós-logout que não estava registrado nas URLs de logout permitidas do provedor de identidade, o que exibia uma página de erro sem a marca e expunha a configuração interna. A correção substituiu os erros brutos do provedor de identidade por uma página de erro com a marca, acrescentou um aviso amigável de “sessão expirada” para logouts entre dispositivos, registrou os destinos de logout legítimos como defesa em profundidade e concluiu a migração para um domínio de autenticação próprio.
As entradas usam o formato SEC-YYYY-NN e são permanentes: nunca removemos um pesquisador creditado. Se você preferir permanecer anônimo, podemos listar o relatório sem o seu identificador.
Avisos de segurança
Descobertas própriasProblemas em software que distribuímos, publicados com o mesmo nível de detalhe que pedimos aos pesquisadores: o que aconteceu, quem é afetado e o que fazer.
zn-gate para Node.js anterior à 1.6.0: um agente podia executar comandos de administração da zn por meio de uma chamada de pacote versionada, contornando o hook que os bloqueia
Os hooks dos agentes negam aos agentes de IA os comandos que gerenciam seus segredos e sua proteção, como zn unlock, zn lock, zn secret set, zn env shadow e zn hooks uninstall. Da 1.5.0-beta.1 até a 1.6.0-beta.1, o hook não reconhecia esses comandos quando eram escritos como chamada de pacote versionada, por exemplo npx -y zn-gate@1.5.1 hooks uninstall, e por isso os deixava passar. A maioria desses comandos também se recusa a rodar quando o ambiente indica um agente de programação ou quando não há um terminal interativo; zn lock não tem essa verificação, então qualquer agente podia bloquear o cofre (isso não revela segredos). Não são afetados: o pacote Python, a remoção de segredos na entrada e na saída das ferramentas e a leitura de valores secretos. Corrigido no zn-gate 1.6.0, que nega as formas versionadas com npx, pnpm dlx e bunx da mesma forma que o comando simples. Atualize com npm install -g zn-gate@1.6.0 (ou atualize o plugin do agente); enquanto não puder atualizar, mantenha os comandos do seu agente fora de um terminal interativo, revise qualquer prompt da zn que você não esperava e, se os hooks do agente foram removidos, instale-os novamente com zn hooks install a partir do seu próprio terminal.
zn-gate 1.5.0 e anteriores para Node.js no Windows: zn run podia entregar segredos a um programa escolhido pelo ambiente
No Windows, quando zn run passava segredos armazenados para um arquivo em lote aprovado (.cmd ou .bat, como uma CLI instalada com npm), ele iniciava o arquivo pelo interpretador de comandos indicado na variável de ambiente ComSpec. Um processo capaz de alterar essa variável, como um agente de IA em uma sessão na qual você havia aprovado o arquivo em lote, podia apontá-la para outro programa, que então recebia os valores secretos. Não são afetados: macOS e Linux, programas do Windows que são arquivos .exe, o pacote Python e a remoção de segredos na entrada e na saída das ferramentas feita pelos hooks. Corrigido no zn-gate 1.5.1, que sempre inicia os arquivos em lote pelo cmd.exe do sistema; em todas as plataformas, também deixa de passar a um programa que recebe segredos as configurações de inicialização do interpretador, como NODE_OPTIONS, herdadas do ambiente de quem chama. Atualize com npm install -g zn-gate@1.5.1 (ou a versão que o plugin do seu agente fixa); enquanto não puder atualizar, não aprove programas .cmd ou .bat para segredos em zn run, e para APIs HTTP use a ferramenta MCP secrets_http_request.
zn-gate 1.4.0 e anteriores enviavam a saída das ferramentas e os argumentos das chamadas para api.usezn.com sem remoção de dados sensíveis quando ZN_API_KEY estava definida
Encontrado durante uma revisão interna do pacote publicado. Sem ZN_API_KEY, nada saía da máquina. Corrigido no zn-gate 1.4.1: a saída das ferramentas e os argumentos das chamadas são avaliados somente localmente, a análise na nuvem é opcional (ZN_CLOUD=1), somente o prompt é enviado, com os dados sensíveis removidos antes do envio. A API não armazena mais o texto de entrada, e o texto que tinha sido armazenado foi excluído do serviço. Se você executou a 1.4.0 ou uma versão anterior com uma chave de API definida, atualize e rotacione qualquer credencial que possa ter aparecido na saída das ferramentas.
Registro de alterações de segurança
Cada melhoria de segurança que lançamos, registrada publicamente. Correções, não exploits.
Política de divulgação responsável
Se você acredita ter descoberto uma vulnerabilidade de segurança no zn-gate, na API em nuvem da zn ou em qualquer infraestrutura da usezn.com, reporte-a diretamente à nossa equipe de segurança. Levamos a sério todas as divulgações responsáveis e as investigamos prontamente. Esta política segue a RFC 9116 e coordena a divulgação com quem a reporta.
Inclua passos detalhados para reproduzir o problema, scripts ou requisições de prova de conceito e os detalhes relevantes do ambiente. Recomendamos fortemente testar em contêineres Docker locais ou em contas de teste isoladas.
Processo de divulgação
- Reportar — envie um e-mail para security@usezn.com com os passos para reproduzir, o impacto e uma prova de conceito. Nunca acesse dados que não sejam seus nem interrompa sistemas de produção.
- Confirmar recebimento — nosso objetivo é uma primeira resposta humana em até 24 horas.
- Triagem — nosso objetivo é concluir a avaliação de validade e gravidade em até 48 horas, e informaremos se o reporte é válido, duplicado ou está fora do escopo.
- Corrigir — corrigimos por prioridade, de acordo com a gravidade, e mantemos você informado sobre o andamento.
- Coordenar a divulgação — o embargo padrão é de 90 dias a partir do reporte, ou o cronograma que combinarmos com você. Apoiamos rascunhos de avisos e a atribuição de CVE, e creditamos você publicamente conforme a sua preferência.
Esses prazos são metas indicativas de uma equipe pequena, não um SLA contratual. Se ficarmos em silêncio, ainda estamos trabalhando nisso, e você é sempre bem-vindo para nos cobrar.
Compromisso de safe harbor
Consideramos autorizada a pesquisa de segurança conduzida de acordo com esta política. Se você fizer um esforço de boa-fé para cumprir a divulgação responsável (evitando acesso a dados de usuários, interrupções de serviço e violações de privacidade), nós vamos:
- Não iniciar nem prosseguir com ações judiciais contra você
- Trabalhar com você de forma transparente para validar e corrigir o problema
- Coordenar o aviso público e a atribuição de acordo com as suas preferências
- Não tratar a sua pesquisa como violação dos nossos Termos de Serviço ou da política de Uso Aceitável
Escopo
Dentro do escopo
- zn-gate (código aberto): servidor MCP, CLI, remoção de segredos e registro de auditoria local
- Endpoints da API em nuvem (
api.usezn.com) - SDKs cliente (
zn-gateNPM/PyPI) - Mecanismos de autenticação e controle de acesso
- Contornos de jailbreak do modelo contra
/v30/analyze - A aplicação web da usezn.com e o painel do cliente
- Integridade, exportação e controles de retenção do cofre de evidências
- Fluxos de integração de cobrança com Auth0 e Polar
Fora do escopo
- Ataques de negação de serviço (DoS/DDoS)
- Engenharia social ou phishing direcionado à equipe da zn
- Serviços de terceiros que hospedam nossos ativos (p. ex., AWS, Cloudflare)
- Spam de scanners automatizados sem prova de conceito acionável
- Cabeçalhos de endurecimento ausentes ou boas práticas sem impacto de segurança demonstrável
- Achados que exigem acesso físico ou um dispositivo do usuário final comprometido
Reconhecimento e recompensas
Valorizamos o esforço necessário para identificar falhas de segurança. Para vulnerabilidades que se qualifiquem, oferecemos:
- Atribuição pública: inclusão permanente no nosso Hall da Fama de Segurança e nas notas de versão.
- Assinaturas da plataforma: pesquisadores qualificados podem receber 6 meses do plano Scale sem custo (2.000.000 de chamadas por mês) para uso pessoal ou de pesquisa.
- Colaboração direta em avisos: coordenação completa sobre o momento da divulgação, rascunhos de avisos e atribuição de CVE.
Atualmente não mantemos um programa pago de bug bounty. Não prometemos dinheiro que não possamos pagar: somos uma equipe pequena, e as recompensas são discricionárias e focadas em atribuição, acesso à plataforma e colaboração. Se uma recompensa monetária passar a existir, ela será publicada aqui primeiro.
Tratamento e retenção de dados
Zero retenção de dados: todos os planos (Free, Pro, Scale e Team) avaliam a entrada fora do Modo Colaborador em memória volátil e a descartam após o veredito; somente os metadados da decisão abaixo são mantidos. Planos pagos nunca treinam modelos com dados de clientes.
Modo Colaborador (opcional): o Modo Colaborador, oferecido com alguns programas de startups e bolsas de pesquisa, é a única opção que compartilha dados para pesquisa, e a escolha é sua. Nesse modo, um trecho higienizado de cada entrada analisada (os primeiros 1.000 caracteres, com e-mails, tokens de portador, chaves de API e longas cadeias hexadecimais removidos automaticamente) é armazenado com o seu registro de evidência por até 90 dias e usado para melhorar os modelos de detecção da zn. A remoção automática não detecta todos os dados pessoais em texto livre.
Registros de evidência: cada decisão gera um registro de evidência com um ID aleatório e metadados (veredito, confiança, regra, latência, data e hora e, a partir de 12 de outubro de 2026, às 12:24 UTC, um hash SHA-256 e o tamanho da entrada, o prefixo da chave de API e a família do cliente). Fora do Modo Colaborador, nunca contém a própria entrada. As evidências expiram automaticamente após 90 dias, são criptografadas em repouso (AES-256, criptografia gerenciada pela AWS) e podem ser exportadas em CSV ou JSON pelo painel. As chaves de API são armazenadas com hash e criptografadas com o AWS KMS.
Leia todos os detalhes na nossa Política de Privacidade.
Certificações e conformidade
Preferimos ser precisos a impressionar. Esta é a nossa situação real hoje:
- SOC 2 / ISO: a zn não possui hoje certificações SOC 2 nem ISO 27001/42001.
- Infraestrutura: operamos na AWS, cujos data centers possuem certificações SOC 2 Type II e ISO 27001.
- Roteiro: uma auditoria SOC 2 Type II começará com o nosso primeiro contrato empresarial; o trabalho de preparação para ISO 27001 e ISO 42001 está no roteiro.
- Exportações para auditoria: os registros de evidência por decisão podem ser exportados (CSV ou JSON) para apoiar a manutenção de registros dos clientes. O pacote local zn-gate também mantém, na sua própria máquina, um registro encadeado por hash.
- Sem SLA de disponibilidade: monitoramos internamente com alarmes do AWS CloudWatch, mas não publicamos um monitor de disponibilidade em tempo real nem prometemos um SLA público de disponibilidade. Veja a página de status.
Procedência dos modelos
- Galvanize 2 é o modelo por trás da verificação opcional na nuvem. Ele é ajustado a partir de Horizon-Labs/prompt-injection-guard-small (Apache-2.0) e publicado sob Apache-2.0. Visão geral: Galvanize 2; cartão do modelo e pesos: usezn/Galvanize-2. Scripts e resultados do benchmark: usezn/Galvanize-2/benchmark.
- Galvanize-60M, o modelo anterior, é o fallback automático quando o Galvanize 2 não está disponível. Cartão do modelo e pesos: usezn/Galvanize-60M (Apache-2.0).
Suboperadores e DPA
Contamos com um conjunto pequeno de suboperadores avaliados: AWS (hospedagem e armazenamento), Auth0 (autenticação), Polar (pagamentos e Merchant of Record), e Amazon SES (e-mails transacionais).
A lista completa, as finalidades e as salvaguardas de transferência estão na nossa página DPA e suboperadores. Os clientes podem firmar um Acordo de Processamento de Dados (DPA) sob solicitação: fale conosco em hello@usezn.com.