Segurança no Blockchain0x.
Os pagamentos do agente movimentam dinheiro real. As escolhas arquitetônicas que protegem os fundos dos clientes, a postura de auditoria como está hoje e como nos contatar se você encontrar algo errado.
O que você pode esperar desta página.
Somos uma empresa em estágio inicial lançando infraestrutura na qual os clientes confiarão autoridade de pagamento. Confiança se baseia no que você pode verificar, não no que lhe dizem. Esta página documenta quatro coisas que clientes e pesquisadores de segurança podem verificar ou cobrar de nós: as garantias arquiteturais que se mantêm mesmo se estivermos errados sobre todo o resto, o estado atual da nossa postura de auditoria (incluindo o que ainda não fizemos), o escopo da nossa política de divulgação de vulnerabilidades e exatamente o que um relator recebe (reconhecimento, não dinheiro), e o canal de contato para divulgação responsável.
What this page is not: a marketing surface designed to look maximally serious about security. We did not invent security certifications we do not hold, did not list "compliance" with frameworks we have not audited against, and did not put trust badges on the page that we did not earn. When we have a SOC 2 attestation or a third-party penetration test report, those will be referenced here with the auditing firm, the date, and the scope. Until then, this page says so plainly.
Quatro propriedades que se mantêm por construção.
As garantias abaixo são arquitetônicas - são propriedades de como o sistema é construído, não de como é operado. A segurança operacional pode falhar (uma chave vazada, um deploy mal configurado); garantias arquitetônicas não dependem de operações diárias serem perfeitas. Estas são as partes da história de segurança nas quais você pode confiar mesmo na pior semana de operações.
Não-custodial na camada de plataforma
A Blockchain0x não mantém fundos de clientes. As carteiras são de propriedade do agente (ou do provedor de custódia subjacente que o cliente conectou, como Carteiras Programáveis da Circle ou Coinbase Smart Wallet). O serviço Blockchain0x opera a superfície do desenvolvedor acima dessas carteiras - APIs, painel, identidade, política de gastos - e nunca tem autoridade de assinatura sobre os saldos.
Política de gasto aplicada no lado do servidor, não no agente
Limites diários, tetos por pagamento, listas de permissões de contrapartes e janelas de tempo são avaliados pela API da carteira Blockchain0x em cada intenção de pagamento antes da liquidação. O tempo de execução do agente não pode acessar o armazenamento de políticas; um agente que recebe injeção de prompt ainda não pode aumentar seus próprios limites.
Confirmação de pagamento validada por recibo
Os recibos de pagamento apresentados pela API são validados no lado do servidor em relação à transação de emissão antes de serem confirmados. Um cliente não pode forjar um recibo localmente e apresentá-lo como prova de pagamento; a etapa de validação do recibo é o mesmo modelo de confiança que as assinaturas de webhook da Stripe usam.
Assinaturas de webhook, não segredos compartilhados em URLs
Cada evento de webhook que emitimos é assinado com HMAC-SHA256 sobre o corpo bruto usando um segredo de assinatura por inquilino. O segredo de assinatura nunca é enviado na URL ou na string de consulta. Os clientes verificam as assinaturas ao receber; fornecemos implementações de referência na documentação.
Onde estamos hoje, honestamente.
The table below is the current state of external audits, third-party reviews, and certifications. We update this page when any line changes - dates are real, scopes are real, and "planned" means scheduled with a firm, not aspirational.
Teste de penetração de terceiros
Planejado para o Q4 2026O primeiro teste de penetração externo está agendado para a segunda metade do ano. Escopo: aplicativo web, APIs públicas, superfície de webhook, autenticação do painel. Um resumo do relatório completo será publicado aqui quando estiver concluído.
SOC 2 Tipo I
Previsto para 2027Não somos auditados pelo SOC 2 hoje. A janela esperada honesta para uma atestação de Tipo I é a primeira metade de 2027; o Tipo II segue após um período de observação de 6 a 12 meses.
Auditorias de contratos inteligentes
Herdado da fonteHoje não operamos nossos próprios smart contracts. As primitivas on-chain são Circle Programmable Wallets, Coinbase Smart Wallet e os contratos subjacentes de Base / USDC, todos com seus próprios relatórios independentes de auditoria das equipes emissoras. Se e quando lançarmos nossos próprios contratos (recursos de account abstraction), eles serão auditados antes da implantação na mainnet.
Revisão de segurança interna anual
Em andamentoRotação de segredos trimestral, revisão de varredura de dependências e auditoria de controle de acesso. Lista de verificação de endurecimento pré-lançamento documentada em nosso [guia de segurança da sua carteira de agente](/learn/guides/secure-your-agent-wallet) para clientes; a versão interna reflete isso.
Não operamos um bug bounty pago.
Para deixar completamente claro: a Blockchain0x não tem programa de bug bounty e não paga dinheiro, criptoativos, créditos, brindes ou qualquer outra compensação por vulnerabilidades reportadas. Não há níveis de severidade, nem faixas de pagamento, nem negociação sobre isso - qualquer pessoa que diga o contrário não está nos citando. Preferimos dizer isso de forma direta do que deixar um pesquisador passar o fim de semana em nossos sistemas esperando um cheque que não existe.
O que temos é um processo de divulgação coordenada sem pagamento. Os relatórios vão para nosso email de segurança e são lidos por uma pessoa. Confirmamos o recebimento de cada relatório por email e, para as descobertas que confirmarmos como válidas, oferecemos um certificado de divulgação responsável e, se você quiser, seu nome ou handle na nossa lista pública de agradecimentos. Esse é o limite total do que oferecemos hoje. Se isso mudar, esta página mudará junto.
Em escopo
- Autenticação e gerenciamento de sessão no painel ou na API.
- Escalada de privilégios entre workspaces ou agentes na mesma conta.
- Server-side request forgery, command injection ou execução remota de código na API.
- Bypass de assinatura do webhook ou bypass de validação de recibo.
- Burlar a política de gastos que permite a um agente mover dinheiro fora de seus limites configurados ou allowlist.
- Exposição significativa de dados (transações, segredos e logs de auditoria de outros tenants).
Fora do escopo
- Self-XSS ou ataques que exigem que a vítima digite ou cole entrada maliciosa no próprio console.
- Relatos que dependem de engenharia social de funcionários ou contratados.
- Relatos sobre serviços de terceiros com os quais a Blockchain0x se integra (Coinbase, Circle, etc) - esses devem ser encaminhados ao programa do próprio terceiro.
- Descobertas contra endpoints de teste (`sk_test_` keys, `*.test.blockchain0x.com`, Base Sepolia).
- Cabeçalhos de segurança ausentes sem impacto demonstrado.
- Questões teóricas sem um proof-of-concept funcional.
| O que um relator recebe | Detalhes |
|---|---|
| Confirmação por email | Todo relatório recebe uma resposta humana de [email protected], independentemente de a descoberta ser válida ou não, além do resultado da triagem assim que o tivermos. |
| Certificado de divulgação responsável | Para descobertas confirmadas, reproduzíveis e dentro do escopo: um certificado assinado nomeando você (ou seu handle), a classe do problema e a data da divulgação. Emitido após o lançamento da correção. |
| Agradecimento público | Com sua permissão, seu nome ou handle será adicionado à lista de agradecimentos publicada nesta página assim que o problema for corrigido. Se preferir, permaneça anônimo - basta nos dizer. Condicionado aos termos de confidencialidade abaixo. |
| Recompensa monetária | Nenhuma. Não pagamos por vulnerabilidades reportadas em nenhum nível de severidade, e o envio de um relatório não cria direito a pagamento. |
As decisões de validade são tomadas pelo lead de engenharia em conversa com o fundador e são finais. O reconhecimento é destinado a achados confirmados, reproduzíveis e dentro do escopo; quando o mesmo problema é reportado mais de uma vez, o primeiro reportante é quem recebe o crédito. Não exigimos NDA para registrar um relatório, e as condições abaixo são os únicos requisitos.
Condições vinculadas ao reconhecimento
Tanto o certificado de divulgação responsável quanto o reconhecimento público dependem de você manter o relatório confidencial. Não publique a vulnerabilidade, o relatório ou qualquer detalhe dele - etapas de reprodução, código de proof-of-concept, capturas de tela, endpoints afetados ou nossa correspondência sobre o assunto - em qualquer meio. Isso inclui posts de blog, artigos, publicações de texto ou imagem em qualquer rede social ou fórum, vídeo, áudio, podcasts, palestras em conferências, newsletters, grupos de chat e derivados gerados por IA de qualquer um dos itens acima. Se você quiser publicar após a correção ser lançada, fale conosco antes e normalmente concordaremos por escrito com uma data e um nível de detalhamento. Publicar sem esse acordo escrito faz você perder o certificado e o reconhecimento, e reservamos todos os demais recursos legais disponíveis.
Separadamente, e sem exceção: qualquer tentativa de nos extorquir dinheiro ou nos chantagear de qualquer forma - exigindo pagamento para reter, atrasar ou excluir um relatório, ameaçando publicar ou vender uma descoberta caso não paguemos, ou nos pressionando com um prazo sustentado por uma ameaça - não é pesquisa de segurança. Não pagaremos. Essas tentativas serão tratadas estritamente conforme a legislação aplicável, inclusive com comunicação do caso às autoridades policiais e cooperação integral com qualquer investigação ou processo subsequente. Pesquisadores de boa-fé não têm motivo para preocupação; este parágrafo não se aplica a você.
Agradecimentos públicos
Os pesquisadores que reportaram uma vulnerabilidade confirmada e solicitaram crédito são listados aqui, do mais recente ao mais antigo, assim que a correção for publicada. Ainda não há ninguém listado - se você for o primeiro, indicaremos isso aqui com seu nome ou handle e o mês do relatório. Uma inclusão aqui está sujeita às condições de confidencialidade descritas acima.
Como relatar um problema de segurança.
Envie um email para [email protected] com: uma descrição do problema, uma reprodução passo a passo, a URL ou endpoint afetado, o impacto que você observou e o nome ou handle que você gostaria que aparecesse no certificado e na lista de agradecimentos (um handle é suficiente; não é necessário nome real, e você pode pedir para permanecer anônimo). Relatórios criptografados são bem-vindos - nossa chave PGP está disponível mediante solicitação.
Nos comprometemos a confirmar o recebimento do seu relatório em até dois dias úteis, fazer a triagem em até cinco e entregar uma correção ou uma decisão de aceitação de risco em até trinta dias para achados confirmados (ou antes, em caso de problemas críticos). Não ameaçamos com ação legal a pesquisa de segurança de boa-fé que siga as práticas de divulgação responsável - expondo dados apenas na medida necessária para demonstrar o problema, sem exfiltrar dados de clientes, sem executar testes disruptivos que afetem usuários em produção e sem publicar o achado antes de termos acordado por escrito quando e como ele poderá ser publicado.
Para questões não relacionadas à segurança (suporte geral, faturamento, parcerias), use /contact. O email de segurança é monitorado apenas para relatórios de segurança.
O que dizemos se algo der errado.
Incidentes de produção que afetam fundos de clientes, dados de clientes ou a disponibilidade da API de pagamento recebem um post-mortem público dentro de trinta dias após a resolução, independentemente da gravidade. Incidentes menores (desempenho degradado, interrupções parciais na região) são comunicados por meio de atualizações de status aos clientes afetados, mas não necessariamente recebem um post-mortem.
Não culpamos os clientes em post-mortems. Não culpamos provedores de terceiros se a causa raiz foi nossa. Nomeamos as causas raízes de forma clara, listamos o que estamos mudando como resultado e mantemos o post-mortem disponível indefinidamente. A expectativa que os clientes devem ter é que nós lhe diremos o que aconteceu antes que você precise perguntar.
Contato de Segurança
Relatórios de vulnerabilidade: [email protected]. Chave PGP mediante solicitação. Os relatórios são confirmados, não pagos.