Higiene empresarial padrão, aplicada com cuidado.

A maior parte do trabalho de segurança em uma plataforma deste tipo é padrão. Criptografia em repouso. Criptografia em trânsito. Segredos com escopo para workers individuais. Chaves isoladas por ambiente. Procedimento documentado de resposta a incidentes. Programa de divulgação responsável. Nada disso é novo. O trabalho está em fazer cada parte com cuidado, com padrões fail-closed, e sem desvios em desenvolvimento.

Esta página descreve como cada parte é implementada. A matriz de aplicação completa está no documento de engenharia de segurança; esta versão é o que você precisa ler para briefar uma equipe de segurança.

Todo o armazenamento de objetos (Cloudflare R2, AWS S3, MinIO local e Azure por meio de um endpoint compatível com S3) é criptografado em repouso usando o AES-256 padrão do provedor de plataforma. Todo o armazenamento Durable Object e de banco de dados herda o mesmo padrão. O tráfego entre workers e de worker para armazenamento usa TLS 1.2 ou superior, e as chamadas de saída para Anthropic e ElevenLabs negociam TLS 1.3.

As chaves têm escopo por ambiente e por worker. O ambiente de desenvolvimento nunca compartilha uma chave com a produção, e os workers do plano de dados nunca compartilham chaves com os workers do plano do operador. O cofre de credenciais de cada workspace é selado sob uma chave derivada exclusivamente para aquele workspace. Para implantações que requerem chaves gerenciadas pelo cliente, uma integração KMS na nuvem escolhida (AWS KMS, Azure Key Vault ou o equivalente da Cloudflare) é configurada durante o engajamento.

Cada segredo reside em exatamente um worker. Não há chaves HMAC compartilhadas, nenhum bearer token copiado, nenhuma reutilização entre ambientes. O worker de ingestão mantém o segredo de assinatura de webhooks. O worker de operações mantém o segredo bearer do administrador. O worker do motor mantém a chave API LLM. O worker de consulta mantém o segredo bearer do lado de leitura. O worker canvas mantém o segredo de mutação de matriz.

Workers que precisam se comunicar entre si usam service bindings do Cloudflare (ou o equivalente na AWS, Azure, local). Os service bindings carregam a identidade do chamador de forma nativa. Não há chave de assinatura compartilhada copiada entre workers. Comprometer o segredo de um worker não se propaga para o raio de impacto de outro worker.

Workers falham de forma segura quando um segredo necessário está ausente na inicialização. O worker inicia, recusa servir e registra o nome do segredo ausente. Não há caminho de fallback que sirva silenciosamente com uma credencial padrão.

A plataforma trava antes de vazar. A lista de verificação fail-closed é aplicada em todos os workers, sem exceções em desenvolvimento ou staging:

• Assinatura HMAC de webhook em cada webhook de entrada. Assinatura ausente ou incorreta retorna 401 sem leitura do corpo e sem gravação em armazenamento.
• Bearer token em cada chamada de API do operador. Token ausente, malformado ou revogado retorna 401 sem chamada downstream emitida.
• Verificação de papel em cada rota autenticada. Token válido com papel errado retorna 403.
• Verificação de propriedade de matriz em cada mutação canvas. O chamador deve ser o proprietário da matriz; caso contrário, 403. A mesma postura fail-closed cobre a superfície canvas tal como ela é entregue.
• Verificação de orçamento de tokens antes de cada chamada LLM. Orçamento excedido retorna uma linha de rastreabilidade de orçamento excedido sem chamada.
• Verificação de hash de prompt antes de cada chamada de enriquecimento. Uma divergência de template de prompt falha de forma segura com uma linha de rastreabilidade prompt_drift. Sem edições silenciosas nos prompts implantados.
• Validação de esquema de saída em cada resposta LLM. Saída que não valida falha de forma segura; a resposta bruta é preservada no blob de resultado para fins forenses.

Se um desenvolvedor quiser um sinalizador de 'ignorar autenticação para testes locais', esse é o momento em que entregamos uma vulnerabilidade. O ambiente de desenvolvimento usa um segredo separado com a mesma aplicação.

Cada método de consulta na API de leitura requer sua chave de escopo (identificador de matriz, identificador de organização) como argumento posicional tipado. Omiti-la é um erro de compilação TypeScript. Ela é verificada na compilação, antes que a autorização em tempo de execução tenha chance.

Cada rota HTTP inclui a chave de escopo no caminho, não em um parâmetro de consulta. A assinatura do manipulador a exige. Não há rota 'listar tudo' onde um filtro de tenant poderia ser silenciosamente descartado. Quando a plataforma adiciona um segundo escopo de organização (as implantações atuais são de organização única), o erro de compilação identifica cada lugar que precisa ser atualizado.

Cada operação que muda o estado já grava em um armazenamento somente de acréscimo. A ingestão de webhook grava no índice do data lake. As edições canvas gravam um novo blob de versão de plano com a versão anterior retida. Os envelopes do motor gravam uma linha de rastreabilidade para cada chamada LLM: identificador de modelo, contagens de tokens, duração, status e um ponteiro para o blob de resultado. Os gastos de orçamento incrementam uma linha de contador.

Não há um recurso de 'log de auditoria' separado porque todo o sistema é o log de auditoria. Um operador investigando um incidente consulta as tabelas existentes. As respostas já estão lá. Não há caminho de exclusão de linhas na plataforma. A revogação de consentimento é tratada por um tombamento que bloqueia o acesso a uma conversa em vez de apagar o histórico, de modo que o registro do que aconteceu permanece intacto e evidencia qualquer adulteração.

Os incidentes são notificados a um responsável de plantão nomeado. O procedimento tem cinco etapas: confirmar o incidente, congelar as credenciais afetadas, tirar um snapshot do estado afetado a partir dos armazenamentos somente de acréscimo, identificar o raio de impacto a partir das linhas de rastreabilidade e executar a remediação. O guia é publicado com o engajamento.

A notificação ao cliente é vinculada por contrato. Para um incidente de dados confirmado que afeta dados de respondentes, notificamos o cliente dentro de 24 horas após a confirmação. A notificação inclui os timestamps da compromissão, o raio de impacto, a remediação executada e a trilha de auditoria que usamos para estabelecer esses fatos.

Uma revisão pós-incidente é compartilhada por escrito dentro de dez dias úteis. A revisão nomeia a causa raiz, a mudança arquitetural que previne recorrência e a verificação que executamos para confirmar que a mudança é efetiva.

Pesquisadores de segurança que encontrarem uma vulnerabilidade podem reportá-la para security@nexaintel.ai. Acusamos recebimento em dois dias úteis. Comprometemo-nos a uma correção ou a um cronograma documentado de mitigação dentro de quinze dias úteis para problemas de alta severidade, trinta dias úteis para severidade média. Creditamos o pesquisador no aviso de segurança, a menos que prefira anonimato.

Não iniciamos ações legais contra pesquisa de boa-fé que siga o cronograma de divulgação. Reservamo-nos o direito de atrasar a divulgação pública até que as implantações afetadas sejam corrigidas.

A plataforma é construída de acordo com os requisitos de controle que o HIPAA, o SOC 2 Tipo II, a Loi 25 Quebec e o GDPR examinam. A arquitetura fornece o substrato para esses controles: implantação em tenant, acordos de não treinamento e não retenção com os parceiros de LLM e de voz, a trilha de auditoria somente de acréscimo, o mecanismo de tombamento para revogação de consentimento e o posicionamento de região definido por implantação.

Em uma implantação em tenant, as certificações que importam pertencem à sua infraestrutura. A plataforma é executada dentro da conta de nuvem que você já auditou, de modo que o seu SOC 2, HIPAA ou atestação regional a cobre da mesma forma que cobre tudo o mais que você executa. Para compradores que querem ajuda, há uma implantação gerenciada na qual a Nexa opera mais da pilha sob contrato.

As atestações dos subprocessadores (Cloudflare, Anthropic, ElevenLabs), o nosso DPA, a lista de subprocessadores e um questionário de segurança vigente estão disponíveis sob NDA via contato. Para uma implantação em tenant, a sua equipe avalia a plataforma em relação à sua própria estrutura.