Segurança e governação

VAULTE · Last updated 22 July 2026

O que protege os seus dados e limita o que o sistema pode fazer em seu nome. Esta página descreve controlos que estão implementados. Onde algo ainda não existe, di-lo.

Isolamento de inquilinos

Cada registo carrega a organização a que pertence, e cada consulta é limitada a ela. A segurança ao nível da linha está ativa nas tabelas governadas e o acesso é concedido apenas ao papel de serviço — os papéis de base de dados anónimos e de utilizador final não têm caminho de leitura para os dados do cliente.

Os recursos de e-mail são além disso limitados ao proprietário: o acesso exige que o utilizador autenticado seja proprietário do recurso. Pertencer à mesma organização, um papel de administrador ou conhecer um identificador de mensagem são, cada um por si só, insuficientes. Isto é verificado por uma suíte de isolamento que executa doze tentativas de acesso hostis contra o esquema real.

Autenticação

• Início de sessão por link mágico enviado por e-mail, com tokens de sessão assinados.
• O registo e a autenticação por passkey são suportados.
• As sessões estão ligadas a um dispositivo e podem ser revogadas.
• As rotas protegidas falham de forma fechada — um pedido não autenticado é rejeitado ou redirecionado, nunca servido parcialmente.

Autorização

Os papéis determinam que superfícies e ações estão disponíveis. As funções de política e aprovação ao nível do fundador estão separadas das funções do inquilino cliente, e nenhum processo de agente detém acesso ilimitado simultâneo a e-mail, pagamentos, implementação e segredos.

Segredos

As credenciais de integração são armazenadas com cifragem de envelope (AES-256-GCM) ligada à organização proprietária, pelo que um texto cifrado movido entre inquilinos não será decifrado. Os segredos são mantidos apenas no servidor e são expurgados de qualquer conteúdo passado a um modelo de linguagem.

Pagamentos

• Os pagamentos são processados pela Stripe. Os dados do cartão nunca chegam aos nossos sistemas.
• As assinaturas dos webhooks são verificadas; um pedido não assinado ou mal assinado é rejeitado.
• Os eventos em modo de teste e em modo real estão isolados — um evento de teste não pode ativar uma conta real e vice-versa.
• Uma conta paga é aprovisionada apenas a partir de um evento de webhook verificado, nunca a partir de um navegador que regressa com um parâmetro de sucesso.
• Eventos de webhook repetidos não podem registar o mesmo pagamento duas vezes.

Limites à ação autónoma

Os limites são aplicados no código da aplicação, não por instrução a um modelo de linguagem. Cada ação pretendida é registada com a sua decisão de política antes de a chamada externa acontecer, de modo que o que foi permitido é verificável depois sem voltar a executar nada.

Algumas ações são recusadas de imediato e não podem ser autorizadas através da fila de aprovação do produto:

• contactar um destinatário depois de este se ter cancelado;
• garantir um resultado comercial;
• enviar sem uma justificação apoiada em evidências;
• iniciar o cumprimento antes de o pagamento ser verificado;
• enviar a partir de uma caixa que não passou nas verificações de configuração;
• agir sobre conteúdo identificado como uma tentativa de injeção de prompt.

Outras ações — transações acima do seu limite, descontos acima do seu teto, âmbito personalizado, alterações de contrato, questões legais ou de segurança — são colocadas em fila para a sua decisão, com a evidência anexada.

Conteúdo não fiável

As respostas, os sites, os documentos e os dados dos fornecedores são tratados como entrada adversária. O conteúdo é despojado de credenciais, analisado à procura de padrões de injeção de instruções e delimitado para que um modelo o receba como dados a analisar em vez de instruções a seguir. A injeção suspeita é colocada em quarentena e recusada.

Paragens de emergência

Uma paragem global interrompe toda a operação autónoma de imediato. As paragens delimitadas interrompem uma caixa, campanha, mercado, oferta, cliente, fluxo ou integração enquanto tudo o resto continua. As paragens são dados, não implementações — produzem efeito na ação seguinte, e o sistema também as pode acionar sobre si próprio quando sinais de entregabilidade, disputa, qualidade ou duplicação cruzam um limiar.

Histórico de auditoria

As ações governadas são registadas com ator, ação, alvo e metadados. As decisões de aprovação, as alterações de política e as paragens são atribuíveis e datadas.

Gestão de incidentes

As falhas são classificadas por gravidade. Os incidentes de segurança e sistémicos interrompem os sistemas afetados, são escalados de imediato e não são retomados com base no critério do próprio sistema. Um incidente não é encerrado por se ter implementado uma correção — o encerramento exige que o fluxo afetado tenha sucesso, que as regressões passem e que a monitorização confirme a estabilidade, com essa evidência registada.

Quando um problema o afetar, dir-lhe-emos o que está afetado e forneceremos uma solução alternativa, se existir. Não lhe diremos que está resolvido até a validação ter realmente passado.

Exportação e eliminação de dados

Pode exportar os seus dados a qualquer momento. Após a rescisão pode solicitar a eliminação; confirmaremos quando estiver concluída. Os registos que somos legalmente obrigados a manter (por exemplo, registos de transações) são conservados pelo período exigido e não mais.

O que não afirmamos

Não detemos qualquer certificação de segurança de terceiros. Não somos certificados SOC 2, ISO 27001 nem HIPAA e não afirmamos sê-lo. Não oferecemos uma garantia contratual de disponibilidade aos preços atuais. Se a sua aquisição exigir uma certificação que não temos, diga-nos antes de comprar.

Reportar uma vulnerabilidade

Envie um e-mail para hello@vaultehq.com com «Security» no assunto. Conceda-nos um prazo razoável para investigar antes de qualquer divulgação pública. Acusaremos a receção e dir-lhe-emos o que encontrarmos.