AI for regulated professionals
— without compromising privacy.
Every defensible claim on this site is paired with the artifact that backs it. Download the signed attestation sample, read the whitepaper, inspect the threat model. If an artifact does not exist yet, it is labeled so — not hidden.
Security posture
ArcaKey protects work that cannot be exposed. We do that by committing to an architectural standard that is verifiable rather than a policy standard that is promised.
Below is the current state of our security program: primitives and architecture, proof artifacts, current compliance posture, and disclosure policy. Every claim on this page is paired with an artifact a sophisticated buyer, a journalist, or a bar counsel can read.
If you’re evaluating ArcaKey for organizational deployment, the evaluation pack at the bottom of this page collects the full documentation set. Sovereign applicants receive the same pack plus additional technical briefings on request.
Cryptographic primitives
- Symmetric (at rest)
- AES-256-GCM.
- Key exchange
- ML-KEM-768 (CRYSTALS-Kyber, NIST FIPS 203), hybridized with X25519.
- Authentication
- FIDO2 at Executive and above; Argon2id-derived passphrase as fallback.
- Audit log signatures
- Ed25519, hash-chained per user.
- Response chunks
- ML-DSA-65 (CRYSTALS-Dilithium, NIST FIPS 204).
- Inference enclave
- Intel TDX + NVIDIA H100 Confidential Computing on GCP A3 Confidential VM; operators cannot read prompts during processing.
- Attestation
- NVIDIA Remote Attestation Service (NRAS), per session, tenant-verifiable via the nvtrust SDK.
Post-quantum scope
ArcaKey's application-layer browser-to-CVM envelope (ML-KEM-768) is live today and terminates inside the attested CVM enclave for Tab 1 and Tab 2 traffic. Vercel forwards KEM ciphertext but cannot decapsulate. Edge TLS hybrid post-quantum KEM (X25519MLKEM768) is *additional* defense at the TLS-termination layer; it remains provider-gated and follows Vercel and Cloudflare edge rollouts. Until edge TLS PQ KEM ships, transport-layer key exchange is TLS 1.3 with classical ECDHE — but the inner application envelope is already PQ-secure. This protects against "harvest now, decrypt later" against future quantum adversaries: even if a captured session's TLS were broken in 50 years, the inner ML-KEM-768 envelope remains FIPS 203-secure.
Sub-processors
ArcaKey routes inference and supporting workloads through a small set of named sub-processors. Each entry below describes its structural role and its compliance / data-handling posture. Confidential AI and Private AI tier traffic flows to one of two TEE-attested backends — Phala for the Qwen 3.5 27B and Qwen 2.5 7B configurations, Tinfoil for all other models on these tiers. Best in Class AI tier traffic flows direct to the frontier provider (Anthropic, OpenAI, or AWS Bedrock for Mistral Large 3) under each provider's contract. Platform and infrastructure sub-processors are listed beneath.
TEE backends (Confidential AI / Private AI)
- PhalaTEE backend — Qwen 3.5 27B + Qwen 2.5 7B
- SOC 2 Type I + HIPAA scoped specifically to the Qwen 2.5 / Qwen 3.5 configurations on Phala — NOT a Phala-as-platform certification. Phala's role today is bounded to these two Qwen models; all other Confidential AI / Private AI inference flows through Tinfoil. Cryptographic posture: Intel TDX + NVIDIA Confidential Computing. ArcaKey ↔ Phala BAA: not requested; ArcaKey relies on Phala's public-documented posture rather than a contractual BAA.
- TinfoilTEE backend — all Confidential AI / Private AI inference except Phala's Qwen models
- TEE-attested per model (Intel TDX + NVIDIA Confidential Computing). SOC 2 Type II at platform level. Hosts the recommended Pro / Pro Suite default (Llama 3.3 70B) on a persistent — not scale-to-zero — route, eliminating cold-start latency. ArcaKey ↔ Tinfoil BAA: not available — Tinfoil does not provide BAAs to any customer. The TEE attestation chain is the substantive operator-blind guarantee for this provider; SOC 2 / HIPAA-related claims come from Tinfoil's public posture rather than a BAA.
Platform & infrastructure
- VercelApplication hosting + edge
- SOC 2 Type II (publicly verifiable on Vercel Trust Center). Hosts the marketing and vault application surfaces. Terminates the inbound TLS connection from the customer's browser; for Tab 1 and Tab 2 the customer's prompt plaintext never reaches Vercel — it is encrypted under the per-session key inside the browser and forwarded as ciphertext.
- CloudflareCDN + DNS
- SOC 2 Type II, ISO 27001, FedRAMP Moderate at platform level. Serves static assets and DNS. Does not see inference traffic.
- SupabaseDatabase + object storage
- SOC 2 Type II. Hosts the encrypted-at-rest vault memory store, audit log, and structured account data. All blob content is encrypted client-side or inside the CVM before write; Supabase sees only ciphertext.
- ClerkIdentity / auth
- SOC 2 Type II. Handles authentication; never touches vault content or inference traffic.
- UpstashPer-session Redis envelope
- SOC 2 Type II. Holds the per-session envelope (TTL-bound). The session MEK lives only inside the CVM for Tab 1 / Tab 2; for Vercel-direct sessions, the envelope sits under platform-key wrapping on Upstash.
- AWS (KMS)Tenant CMK for Executive opt-in
- SOC 2 Type II, FIPS 140-2 Level 2 (KMS); FIPS 140-2 Level 3 available via CloudHSM (JIT-activated on contractual L3 requirement). Used for tenant-scoped Customer Master Key wrapping of the per-blob DEK when an Executive customer opts in. Standard AWS DPA + HIPAA-eligible under AWS BAA. Customer controls the key in their own AWS account; ArcaKey's runtime IAM role is granted Encrypt / Decrypt only.
- StripeBilling
- SOC 2 Type II, PCI-DSS Level 1. Handles payment processing only; never touches vault content or inference traffic.
- Brave SearchWeb search index (opt-in per turn)
- Contracted search index. For Tab 1 and Tab 2, the Brave query is made from inside the attested CVM; the query plaintext never reaches Vercel. For Tab 3, the query is made from Vercel runtime. Brave sees the query plaintext in either case — ArcaKey does not claim end-to-end encrypted search.
Frontier model providers (Best in Class AI)
- AnthropicFrontier model provider — Claude family
- SOC 2 Type II; vendor BAA program available. ArcaKey ↔ Anthropic BAA + ZDR both requested 2026-05-24 under ArcaKey AI, LLC; pending countersign. Reachable on Pro Suite and above; HIPAA-covered access activates once both contracts countersign.
- OpenAIFrontier model provider — GPT family
- SOC 2 Type II; vendor BAA program available. ArcaKey ↔ OpenAI BAA active 2026-05-24 under ArcaKey AI, LLC. ZDR not separately contracted at this time — OpenAI's default API retention applies. Reachable across all paid tiers (model-specific gating).
- AWS Bedrock (Mistral Large 3)Frontier model provider — Mistral Large 3 in us-east-2
- SOC 2 Type II, ISO 27001, FIPS 140-2 Level 2 (KMS). Account-level AWS BAA active 2026-05-11 under ArcaKey AI, LLC — the same BAA umbrella that covers our tenant-CMK KMS infrastructure. Mistral Large 3 served exclusively via Bedrock; Mistral La Plateforme's direct API (DPA-only, no vendor BAA program) is not used. Reachable on Executive and above.
HIPAA / PHI processing — three distinct layers
Buyers reviewing ArcaKey's HIPAA story should distinguish three independent layers, each with its own state today. The common buyer confusion is conflating them — "Anthropic has a BAA, so my data is covered" is a layer-1 statement, not a layer-3 statement, and the gap between them is contractual rather than cryptographic.
Vendor-level BAA programs
Anthropic and OpenAI offer vendor-level BAA programs (the source of the "BAA AVAILABLE" badge on the Tab 3 surface). Google Vertex AI BAA is pending. Mistral has no vendor BAA program of its own, but ArcaKey routes Mistral exclusively via AWS Bedrock under the AWS account-level BAA (active 2026-05-11), so Mistral inference carries the same HIPAA-eligible posture as the rest of Tab 3 — through a different contractual mechanism. These are vendor and infrastructure capabilities, independent of any contract ArcaKey has signed.
ArcaKey ↔ vendor BAA execution
Whether ArcaKey has countersigned each upstream BAA is tracked on a living BAA sub-processor matrix; not all gates are closed today. The JIT row "HIPAA-covered productized processing" tracks closure of the residual gates plus Vercel BAA countersignature. Reachable via the evaluation pack for due-diligence reviewers.
ArcaKey ↔ customer BAA
ArcaKey holds no direct HIPAA-covered customer contracts today. The first signed customer engagement requiring covered processing fires the JIT trigger; until then, the cryptographic posture (Phala TEE on Tab 1, scoped to Qwen 2.5 / 3.5; ZDR + vendor-BAA-eligible providers on Tab 3) exists independent of customer-side BAA execution.
Linked artifacts
Named primitives, session architecture, TEE deployment, and explicit claims-vs-unproven separation.
- Threat model (v0.1)Shipped
In-scope adversaries, out-of-scope adversaries, trust assumptions, defense-in-depth matrix.
- TEE attestation referenceShipped
Attestation chain, evidence artifact schema, offline verification procedure, deployment status.
Sovereign activation architecture: client ↔ enclave direct key exchange; relay-only app server.
Published Ed25519 public keys used to sign attestation artifacts. Live runtime mirror at /api/vault/attestation/pubkey.
- security.txtShipped
RFC 9116 security contact and disclosure policy.
Review-ready check: /security-review
Live attestation
Every TEE-routed session emits a signed attestation artifact you can download and verify offline. The sample below is freshly signed each time you request it — it is a real artifact, not a static file.
Pre-launch note: the NRAS evidence layer is stub-sourced until GCP A3 Confidential VM capacity is active. The ArcaKey binding signature over the artifact is real and verifiable today. Transition to live NRAS is automatic on capacity cutover — the artifact shape does not change. See Section 6 of the TEE attestation reference.
Defensible-claims checklist
| Claim | Verified by |
|---|---|
| End-to-end encrypted | Whitepaper Section 4 |
| Post-quantum encryption (ML-KEM-768 / ML-DSA-65) | Whitepaper Section 3 |
| Hardware-isolated inference (TEE) | TEE attestation reference + signed sample |
| Zero training on your data | Threat model Section 3 (A4) |
| User-held keys (Permanent / Sovereign) | Whitepaper Section 7 |
| Zero retention on demand (Ghost Mode) | Whitepaper Section 4 + threat model A4 |
| ArcaKey cannot read Sovereign content | End-to-end-to-enclave architecture |
| Response tampering prevention | Whitepaper Section 4 + threat model A6 |
Disclosure policy
ArcaKey welcomes reports of security issues. We commit to:
- · Acknowledge receipt of a report within 1 business day.
- · Provide a triage assessment within 5 business days.
- · Not pursue legal action against researchers who act in good faith, do not exfiltrate customer data, and give us reasonable time to remediate before public disclosure.
- · Publicly credit reporters who wish to be named in Acknowledgments.
Report to security@arcakey.ai. PGP key at /docs/arcakey-security-pgp.txt (pending publication).
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 AuditEvaluation pack
Qualifying organizations can request the ArcaKey evaluation pack — architecture whitepaper, threat model, independent pentest executive summary (on completion), HIPAA BAA template, SOC 2 observation letter, and a 30-minute technical briefing with the founder.
Acknowledgments
No published reports yet — this section will list researchers as reports are triaged and remediated.