AAlphaBot
Modelo de segurança

Seus fundos. Suas keys. Nossa vantagem de execução.

AlphaBot se conecta a exchanges via API keys que você fornece e coloca ordens em seu nome. Nunca custodiamos, mantemos, reipotecamos ou transferimos ativos de usuários. Abaixo está exatamente o que fazemos — e não fazemos — com as credenciais que você confia em nós.

Segredos criptografados com KMSPermissão de withdraw rejeitada firmementeCancele a qualquer momento

1. Nunca custodiamos seus fundos

  • API keys que você conecta concedem read e trade permissão apenas — nunca withdraw.
  • A permissão de saque é rejeitada imediatamente no onboarding. Detectamos na primeira chamada autenticada e nos recusamos a aceitar a chave. A chave não é armazenada, não é registrada em log, não é retentada.
  • Se seu exchange suporta IP allow-lists em API keys, você pode restringir sua key aos endereços outbound de AlphaBot (listados no dashboard).

2. Criptografia: AWS KMS, envelope, por-usuário

  • Segredos de API são criptografados em repouso usando AWS KMS com criptografia envelope: uma unique data key por usuário, envolvida em uma KMS customer master key.
  • A política de KMS vincula operações de decrypt à sua JWT de sessão ativa. Operadores (nós) não conseguimos descriptografar seus segredos out-of-band.
  • Segredos descriptografados vivem apenas em memory de processo, apenas pela duração de uma chamada de API, e nunca são escritos para disco ou logs.

3. Isolamento de dados por-usuário

Cada record em nosso datastore é keyed e particionado por usuário. Caminhos de acesso requerem a identidade autenticada do chamador combinar com o dono da linha; acesso cross-user é impossível por construção, não por convenção.

Rodamos um fixture de CI que afirma "usuário A não consegue read, modificar ou disparar qualquer side-effect em dados do usuário B" contra cada handler protegido. O teste falha o build em qualquer regressão.

4. Append-only audit log

Cada ação que AlphaBot toma contra sua conta — ordem colocada, ordem cancelada, key rotacionada, kill switch disparado, parâmetro mudado — é registrada em um log append-only hash-chained.

  • Você consegue exportar o log completo como CSV ou JSON do dashboard a qualquer tempo.
  • Cada entrada referencia o hash da entrada anterior, então qualquer tampering é detectável.
  • A chain head é publicada, então você consegue verificar localmente que nenhuma entrada foi alterada ou removida.
  • Ações do operador (funcionário) em infraestrutura são logadas separadamente e disponibilizadas em request ao tier Enterprise.

5. Infraestrutura

AlphaBot roda em AWS em múltiplas regiões (us-east-1, us-west-2, ap-southeast-1) escolhidas por proximidade a match engines de exchange. Não compartilhamos databases com qualquer terceiro. Deployments de produção requerem multi-factor authentication, são short-lived-credential only e são registrados no operator audit log.

6. Divulgação de vulnerabilidade

Se você acredita ter encontrado um problema de segurança, por favor email security@alphabot.deeplogic.software. Buscamos reconhecer em até um dia útil e fornecer um plano de remediação em até cinco.

Estamos preparando um programa formal de bug-bounty com payouts escalados por severidade (baixa / média / alta / crítica). Até estar ao vivo, reconheceremos divulgação responsável publicamente (com consentimento do reporter) e pagaremos bounties discricionários para reports válidos e in-scope. Out-of-scope: qualquer coisa requerendo compromisso de credenciais de exchange de end user, findings não-impactando-produto, denial-of-service contra infraestrutura compartilhada, social engineering de staff.

O que nós (ainda) não alegamos

Não alegamos certificação SOC 2 ou ISO 27001. Ambas estão em nosso roadmap e publicaremos o auditor e report quando cada uma estiver completa. Até então, os controls descritos acima são o que conseguimos apoiar hoje.