Segurança

1. Nossa abordagem

O NeuralOS é uma plataforma operada pela Klinworks, LLC onde pessoas e equipes trabalham com agentes de IA, automações e aplicativos. Isso significa que cuidamos de informações valiosas: sua conta, o conteúdo do seu espaço de trabalho e, muitas vezes, as credenciais com que seus agentes atuam em outros serviços.

Aplicamos defesa em profundidade: várias camadas de proteção independentes, de modo que, se uma falhar, as demais continuam contendo o risco. Nesta página descrevemos apenas medidas que já aplicamos no produto. O que ainda é um objetivo é indicado expressamente como tal.

Esta página complementa a Política de Privacidade, a Política de Uso de IA e a lista de suboperadores.

2. Infraestrutura

O NeuralOS se apoia em provedores de infraestrutura reconhecidos em vez de operar data centers próprios. A lista nominal completa está em Suboperadores.

• Cabeçalhos de segurança: a API aplica cabeçalhos HTTP reforçados e uma política de CORS restrita às nossas próprias origens.
• Limites de uso: a API limita a frequência de requisições com um armazenamento compartilhado, de modo que o limite se mantém mesmo com várias réplicas em execução.
• Privilégio mínimo: as credenciais de infraestrutura ficam apenas nas variáveis de ambiente do provedor; nunca no código nem no banco de dados.

3. Criptografia

• Em trânsito: as conexões com neuralos.io e com a API usam HTTPS/TLS; requisições sem criptografia são redirecionadas para HTTPS.
• Em repouso: o banco de dados e o armazenamento de arquivos são criptografados em repouso pelo nosso provedor de dados.
• Segredos no nível da aplicação: além da criptografia do provedor, nós mesmos criptografamos os dados mais sensíveis com AES-256-GCM (criptografia autenticada) antes de armazená-los.
• Criptografia de envelope: cada segredo recebe sua própria chave de dados aleatória, que por sua vez é envolvida por uma chave mestra. Assim podemos rotacionar chaves mestras sem expor os dados, e uma chave de dados comprometida afeta um único segredo.
• Vinculado ao contexto: cada segredo criptografado fica vinculado criptograficamente ao seu espaço de trabalho ou usuário; copiado para outro contexto, ele simplesmente não é descriptografado.
• Falha fechada: se a verificação de integridade falhar, a operação é rejeitada; nunca se devolve um dado parcial.

4. Chaves próprias (BYOK) e credenciais de integrações

Você pode conectar suas próprias chaves de provedores de IA (BYOK, "traga sua própria chave") e credenciais de integrações de terceiros. Nós as tratamos como o dado mais sensível da plataforma:

• são criptografadas com uma chave específica do seu espaço de trabalho antes de serem armazenadas;
• nunca voltam a ser exibidas por completo depois de salvas (você vê apenas uma versão mascarada) e nunca são gravadas nos logs;
• só são descriptografadas no momento de uso, para a chamada que precisa delas;
• você pode revogá-las ou substituí-las a qualquer momento no seu espaço de trabalho.

As chaves mestras de criptografia nunca são armazenadas no banco de dados nem no repositório de código, e um detector automático de segredos bloqueia qualquer mudança que tente incluir uma.

5. Autenticação e controle de acesso

Sua conta

• Verificação em duas etapas (2FA): com qualquer aplicativo TOTP. O segredo é armazenado criptografado, e os códigos de backup são armazenados como hash e são de uso único.
• Sessões revogáveis: você pode ver suas sessões ativas e encerrar uma ou todas. Ao trocar a senha, as demais sessões são encerradas e avisamos você por e-mail.
• Antibots e antienumeração: o cadastro e o login são protegidos com Cloudflare Turnstile, e o cadastro não revela se um e-mail já tem conta.
• Gestão de credenciais: a autenticação é gerenciada pelo Supabase Auth; nunca armazenamos senhas em texto puro.

Seu espaço de trabalho

• Isolamento por linha: as tabelas com dados de clientes têm a segurança em nível de linha (RLS) do PostgreSQL ativada, de modo que o banco de dados só devolve linhas do espaço de trabalho ao qual você pertence.
• Funções: cada membro tem uma função (proprietário, administrador, membro ou observador), e a API verifica essa função antes de cada ação sensível.
• Acesso interno: a equipe da Klinworks, LLC acessa dados de clientes apenas quando necessário para prestar suporte, investigar um incidente ou cumprir a lei.

6. Segurança dos agentes de IA

Os agentes podem ler, escrever e agir em seu nome. Por isso, nós os limitamos desde o design:

• Permissões explícitas: um agente só usa as ferramentas, integrações e fontes de conhecimento que você concede a ele.
• O que importa espera a sua assinatura: ações com impacto (por exemplo, gastos ou envios externos) podem exigir aprovação humana, e cada aprovação ou rejeição fica registrada com quem a decidiu.
• Conteúdo não confiável: tratamos o conteúdo externo que um agente lê (sites, documentos, e-mails) como dados, não como ordens, para reduzir o risco de injeção de instruções. Nenhuma defesa é perfeita: revise o que um agente propõe antes de aprovar.
• Provedores de modelos: os prompts são enviados aos provedores indicados em Suboperadores apenas para gerar a resposta. Mais detalhes na Política de Uso de IA.

7. Desenvolvimento seguro

Cada mudança de código da API passa por um pipeline de integração contínua que precisa estar verde antes do deploy:

1. Detecção de segredos (gitleaks): nenhuma chave ou senha pode entrar no repositório.
2. Verificação de segurança do banco de dados: revisa os avisos de segurança do Supabase (por exemplo, tabelas sem RLS) e bloqueia a mudança se encontrar algum.
3. Checagem de tipos estrita, lint e formatação.
4. Testes automatizados com limites mínimos de cobertura, incluindo testes de integração contra um banco de dados real.
5. Build de produção.

A aplicação web também tem seus próprios guardiões, que verificam os contratos entre a web e a API. As mudanças no esquema de dados são feitas apenas por meio de migrações versionadas.

8. Monitoramento e registro

• Registro de auditoria somente de inclusão: as ações relevantes (mudanças de função, faturamento, agentes, automações etc.) são registradas com quem, o quê e quando. Um gatilho no próprio banco de dados impede alterar ou apagar essas entradas, mesmo com acesso direto.
• Livro de pagamentos imutável: os movimentos de saldo e pagamentos também são registrados de forma append-only.
• Vigilância da saúde: um guardião externo verifica a cada 15 minutos se o site e a API respondem e, a cada 6 horas, o fluxo completo de login, como faria um usuário real. Qualquer incidente fica registrado imediatamente para a equipe.
• Erros: usamos o Sentry para detectar e diagnosticar falhas, com dados técnicos limitados.
• Status do serviço: consulte em /status.

9. Resposta a incidentes

Se detectarmos ou recebermos o relato de um incidente de segurança, seguimos este processo:

1. Detecção e avaliação: confirmamos o alcance e a gravidade.
2. Contenção: isolamos os sistemas afetados, revogamos credenciais expostas e rotacionamos chaves quando for o caso.
3. Notificação: se um incidente afetar seus dados pessoais, avisamos você sem demora indevida e, quando aplicável, as autoridades competentes dentro dos prazos legais (por exemplo, 72 horas no GDPR).
4. Recuperação: restauramos o serviço e verificamos que a causa foi corrigida.
5. Aprendizado: analisamos a causa raiz e adicionamos controles para que não se repita.

10. Divulgação responsável

Agradecemos a quem pesquisa de boa-fé e nos ajuda a proteger nossos usuários. Se você encontrar uma vulnerabilidade em neuralos.io, seus subdomínios ou na API do NeuralOS, escreva para ceo@neuralos.io com:

• uma descrição do problema e do seu impacto potencial;
• os passos para reproduzi-lo (e, se possível, uma prova de conceito);
• sua forma de contato preferida.

Pedimos que você: não acesse, altere nem apague dados de outras pessoas; não degrade o serviço (nada de testes de negação de serviço, spam ou engenharia social contra nossa equipe ou usuários); use apenas contas próprias ou de teste; e nos dê um prazo razoável para corrigir antes de publicar qualquer coisa.

Nós nos comprometemos a: confirmar o recebimento, manter você informado do andamento, reconhecer sua contribuição se desejar e não tomar medidas judiciais contra pesquisas de boa-fé feitas conforme estas regras. No momento, não temos um programa de recompensas financeiras.

11. Conformidade e certificações

Só afirmamos certificações que efetivamente temos.

Nossos principais provedores de infraestrutura têm suas próprias certificações, que você pode consultar em seus centros de confiança. Quando passarmos por uma auditoria, isso será refletido aqui.

12. Sua parte na segurança

A segurança é compartilhada. Nós protegemos a plataforma; você controla quem entra na sua conta e o que seus agentes podem fazer. Recomendamos:

• ativar a verificação em duas etapas e guardar seus códigos de backup em local seguro;
• usar uma senha única e não compartilhar sua conta;
• conceder a cada membro e a cada agente apenas as permissões necessárias;
• revisar as ações que um agente propõe antes de aprová-las;
• rotacionar suas chaves BYOK se suspeitar que foram expostas e encerrar as sessões que não reconhecer;
• nos avisar imediatamente se notar atividade suspeita.

Se você constrói aplicativos com o NeuralOS, é responsável pela segurança da lógica deles e pelos dados dos seus próprios usuários finais.

13. Alterações nesta página

Melhoramos nossas medidas de segurança continuamente e atualizaremos esta página para refleti-las. A data da última atualização aparece no topo. Se uma alteração reduzir de forma relevante o nível de proteção descrito, avisaremos com pelo menos 30 dias de antecedência.

14. Contato

Para qualquer dúvida de segurança, ou para reportar uma vulnerabilidade ou um incidente, escreva para ceo@neuralos.io. Se for urgente, inclua URGENTE no assunto.

Klinworks, LLC · sociedade de responsabilidade limitada (LLC) constituída no Estado de Delaware, EUA · número de registro 10704723.