Sécurité · ArcaKey Private AI

IA pour les professionnels réglementés —
sans compromis sur la confidentialité.

Chaque allégation défendable de ce site est associée à l'artefact qui la soutient. Téléchargez l'échantillon d'attestation signé, lisez le livre blanc, inspectez le modèle de menaces. Si un artefact n'existe pas encore, il est étiqueté comme tel — pas dissimulé.

Posture de sécurité

ArcaKey protège les travaux qui ne peuvent être exposés. Nous le faisons en nous engageant sur un standard architectural vérifiable plutôt que sur un standard de politique promis.

Vous trouverez ci-dessous l'état actuel de notre programme de sécurité : primitives et architecture, artefacts de preuve, posture de conformité actuelle et politique de divulgation. Chaque allégation de cette page est associée à un artefact qu'un acquéreur averti, un journaliste ou un avocat de barreau peut lire.

Si vous évaluez ArcaKey en vue d'un déploiement organisationnel, le dossier d'évaluation au bas de cette page rassemble l'ensemble documentaire complet. Les candidats Sovereign reçoivent le même dossier accompagné de briefings techniques additionnels sur demande.

Primitives cryptographiques

Symétrique (au repos)
AES-256-GCM.
Échange de clés
ML-KEM-768 (CRYSTALS-Kyber, NIST FIPS 203), hybridé avec X25519.
Authentification
FIDO2 sur Executive et au-delà ; phrase secrète dérivée en Argon2id en repli (universel).
Signatures du journal d'audit
Ed25519, chaînées par hash, par utilisateur.
Fragments de réponse
ML-DSA-65 (CRYSTALS-Dilithium, NIST FIPS 204).
Enclave d'inférence
Intel TDX + NVIDIA H100 Confidential Computing sur GCP A3 Confidential VM ; les opérateurs ne peuvent pas lire les requêtes pendant le traitement.
Attestation
NVIDIA Remote Attestation Service (NRAS), par session, vérifiable par locataire via le SDK nvtrust.

Portée post-quantique

L'enveloppe navigateur-vers-CVM d'ArcaKey au niveau de l'application (ML-KEM-768) est active aujourd'hui et se termine dans l'enclave CVM attestée pour le trafic Tab 1 et Tab 2. Vercel transmet le texte chiffré KEM mais ne peut pas le déencapsuler. Le KEM post-quantique hybride sur TLS de bord (X25519MLKEM768) est une défense *supplémentaire* à la couche de terminaison TLS ; il reste tributaire du fournisseur et suit les déploiements de bord de Vercel et Cloudflare. Jusqu'à ce que TLS PQ KEM en bord soit activé, l'échange de clés au niveau du transport est TLS 1.3 avec ECDHE classique — mais l'enveloppe interne de l'application est déjà PQ-sécurisée. Cela protège contre « récolter maintenant, déchiffrer plus tard » face à de futurs adversaires quantiques : même si le TLS d'une session capturée était cassé dans 50 ans, l'enveloppe interne ML-KEM-768 reste FIPS 203-sécurisée.

Sous-traitants

ArcaKey route l'inférence et les charges de soutien à travers un petit ensemble de sous-traitants nommés. Chaque entrée ci-dessous décrit son rôle structurel et sa posture de conformité / traitement des données. Le trafic des niveaux Confidential AI et Private AI va vers l'un des deux backends attestés TEE — Phala pour les configurations Qwen 3.5 27B et Qwen 2.5 7B, Tinfoil pour tous les autres modèles sur ces niveaux. Le trafic du niveau Best in Class AI va directement au fournisseur de frontière (Anthropic, OpenAI ou AWS Bedrock pour Mistral Large 3) sous le contrat de chaque fournisseur. Les sous-traitants de plateforme et d'infrastructure sont listés en dessous.

TEE backends (Confidential AI / Private AI)

PhalaBackend TEE — Qwen 3.5 27B + Qwen 2.5 7B
SOC 2 Type I + HIPAA, portée spécifiquement aux configurations Qwen 2.5 / Qwen 3.5 sur Phala — PAS une certification Phala-en-tant-que-plateforme. Le rôle de Phala aujourd'hui est borné à ces deux modèles Qwen ; toute autre inférence Confidential AI / Private AI passe par Tinfoil. Posture cryptographique : Intel TDX + NVIDIA Confidential Computing. BAA ArcaKey ↔ Phala : non demandé ; ArcaKey s'appuie sur la posture publique documentée de Phala plutôt que sur un BAA contractuel.
TinfoilBackend TEE — toute l'inférence Confidential AI / Private AI sauf les modèles Qwen de Phala
TEE attesté par modèle (Intel TDX + NVIDIA Confidential Computing). SOC 2 Type II au niveau plateforme. Héberge le modèle Pro / Pro Suite par défaut recommandé (Llama 3.3 70B) sur une route persistante — pas scale-to-zero — éliminant la latence de démarrage à froid. BAA ArcaKey ↔ Tinfoil : non disponible — Tinfoil ne fournit de BAA à aucun client. La chaîne d'attestation TEE est la garantie substantielle d'aveuglement de l'opérateur pour ce fournisseur ; les revendications liées à SOC 2 / HIPAA proviennent de la posture publique de Tinfoil plutôt que d'un BAA.

Platform & infrastructure

VercelHébergement d'application + bord
SOC 2 Type II (vérifiable publiquement sur Vercel Trust Center). Héberge les surfaces marketing et l'application vault. Termine la connexion TLS entrante depuis le navigateur du client ; pour Tab 1 et Tab 2 le texte clair de l'invite du client n'atteint jamais Vercel — il est chiffré sous la clé par session à l'intérieur du navigateur et transmis comme texte chiffré.
CloudflareCDN + DNS
SOC 2 Type II, ISO 27001, FedRAMP Moderate au niveau plateforme. Sert les actifs statiques et le DNS. Ne voit pas le trafic d'inférence.
SupabaseBase de données + stockage d'objets
SOC 2 Type II. Héberge le magasin de mémoires vault chiffrées au repos, le journal d'audit et les données structurées de compte. Tout le contenu blob est chiffré côté client ou à l'intérieur du CVM avant écriture ; Supabase ne voit que du texte chiffré.
ClerkIdentité / auth
SOC 2 Type II. Gère l'authentification ; ne touche jamais au contenu du vault ni au trafic d'inférence.
UpstashEnveloppe Redis par session
SOC 2 Type II. Détient l'enveloppe par session (bornée par TTL). Le MEK de session vit seulement à l'intérieur du CVM pour Tab 1 / Tab 2 ; pour les sessions Vercel-direct, l'enveloppe reste sous emballage avec la clé de plateforme sur Upstash.
AWS (KMS)CMK tenant pour opt-in Executive
SOC 2 Type II, FIPS 140-2 Niveau 2 (KMS) ; FIPS 140-2 Niveau 3 disponible via CloudHSM (activation JIT sur exigence contractuelle L3). Utilisé pour l'emballage Customer Master Key à portée tenant sur le DEK par bloc lorsqu'un client Executive opte. DPA AWS standard + éligible HIPAA sous AWS BAA. Le client contrôle la clé dans son propre compte AWS ; le rôle IAM runtime d'ArcaKey reçoit uniquement Encrypt / Decrypt.
StripeFacturation
SOC 2 Type II, PCI-DSS Niveau 1. Gère uniquement le traitement des paiements ; ne touche jamais au contenu du vault ni au trafic d'inférence.
Brave SearchIndex de recherche web (opt-in par tour)
Index de recherche sous contrat. Pour Tab 1 et Tab 2, la requête Brave est faite depuis l'intérieur du CVM attesté ; le texte clair de la requête n'atteint jamais Vercel. Pour Tab 3, la requête est faite depuis le runtime Vercel. Brave voit le texte clair de la requête dans tous les cas — ArcaKey ne prétend pas à une recherche chiffrée de bout en bout.

Frontier model providers (Best in Class AI)

AnthropicFournisseur de modèles de frontière — famille Claude
SOC 2 Type II ; programme BAA fournisseur disponible. BAA + ZDR entre ArcaKey et Anthropic tous deux demandés le 2026-05-24 sous ArcaKey AI, LLC ; en attente de contre-signature. Atteignable en Pro Suite et au-dessus ; l'accès couvert par HIPAA s'active dès que les deux contrats sont contre-signés.
OpenAIFournisseur de modèles de frontière — famille GPT
SOC 2 Type II ; programme BAA fournisseur disponible. BAA entre ArcaKey et OpenAI actif depuis 2026-05-24 sous ArcaKey AI, LLC. ZDR non contracté séparément à ce stade — la rétention par défaut de l'API OpenAI s'applique. Atteignable sur tous les paliers payants (avec gating par modèle).
AWS Bedrock (Mistral Large 3)Fournisseur de modèles de frontière — Mistral Large 3 en us-east-2
SOC 2 Type II, ISO 27001, FIPS 140-2 Niveau 2 (KMS). BAA au niveau du compte AWS actif depuis 2026-05-11 sous ArcaKey AI, LLC — le même parapluie BAA qui couvre notre infrastructure KMS de CMK par tenant. Mistral Large 3 est servi exclusivement via Bedrock ; l'API directe de Mistral La Plateforme (DPA uniquement, pas de programme BAA fournisseur) n'est pas utilisée. Atteignable en Executive et au-dessus.

Traitement HIPAA / PHI — trois couches distinctes

Les acheteurs examinant l'histoire HIPAA d'ArcaKey doivent distinguer trois couches indépendantes, chacune avec son propre état aujourd'hui. La confusion courante de l'acheteur est de les confondre — « Anthropic a un BAA, donc mes données sont couvertes » est une déclaration de couche 1, pas une déclaration de couche 3, et l'écart entre elles est contractuel et non cryptographique.

  1. Programmes BAA au niveau fournisseur

    Anthropic et OpenAI offrent des programmes BAA au niveau fournisseur (la source du badge « BAA AVAILABLE » sur la surface Tab 3). Le BAA de Google Vertex AI est en attente. Mistral n'a pas de programme BAA fournisseur propre, mais ArcaKey route Mistral exclusivement via AWS Bedrock sous le BAA au niveau du compte AWS (actif depuis 2026-05-11), de sorte que l'inférence Mistral porte la même posture éligible HIPAA que le reste de Tab 3 — via un mécanisme contractuel distinct. Ce sont des capacités du fournisseur et de l'infrastructure, indépendantes de tout contrat qu'ArcaKey ait signé.

  2. Exécution BAA ArcaKey ↔ fournisseur

    Si ArcaKey a contresigné chaque BAA amont est suivi sur une matrice vivante de sous-traitant BAA ; toutes les portes ne sont pas fermées aujourd'hui. La ligne JIT « traitement productisé couvert par HIPAA » suit la fermeture des portes résiduelles plus la contresignature BAA de Vercel. Accessible via le pack d'évaluation pour les examinateurs de due diligence.

  3. BAA ArcaKey ↔ client

    ArcaKey ne détient aucun contrat direct avec des clients couverts par HIPAA aujourd'hui. Le premier engagement client signé nécessitant un traitement couvert déclenche le déclencheur JIT ; jusque-là, la posture cryptographique (Phala TEE sur Tab 1, à portée Qwen 2.5 / 3.5 ; ZDR + fournisseurs éligibles BAA fournisseur sur Tab 3) existe indépendamment de l'exécution BAA côté client.

Artefacts liés

Vérification prête pour revue : /security-review

Attestation en service

Chaque session routée par TEE émet un artefact d'attestation signé que vous pouvez télécharger et vérifier hors ligne. L'échantillon ci-dessous est signé fraîchement à chaque demande — c'est un artefact réel, pas un fichier statique.

Télécharger un échantillon signéClé publique publiéeComment vérifier

Note pré-lancement : la couche de preuves NRAS est sourcée en stub jusqu'à activation de la capacité GCP A3 Confidential VM. La signature de liaison ArcaKey sur l'artefact est réelle et vérifiable aujourd'hui. Le passage à NRAS en service est automatique au moment de la mise en capacité — la forme de l'artefact ne change pas. Voir la Section 6 de la référence d'attestation TEE.

Checklist des allégations défendables

AllégationVérifié par
Chiffré de bout en boutLivre blanc, Section 4
Chiffrement post-quantique (ML-KEM-768 / ML-DSA-65)Livre blanc, Section 3
Inférence isolée matériellement (TEE)Référence d'attestation TEE + échantillon signé
Aucun entraînement sur vos donnéesModèle de menaces, Section 3 (A4)
Clés détenues par l'utilisateur (Permanent / Sovereign)Livre blanc, Section 7
Zéro rétention à la demande (Ghost Mode)Livre blanc, Section 4 + modèle de menaces A4
ArcaKey ne peut pas lire le contenu SovereignArchitecture end-to-end-to-enclave
Prévention de l'altération des réponsesLivre blanc, Section 4 + modèle de menaces A6

Politique de divulgation

ArcaKey accueille les rapports de problèmes de sécurité. Nous nous engageons à :

  • · Accuser réception d'un rapport sous 1 jour ouvré.
  • · Fournir une évaluation de triage sous 5 jours ouvrés.
  • · Ne pas engager de poursuites contre les chercheurs qui agissent de bonne foi, n'exfiltrent pas de données client et nous laissent un délai raisonnable pour remédier avant divulgation publique.
  • · Créditer publiquement les rapporteurs qui souhaitent figurer dans les Acknowledgments.

Signaler à security@arcakey.ai. Clé PGP à /docs/arcakey-security-pgp.txt (publication en attente).

Need a written assessment?

The ArcaKey Defensibility Audit is a 30-day advisory engagement that produces a founder-signed, independently reviewed memo mapping your AI workflows against Title 21, NIST post-quantum, and AI RMF standards. Suitable for inclusion in your AI governance file, sponsor due-diligence packet, or regulatory submission appendix.

See the Defensibility Audit

Dossier d'évaluation

Les organisations qualifiées peuvent demander le dossier d'évaluation ArcaKey — livre blanc d'architecture, modèle de menaces, synthèse exécutive du pentest indépendant (dès finalisation), modèle de BAA HIPAA, lettre d'observation SOC 2 et briefing technique de 30 minutes avec le fondateur.

Demander le dossier d'évaluationPour les organisations

Acknowledgments

Aucun rapport publié pour le moment — cette section listera les chercheurs au fur et à mesure du triage et de la remédiation des rapports.