IA para profesionales regulados
— sin comprometer la privacidad.
Cada afirmación defendible en este sitio está pareada con el artefacto que la respalda. Descargue la muestra de atestación firmada, lea el whitepaper, inspeccione el modelo de amenazas. Si un artefacto aún no existe, está etiquetado como tal — no oculto.
Postura de seguridad
ArcaKey protege trabajo que no puede ser expuesto. Lo hacemos comprometiéndonos a un estándar arquitectónico verificable en lugar de un estándar de política prometido.
A continuación está el estado actual de nuestro programa de seguridad: primitivas y arquitectura, artefactos de prueba, postura de cumplimiento actual y política de divulgación. Cada afirmación en esta página está pareada con un artefacto que un comprador sofisticado, un periodista o un consejo del colegio puede leer.
Si está evaluando ArcaKey para despliegue organizacional, el paquete de evaluación al pie de esta página recoge el conjunto completo de documentación. Los solicitantes de Sovereign reciben el mismo paquete más sesiones técnicas adicionales a solicitud.
Primitivas criptográficas
- Simétrico (en reposo)
- AES-256-GCM.
- Intercambio de llaves
- ML-KEM-768 (CRYSTALS-Kyber, NIST FIPS 203), hibridizado con X25519.
- Autenticación
- FIDO2 en Executive y superiores; contraseña derivada por Argon2id como respaldo.
- Firmas del registro de auditoría
- Ed25519, encadenadas por hash por usuario.
- Fragmentos de respuesta
- ML-DSA-65 (CRYSTALS-Dilithium, NIST FIPS 204).
- Enclave de inferencia
- NVIDIA H100 en cómputo confidencial sobre GCP A3 Confidential VM; cifrado de memoria AMD SEV-SNP.
- Atestación
- NVIDIA Remote Attestation Service (NRAS), por sesión, verificable por el inquilino mediante el SDK nvtrust.
Alcance post-cuántico
El sobre de aplicación navegador-a-CVM de ArcaKey (ML-KEM-768) está activo hoy y termina dentro del enclave CVM atestado para el tráfico de Tab 1 y Tab 2. Vercel reenvía el texto cifrado KEM pero no puede desencapsularlo. El KEM post-cuántico híbrido en TLS de borde (X25519MLKEM768) es defensa *adicional* en la capa de terminación TLS; sigue dependiendo del proveedor y de los despliegues de borde de Vercel y Cloudflare. Hasta que se active TLS PQ KEM en el borde, el intercambio de llaves a nivel de transporte es TLS 1.3 con ECDHE clásico — pero el sobre interno de aplicación ya es PQ-seguro. Esto protege contra "cosecha ahora, descifra después" frente a futuros adversarios cuánticos: incluso si el TLS de una sesión capturada se rompiera en 50 años, el sobre interno ML-KEM-768 seguiría siendo FIPS 203-seguro.
Sub-procesadores
ArcaKey enruta la inferencia y las cargas de soporte a través de un conjunto pequeño de sub-procesadores nombrados. Cada entrada describe su rol estructural y su postura de cumplimiento / manejo de datos. El tráfico de los niveles Confidential AI y Private AI fluye a uno de dos backends atestados TEE — Phala para las configuraciones Qwen 3.5 27B y Qwen 2.5 7B, Tinfoil para todos los demás modelos en estos niveles. El tráfico del nivel Best in Class AI fluye directo al proveedor de frontera (Anthropic, OpenAI, o AWS Bedrock para Mistral Large 3) bajo el contrato de cada proveedor. Los sub-procesadores de plataforma e infraestructura se listan debajo.
TEE backends (Confidential AI / Private AI)
- PhalaBackend TEE — Qwen 3.5 27B + Qwen 2.5 7B
- SOC 2 Tipo I + HIPAA con alcance limitado específicamente a las configuraciones Qwen 2.5 / Qwen 3.5 en Phala — NO una certificación de Phala-como-plataforma. El rol de Phala hoy está acotado a estos dos modelos Qwen; toda otra inferencia Confidential AI / Private AI fluye por Tinfoil. Postura criptográfica: Intel TDX + NVIDIA Confidential Computing. BAA ArcaKey ↔ Phala: no solicitado; ArcaKey se apoya en la postura pública documentada de Phala en lugar de un BAA contractual.
- TinfoilBackend TEE — toda la inferencia Confidential AI / Private AI excepto los modelos Qwen de Phala
- Atestado TEE por modelo (Intel TDX + NVIDIA Confidential Computing). SOC 2 Tipo II a nivel de plataforma. Aloja el modelo Pro / Pro Suite por defecto recomendado (Llama 3.3 70B) en una ruta persistente — no scale-to-zero — eliminando la latencia de arranque en frío. BAA ArcaKey ↔ Tinfoil: no disponible — Tinfoil no proporciona BAAs a ningún cliente. La cadena de atestación TEE es la garantía sustantiva de operador-ciego para este proveedor; las afirmaciones relacionadas con SOC 2 / HIPAA provienen de la postura pública de Tinfoil en lugar de un BAA.
Platform & infrastructure
- VercelHospedaje de aplicación + borde
- SOC 2 Tipo II (públicamente verificable en Vercel Trust Center). Aloja las superficies de marketing y de aplicación del vault. Termina la conexión TLS entrante del navegador del cliente; para Tab 1 y Tab 2 el texto plano de la indicación del cliente nunca alcanza Vercel — se cifra bajo la llave por sesión dentro del navegador y se reenvía como texto cifrado.
- CloudflareCDN + DNS
- SOC 2 Tipo II, ISO 27001, FedRAMP Moderate a nivel de plataforma. Sirve activos estáticos y DNS. No ve el tráfico de inferencia.
- SupabaseBase de datos + almacenamiento de objetos
- SOC 2 Tipo II. Aloja el almacén de memoria cifrada del vault en reposo, el registro de auditoría y los datos estructurados de cuenta. Todo el contenido de blob se cifra del lado del cliente o dentro del CVM antes de escribir; Supabase ve solo texto cifrado.
- ClerkIdentidad / auth
- SOC 2 Tipo II. Maneja la autenticación; nunca toca el contenido del vault ni el tráfico de inferencia.
- UpstashSobre Redis por sesión
- SOC 2 Tipo II. Mantiene el sobre por sesión (acotado por TTL). El MEK de sesión vive solo dentro del CVM para Tab 1 / Tab 2; para sesiones Vercel-direct, el sobre queda bajo envoltura de llave de plataforma en Upstash.
- AWS (KMS)CMK del tenant para opt-in en Executive
- SOC 2 Tipo II, FIPS 140-2 Nivel 2 (KMS); FIPS 140-2 Nivel 3 disponible vía CloudHSM (activación JIT bajo requisito contractual L3). Usado para envoltura de Llave Maestra del Cliente con alcance al tenant, sobre el DEK por bloque cuando un cliente Executive opta. AWS DPA estándar + elegible para HIPAA bajo AWS BAA. El cliente controla la llave en su propia cuenta AWS; el rol IAM en tiempo de ejecución de ArcaKey recibe solo Encrypt / Decrypt.
- StripeFacturación
- SOC 2 Tipo II, PCI-DSS Nivel 1. Maneja el procesamiento de pagos solamente; nunca toca el contenido del vault ni el tráfico de inferencia.
- Brave SearchÍndice de búsqueda web (opt-in por turno)
- Índice de búsqueda contratado. Para Tab 1 y Tab 2, la consulta a Brave se realiza desde dentro del CVM atestado; el texto plano de la consulta nunca alcanza Vercel. Para Tab 3, la consulta se realiza desde el runtime de Vercel. Brave ve el texto plano de la consulta en cualquier caso — ArcaKey no afirma búsqueda cifrada extremo-a-extremo.
Frontier model providers (Best in Class AI)
- AnthropicProveedor de modelos de frontera — familia Claude
- SOC 2 Tipo II; programa BAA de proveedor disponible. BAA + ZDR ArcaKey ↔ Anthropic ambos solicitados 2026-05-24 bajo ArcaKey AI, LLC; pendiente de contrafirma. Alcanzable en Pro Suite y superiores; el acceso cubierto por HIPAA se activa una vez que ambos contratos se contrafirman.
- OpenAIProveedor de modelos de frontera — familia GPT
- SOC 2 Tipo II; programa BAA de proveedor disponible. BAA ArcaKey ↔ OpenAI activo 2026-05-24 bajo ArcaKey AI, LLC. ZDR no contratado por separado en este momento — se aplica la retención por defecto de la API de OpenAI. Alcanzable en todos los niveles de pago (con gating por modelo).
- AWS Bedrock (Mistral Large 3)Proveedor de modelos de frontera — Mistral Large 3 en us-east-2
- SOC 2 Tipo II, ISO 27001, FIPS 140-2 Nivel 2 (KMS). BAA AWS a nivel de cuenta activo 2026-05-11 bajo ArcaKey AI, LLC — el mismo paraguas BAA que cubre nuestra infraestructura KMS de CMK por tenant. Mistral Large 3 servido exclusivamente vía Bedrock; la API directa de Mistral La Plateforme (solo DPA, sin programa BAA de proveedor) no se usa. Alcanzable en Executive y superiores.
Procesamiento HIPAA / PHI — tres capas distintas
Los compradores que revisen la historia HIPAA de ArcaKey deben distinguir tres capas independientes, cada una con su propio estado hoy. La confusión común del comprador es conflarlas — "Anthropic tiene un BAA, así que mis datos están cubiertos" es una afirmación de capa 1, no una afirmación de capa 3, y la brecha entre ellas es contractual, no criptográfica.
Programas BAA a nivel de proveedor
Anthropic y OpenAI ofrecen programas BAA a nivel de proveedor (la fuente de la insignia "BAA AVAILABLE" en la superficie Tab 3). El BAA de Google Vertex AI está pendiente. Mistral no tiene programa BAA propio de proveedor, pero ArcaKey enruta Mistral exclusivamente vía AWS Bedrock bajo el BAA a nivel de cuenta AWS (activo 2026-05-11), de modo que la inferencia de Mistral lleva la misma postura elegible para HIPAA que el resto de Tab 3 — a través de un mecanismo contractual distinto. Estas son capacidades del proveedor y la infraestructura, independientes de cualquier contrato que ArcaKey haya firmado.
Ejecución del BAA ArcaKey ↔ proveedor
Si ArcaKey ha contrafirmado cada BAA aguas arriba se rastrea en una matriz viva de sub-procesador BAA; no todas las puertas están cerradas hoy. La fila JIT "procesamiento productizado cubierto por HIPAA" rastrea el cierre de las puertas residuales más la contrafirma BAA de Vercel. Alcanzable mediante el paquete de evaluación para revisores de due-diligence.
BAA ArcaKey ↔ cliente
ArcaKey no mantiene contratos directos con clientes cubiertos por HIPAA hoy. El primer compromiso firmado con un cliente que requiera procesamiento cubierto dispara el disparador JIT; hasta entonces, la postura criptográfica (Phala TEE en Tab 1, con alcance limitado a Qwen 2.5 / 3.5; ZDR + proveedores elegibles para BAA en Tab 3) existe independiente de la ejecución del BAA del lado del cliente.
Artefactos enlazados
Primitivas nombradas, arquitectura de sesión, despliegue TEE y separación explícita entre afirmaciones probadas y no probadas.
- Modelo de amenazas (v0.1)Enviado
Adversarios en alcance, adversarios fuera de alcance, supuestos de confianza, matriz de defensa en profundidad.
- Referencia de atestación TEEEnviado
Cadena de atestación, esquema del artefacto de evidencia, procedimiento de verificación sin conexión, estado de despliegue.
Arquitectura de activación de Sovereign: intercambio directo de llaves cliente ↔ enclave; servidor de aplicaciones de solo retransmisión.
Llaves públicas Ed25519 publicadas usadas para firmar artefactos de atestación. Espejo en tiempo de ejecución en /api/vault/attestation/pubkey.
- security.txtEnviado
Contacto de seguridad y política de divulgación según RFC 9116.
Verificación lista para revisión: /security-review
Atestación en vivo
Cada sesión enrutada a TEE emite un artefacto de atestación firmado que puede descargar y verificar sin conexión. La muestra a continuación se firma frescamente cada vez que la solicita — es un artefacto real, no un archivo estático.
Nota previa al lanzamiento: la capa de evidencia NRAS proviene de un stub hasta que la capacidad GCP A3 Confidential VM esté activa. La firma de enlace de ArcaKey sobre el artefacto es real y verificable hoy. La transición a NRAS en vivo es automática en el corte de capacidad — la forma del artefacto no cambia. Vea la Sección 6 de la referencia de atestación TEE.
Lista de afirmaciones defendibles
| Afirmación | Verificada por |
|---|---|
| Cifrado de extremo a extremo | Whitepaper Sección 4 |
| Cifrado poscuántico (ML-KEM-768 / ML-DSA-65) | Whitepaper Sección 3 |
| Inferencia aislada en hardware (TEE) | Referencia de atestación TEE + muestra firmada |
| Cero entrenamiento con sus datos | Modelo de amenazas Sección 3 (A4) |
| Llaves en poder del usuario (Permanent / Sovereign) | Whitepaper Sección 7 |
| Cero retención bajo demanda (Ghost Mode) | Whitepaper Sección 4 + modelo de amenazas A4 |
| ArcaKey no puede leer el contenido Sovereign (Fase 2) | Arquitectura de Fase 2 |
| Prevención de manipulación de respuesta | Whitepaper Sección 4 + modelo de amenazas A6 |
Política de divulgación
ArcaKey recibe reportes de problemas de seguridad. Nos comprometemos a:
- · Acusar recibo de un reporte dentro de 1 día hábil.
- · Proveer una evaluación de triaje dentro de 5 días hábiles.
- · No emprender acciones legales contra investigadores que actúen de buena fe, no exfiltren datos de clientes y nos den un tiempo razonable para remediar antes de la divulgación pública.
- · Acreditar públicamente a los reporteros que deseen ser nombrados en Reconocimientos.
Reporte a security@arcakey.ai. Llave PGP en /docs/arcakey-security-pgp.txt (pendiente de publicación).
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 AuditPaquete de evaluación
Las organizaciones que califican pueden solicitar el paquete de evaluación de ArcaKey — whitepaper de arquitectura, modelo de amenazas, resumen ejecutivo de pentest independiente (al completarse), plantilla de BAA HIPAA, carta de observación SOC 2, y una sesión técnica de 30 minutos con el fundador.
Reconocimientos
Aún no hay reportes publicados — esta sección listará investigadores conforme los reportes sean triados y remediados.