Sécurité chez Blockchain0x.
Les paiements d'agents déplacent de l'argent réel. Les choix architecturaux qui protègent les fonds des clients, la posture d'audit telle qu'elle est aujourd'hui, et comment nous contacter si vous trouvez quelque chose de mal.
Ce à quoi vous pouvez vous attendre de cette page.
Nous sommes une entreprise en phase initiale qui livre une infrastructure à laquelle les clients confieront une autorité de paiement. La confiance se construit sur ce que vous pouvez vérifier, pas sur ce qu'on vous dit. Cette page documente quatre éléments que les clients et les chercheurs en sécurité peuvent vérifier ou sur lesquels ils peuvent nous engager : les garanties architecturales qui tiennent même si nous nous trompons sur tout le reste, l'état actuel de notre posture d'audit (y compris ce que nous n'avons pas encore fait), le périmètre de notre politique de divulgation des vulnérabilités et exactement ce qu'un rapporteur reçoit (de la reconnaissance, pas de l'argent), ainsi que le canal de contact pour une divulgation responsable.
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.
Quatre propriétés qui tiennent par construction.
Les garanties ci-dessous sont architecturales - ce sont des propriétés de la façon dont le système est construit, pas de la façon dont il est exploité. La sécurité opérationnelle peut faillir (une clé divulguée, un déploiement mal configuré) ; les garanties architecturales ne dépendent pas du bon fonctionnement des opérations quotidiennes. Ce sont les parties de l'histoire de la sécurité sur lesquelles vous pouvez compter même lors de la pire semaine d'opérations.
Non-custodial au niveau de la plateforme
Blockchain0x ne détient pas les fonds des clients. Les portefeuilles appartiennent à l'agent (ou au fournisseur de garde sous-jacent que le client a connecté, comme les portefeuilles programmables Circle ou le portefeuille intelligent Coinbase). Le service Blockchain0x opère la surface développeur au-dessus de ces portefeuilles - APIs, tableau de bord, identité, politique de dépense - et n'a jamais d'autorité de signature sur les soldes.
Politique de dépense appliquée côté serveur, pas dans l'agent
Les plafonds quotidiens, les plafonds par paiement, les listes blanches des contreparties et les fenêtres temporelles sont évalués par l'API de portefeuille Blockchain0x sur chaque intention de paiement avant le règlement. Le runtime de l'agent ne peut pas accéder au stockage des politiques ; un agent qui subit une injection de prompt ne peut toujours pas augmenter ses propres limites.
Confirmation de paiement validée par reçu
Les reçus de paiement affichés par l'API sont validés côté serveur par rapport à la transaction émettrice avant qu'ils ne soient confirmés. Un client ne peut pas falsifier un reçu localement et le présenter comme preuve de paiement ; l'étape de validation du reçu est le même modèle de confiance que les signatures de webhook de Stripe utilisent.
Signatures de webhook, pas de secrets partagés dans les URL
Chaque événement webhook que nous émettons est signé avec HMAC-SHA256 sur le corps brut en utilisant un secret de signature par locataire. Le secret de signature n'est jamais envoyé dans l'URL ou la chaîne de requête. Les clients vérifient les signatures à la réception ; nous fournissons des implémentations de référence dans la documentation.
Où nous en sommes aujourd'hui, honnêtement.
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.
Test de pénétration par un tiers
Prévu pour le T4 2026Le premier test de pénétration externe est prévu pour la deuxième moitié de l'année. Portée : application web, API publiques, surface webhook, authentification du tableau de bord. Un résumé complet du rapport sera publié ici une fois terminé.
SOC 2 Type I
Ciblé pour 2027Nous ne sommes pas audités SOC 2 aujourd'hui. La fenêtre attendue pour une attestation de Type I est la première moitié de 2027 ; le Type II suit après une période d'observation de 6 à 12 mois.
Audits de contrats intelligents
Hérité de l'amontNous n'exploitons pas aujourd'hui nos propres smart contracts. Les primitives on-chain sont Circle Programmable Wallets, Coinbase Smart Wallet et les contrats Base / USDC sous-jacents, qui disposent tous de leurs propres rapports d'audit indépendants fournis par les équipes émettrices. Si nous lançons nos propres contrats - ou lorsque nous le ferons - (fonctionnalités d'account abstraction), ils seront audités avant le déploiement sur le mainnet.
Revue annuelle de la sécurité interne
En coursRotation secrète trimestrielle, révision de l'analyse des dépendances et audit de contrôle d'accès. Liste de contrôle de durcissement avant lancement documentée dans notre [guide sécuriser votre portefeuille d'agent](/learn/guides/secure-your-agent-wallet) pour les clients ; la version interne lui correspond.
Nous ne proposons pas de bug bounty rémunéré.
Pour être parfaitement clair : Blockchain0x n'a aucun programme de bug bounty et ne verse ni argent, ni crypto-actifs, ni crédits, ni goodies, ni aucune autre compensation pour les vulnérabilités signalées. Il n'existe ni niveaux de gravité, ni fourchettes de paiement, ni négociation à ce sujet - toute personne qui vous dirait le contraire ne nous cite pas. Nous préférons le dire explicitement plutôt que de laisser un chercheur passer un week-end sur nos systèmes en attendant un chèque qui n'existe pas.
En revanche, nous appliquons un processus de divulgation coordonnée non rémunéré. Les rapports sont envoyés à notre adresse de sécurité et lus par un humain. Nous accusons réception de chaque rapport par email, et pour les découvertes que nous confirmons comme valides, nous proposons un certificat de divulgation responsable et, si vous le souhaitez, votre nom ou pseudonyme sur notre liste publique de remerciements. C'est tout ce que nous proposons aujourd'hui. Si cela change, cette page changera avec.
Dans le champ d'application
- Authentification et gestion des sessions sur le tableau de bord ou l'API.
- Escalade de privilèges entre des espaces de travail ou des agents sur le même compte.
- Server-side request forgery, injection de commandes ou exécution de code à distance dans l'API.
- Contournement de la signature du webhook ou contournement de la validation du reçu.
- Contournement de la politique de dépenses qui permet à un agent de déplacer de l'argent en dehors de ses plafonds configurés ou de sa liste d'autorisation.
- Exposition importante de données (transactions d'autres locataires, secrets, journaux d'audit).
Hors de portée
- Self-XSS ou attaques qui exigent que la victime tape ou colle une entrée hostile dans sa propre console.
- Signalements qui reposent sur l'ingénierie sociale du personnel ou des prestataires.
- Les signalements concernant des services tiers avec lesquels Blockchain0x s'intègre (Coinbase, Circle, etc) - doivent être adressés au programme propre du tiers.
- Résultats contre les endpoints de test (`sk_test_` keys, `*.test.blockchain0x.com`, Base Sepolia).
- En-têtes de sécurité manquants sans impact démontré.
- Problèmes théoriques sans preuve de concept fonctionnelle.
| Ce qu'un rapporteur reçoit | Détails |
|---|---|
| Accusé de réception par email | Chaque rapport reçoit une réponse humaine de [email protected], que la découverte soit valide ou non, ainsi que le résultat du triage dès qu'il est disponible. |
| Certificat de divulgation responsable | Pour les découvertes confirmées, reproductibles et dans le périmètre : un certificat signé indiquant votre nom (ou pseudonyme), la catégorie du problème et la date de divulgation. Délivré après le déploiement du correctif. |
| Reconnaissance publique | Avec votre autorisation, votre nom ou pseudonyme est ajouté à la liste des remerciements publiée sur cette page une fois le problème corrigé. Restez anonyme si vous le préférez - dites-le-nous simplement. Sous réserve des conditions de confidentialité ci-dessous. |
| Récompense monétaire | Aucune. Nous ne rémunérons aucune vulnérabilité signalée, quel que soit son niveau de gravité, et la soumission d'un rapport ne crée aucun droit à paiement. |
Les décisions de validité sont prises par le responsable engineering en concertation avec le fondateur et sont définitives. La reconnaissance concerne les constats confirmés, reproductibles et dans le périmètre ; lorsqu'un même problème est signalé plusieurs fois, le premier signalant est celui qui est crédité. Nous n'exigeons pas de NDA pour déposer un signalement, et les conditions ci-dessous sont les seules restrictions applicables.
Conditions liées à la reconnaissance
Le certificat de divulgation responsable et la reconnaissance publique sont tous deux conditionnés au maintien de la confidentialité du signalement. Ne publiez pas la vulnérabilité, le signalement ni aucun de ses détails - étapes de reproduction, code de preuve de concept, captures d'écran, points de terminaison concernés, ou nos échanges à ce sujet - sous quelque forme que ce soit. Cela inclut les articles de blog, les comptes rendus, les publications textuelles ou illustrées sur tout réseau social ou forum, la vidéo, l'audio, les podcasts, les conférences, les newsletters, les groupes de discussion et les dérivés générés par IA de l'un quelconque de ce qui précède. Si vous souhaitez publier après le déploiement du correctif, demandez-nous d'abord et nous conviendrons généralement par écrit d'une date et d'un niveau de détail. Publier sans cet accord écrit entraîne la perte du certificat et de la reconnaissance, et nous nous réservons tout autre recours à notre disposition.
Par ailleurs, et sans exception : toute tentative de nous extorquer de l'argent ou de nous faire chanter sous quelque forme que ce soit - exiger un paiement pour retenir, retarder ou supprimer un signalement, menacer de publier ou de vendre un résultat si nous ne payons pas, ou nous mettre sous pression avec une échéance assortie d'une menace - ne relève pas de la recherche en sécurité. Nous ne paierons pas. De telles tentatives seront traitées strictement conformément au droit applicable, notamment par un signalement aux forces de l'ordre et une coopération totale avec toute enquête ou poursuite qui en découlerait. Les chercheurs de bonne foi n'ont rien à craindre ici ; ce paragraphe ne vous vise pas.
Remerciements publics
Les chercheurs qui ont signalé une vulnérabilité confirmée et demandé à être crédités sont listés ici, du plus récent au plus ancien, une fois le correctif déployé. Personne n'est encore सूची. Si vous êtes le premier, nous le préciserons ici avec votre nom ou pseudonyme et le mois du signalement. Cette mention est soumise aux conditions de confidentialité énoncées ci-dessus.
Comment signaler un problème de sécurité.
Envoyez un email à [email protected] avec : une description du problème, une reproduction étape par étape, l'URL ou le point de terminaison affecté, l'impact observé, ainsi que le nom ou pseudonyme que vous souhaitez voir figurer sur le certificat et dans la liste des remerciements (un pseudonyme suffit - aucun nom réel n'est requis, et vous pouvez demander à rester anonyme). Les rapports chiffrés sont les bienvenus - notre clé PGP est disponible sur demande.
Nous nous engageons à accuser réception de votre signalement sous deux jours ouvrables, à le qualifier sous cinq jours, et à déployer un correctif ou une décision d'acceptation du risque sous trente jours pour les constats confirmés (ou plus tôt pour les problèmes critiques). Nous ne menaçons pas d'action en justice les recherches de sécurité de bonne foi qui respectent les pratiques de divulgation responsable - en n'exposant les données qu'au strict nécessaire pour démontrer le problème, sans exfiltrer de données clients, sans exécuter de tests perturbateurs affectant les utilisateurs en production, et sans publier le résultat avant d'avoir convenu par écrit de la date et des modalités de publication.
Pour les problèmes non liés à la sécurité (support général, facturation, partenariats), utilisez /contact. L'email de sécurité est surveillé uniquement pour les rapports de sécurité.
Ce que nous disons si quelque chose ne va pas.
Les incidents de production qui affectent les fonds des clients, les données des clients ou la disponibilité de l'API de paiement obtiennent un post-mortem public dans les trente jours suivant la résolution, quelle que soit la gravité. Les incidents plus petits (performance dégradée, pannes partielles) sont communiqués via des mises à jour de statut aux clients concernés mais ne reçoivent pas nécessairement de post-mortem.
Nous ne blâmons pas les clients lors des post-mortems. Nous ne blâmons pas les fournisseurs tiers si la cause profonde était la nôtre. Nous nommons les causes profondes clairement, listons ce que nous changeons en conséquence, et gardons le post-mortem disponible indéfiniment. L'attente que les clients devraient avoir est que nous vous dirons ce qui s'est passé avant que vous ayez à demander.
Contact sécurité
Signalements de vulnérabilités : [email protected]. Clé PGP sur demande. Les rapports sont accusés de réception, pas rémunérés.