Security · ArcaKey Private AI

A promise can be broken.
Our encryption can’t.

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
NVIDIA H100 confidential computing on GCP A3 Confidential VM; AMD SEV-SNP memory encryption.
Attestation
NVIDIA Remote Attestation Service (NRAS), per session, tenant-verifiable via the nvtrust SDK.

Linked artifacts

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.

Download signed samplePublished pubkeyHow to verify

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 §6 of the TEE attestation reference.


Defensible-claims checklist

ClaimVerified by
End-to-end encryptedWhitepaper §4
Post-quantum encryption (ML-KEM-768 / ML-DSA-65)Whitepaper §3
Hardware-isolated inference (TEE)TEE attestation reference + signed sample
Zero training on your dataThreat model §3 (A4)
User-held keys (Permanent / Sovereign)Whitepaper §7
Zero retention on demand (Ghost Mode)Whitepaper §4 + threat model A4
ArcaKey cannot read Sovereign content (Phase 2)Phase 2 architecture
Response tampering preventionWhitepaper §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).


Evaluation 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.

Request evaluation packFor organizations

Acknowledgments

No published reports yet — this section will list researchers as reports are triaged and remediated.