Iniciar sesión Obtenga gratis para siempre Empezar

Seguridad

Matemáticas, no política.

La mayoría de los gestores de contraseñas dicen "nunca leeremos sus datos". La arquitectura de Clavitor significa que no podemos. Su huella dactilar, rostro o clave de seguridad derivan claves de cifrado que nunca existen en ningún servidor. Nosotros guardamos la caja fuerte. Solo usted tiene la clave.

Tres elementos hacen que esto funcione.

01 — Campo

Cifrado por campo

Cada campo tiene su propio nivel de cifrado. Su clave de API es legible por el agente que la necesita; su tarjeta de crédito en la misma entrada no lo es. Mismo registro, acceso diferente.

02 — Hardware

Claves derivadas de hardware

Sus campos más sensibles se cifran con una clave derivada de su dispositivo: huella dactilar, rostro o clave de seguridad. La clave se calcula en su navegador. Nunca sale del dispositivo.

03 — Distancia

Fuera de alcance

La bóveda se ejecuta en una infraestructura separada que su agente de IA no puede tocar. Las credenciales se liberan a través de una API estrecha, con alcance limitado por agente. Nada en su portátil. Nada en su archivo .env.

Tier 1 — Vault encryption

Todo está cifrado en reposo.

Every record in your vault — every field, every entry, every byte — is encrypted at rest with AES-256-GCM. The encryption key is 8 bytes, derived from a 32-byte master secret that was randomly generated when your vault was created. That master secret is never stored on disk. It exists only inside a WL3 file, wrapped with the output of your hardware key.

Si alguien roba el archivo de la bóveda —una copia de seguridad robada, un host comprometido, un administrador de sistemas hostil— obtiene texto cifrado. Títulos de entrada, nombres de usuario, contraseñas, tarjetas, notas: todo cifrado. La clave de 8 bytes es lo suficientemente fuerte como para que el ataque de fuerza bruta sea computacionalmente impracticable, e incluso entonces, los campos internos se cifran de nuevo en niveles superiores.

Esta es la base. Todos los gestores de contraseñas cifran en reposo. Lo que importa es lo que sucede por encima de esta línea.

Tier 2 — Credential encryption

Sus agentes pueden leer credenciales. Nada más.

Por encima de la capa de la bóveda, cada campo de credenciales —claves de API, contraseñas, semillas TOTP, tokens OAuth, claves SSH— se cifra individualmente con su propia clave derivada. La clave de cifrado tiene 16 bytes de entropía completa. Computacionalmente irrompible.

Sus agentes de IA reciben esta clave para que puedan hacer su trabajo. Eso es por diseño: un agente que implementa su código necesita su clave SSH. Pero la clave viene con cuatro capas de defensa que controlan lo que sucede con ella:

Tokens con alcance limitado. Cada agente recibe un token que otorga acceso a entradas específicas. Su agente de implementación ve su clave SSH y sus credenciales de AWS. No ve su clave de Stripe, su contraseña de correo electrónico ni las entradas de su colega. No puede enumerar, navegar, buscar ni descubrir credenciales fuera de su alcance. Obtiene lo que se le ha asignado y no puede encontrar lo que no tiene.

Distancia. Su bóveda no está en su portátil. Se ejecuta en una infraestructura separada que su agente no puede tocar. El agente interactúa a través de una API estrecha que sirve o deniega; no hay sistema de archivos que leer, ni memoria de procesos que inspeccionar, ni caché local que saquear. Si la bóveda viviera en la misma máquina que el agente, una habilidad comprometida podría infiltrarse en el sistema y extraer lo que quisiera. La distancia elimina esa opción por completo.

Limitación de velocidad. Un agente que accede a más de tres credenciales únicas por minuto, o diez por hora, se limita. Una segunda infracción en dos horas activa un bloqueo total: el agente se congela y requiere su clave de hardware para desbloquearse. Un agente normal necesita dos o tres credenciales. Un agente que lee diez está mal configurado o comprometido. En cualquier caso, se detiene.

Lista blanca de IP. Cada token de agente se vincula a una IP de origen en el primer contacto. Un token robado utilizado desde una IP diferente es rechazado en la capa intermedia antes de que se ejecute cualquier manejador. El atacante tiene la clave pero no puede usarla desde ningún lugar excepto desde la máquina para la que se emitió.

El resultado: el radio de explosión de un agente comprometido se limita a su alcance, desde su IP, a una velocidad que activa el bloqueo antes de que pueda ocurrir una exfiltración significativa. Sus otros agentes, sus otras credenciales y sus campos de identidad no se ven afectados.

Tier 3 — Identity encryption

Sus datos más sensibles se cifran con su dispositivo. No podemos leerlos.

Tarjetas de crédito, CVV, números de pasaporte, SSN, códigos de recuperación, notas privadas, claves de firma: estos son campos de identidad. Se cifran con una clave de 32 bytes que se generó aleatoriamente cuando se creó su bóveda. Usted no conoce esta clave. Nosotros no la tenemos. Nunca ha existido en ningún servidor.

The key lives inside a WL3 file, wrapped with the 32-byte output of your hardware key's PRF extension (WebAuthn PRF). To unwrap it, you need the physical device — your fingerprint reader, your face sensor, or your YubiKey. The unwrapping happens in your browser. The plaintext key exists in browser memory for the duration of one operation, then it's gone.

Ningún agente recibe esta clave. Ningún punto final de API la sirve. Ningún proceso del lado del servidor puede derivarla. Los campos de identidad son texto cifrado en cada servidor, en cada copia de seguridad, en cada destino de replicación, en cada momento. Una brecha en nuestra infraestructura —total, completa, cada byte exfiltrado— produce texto cifrado para cada campo de identidad en todas las bóvedas. La clave de descifrado no está en los datos exfiltrados. No puede estarlo, porque nunca estuvo allí.

No podemos descifrar sus campos de identidad. No podemos ser obligados a producir una clave que no tenemos. Esto no es una promesa de política. Es una propiedad matemática del sistema.

Nadie más que usted tiene acceso

Y no hay contraseña maestra.

No hay nada que olvidar, nada que pescar, nada que descifrar en una brecha. Su dispositivo —huella dactilar, rostro o clave de seguridad— es la única vía de entrada. Cada conexión es TLS 1.3 con cifrados modernos y HSTS. Las credenciales se liberan a tokens de agente con alcance limitado a través de puntos finales de API estrechos, nunca registrados. Incluso nuestro soporte de IA no puede ver sus credenciales: el mismo cifrado que oculta sus secretos de nosotros los oculta también de nuestras herramientas de soporte.

Modelo de amenazas

Contra qué nos defendemos.

Cada plataforma de credenciales se enfrenta a la misma superficie de ataque. Así es como Clavitor está diseñado contra cada una.

AmenazaCómo nos defendemosResultado
Phishing de credencialesLos usuarios no conocen sus contraseñas (aleatorias de 32 bytes, nunca mostradas). La extensión solo se rellena en coincidencia de URL. El usuario no puede escribir lo que no sabe.Estructuralmente bloqueado
Phishing de OTP / 2FATOTP reside en la bóveda, con alcance limitado al dominio real. Dominio incorrecto — sin código. Misma defensa que la contraseña.Estructuralmente bloqueado
Brecha del servidorLos campos de identidad se cifran con claves derivadas de hardware que nunca poseemos. Los campos de credenciales se rotan automáticamente; el texto plano filtrado caduca en cuestión de horas.Daño limitado
Agente de IA comprometidoCada agente tiene un token con alcance limitado. El compromiso expone solo el alcance del agente, no su bóveda completa.Radio de explosión limitado
Malware en el punto finalLa bóveda es remota, no local. Los tokens de sesión tienen tiempo limitado. Los desafíos WebAuthn están vinculados al origen; el malware no puede firmar por el usuario.Mitigado
Ataque internoLos campos de identidad son matemáticamente inaccesibles para nosotros. No podríamos producir texto plano bajo citación judicial.Fuera de nuestro alcance

Confíe en la plataforma, no solo en la criptografía.

El cifrado es solo una de las tres garantías. Las otras dos se refieren a lo que sucede cuando algo falla — el servicio, o su propio acceso a él.

Resiliencia — el servicio sigue funcionando

Preguntamos qué sucede cuando falla cada capa — nube, DNS, registrador, correo electrónico, nuestro propio software. La arquitectura está diseñada para que la respuesta sea siempre la misma: la bóveda sigue funcionando. La lista honesta de amenazas →

Recuperación — usted permanece dentro

Pierda su clave de hardware y aún así podrá acceder — a través de un código de conocimiento dividido de su lado, un ancla de recuperación del nuestro y una llamada de Zoom con material de verificación que usted eligió. Sin restablecimiento por correo electrónico, sin SMS, sin preguntas de seguridad. Cómo funciona la recuperación →

Lea las inmersiones profundas.

Para la audiencia técnica: detalles criptográficos, análisis de modelos de amenazas y una invitación abierta a encontrar lo que nos hemos perdido.