Matemáticas, no política.

Tres cosas hacen que esto funcione.

Nivel 1 — Cifrado de la bóveda

Todo está cifrado en reposo.

Cada registro en su bóveda —cada campo, cada entrada, cada byte— está cifrado en reposo con AES-256-GCM. La clave de cifrado tiene 8 bytes, derivada de un secreto maestro de 32 bytes que se generó aleatoriamente cuando se creó su bóveda. Ese secreto maestro nunca se almacena en disco. Solo existe dentro de un archivo WL3, envuelto con la salida de su clave de hardware.

Si alguien roba el archivo de la bóveda —una copia de seguridad robada, un host comprometido, un administrador de sistemas hostil— obtienen 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 forzarla sea computacionalmente impráctico, e incluso entonces, los campos interiores se cifran de nuevo en niveles superiores.

Esta es la línea base. Cada gestor de contraseñas cifra en reposo. Lo que importa es lo que sucede por encima de esta línea.

Nivel 2 — Cifrado de credenciales

Sus agentes pueden leer credenciales. Nada más.

Por encima de la capa de la bóveda, cada campo de credencial —claves 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 ámbito. 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 ámbito. Obtiene lo que se le ha nombrado 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 para leer, ni memoria de procesos para inspeccionar, ni caché local para 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 se rechaza 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 ámbito, 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.

Nivel 3 — Cifrado de identidad

Sus datos más sensibles se cifran con su dispositivo. Nosotros 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.

La clave vive dentro de un archivo WL3, envuelta con la salida de 32 bytes de la extensión PRF de su clave de hardware (WebAuthn PRF). Para desenvolverla, necesita el dispositivo físico: su lector de huellas dactilares, su sensor facial o su YubiKey. El desenrollado ocurre en su navegador. La clave en texto plano existe en la memoria del navegador durante la duración de una operación, luego desaparece.

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 de 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 se nos puede obligar 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 (phishing), nada que descifrar en una brecha. Su dispositivo —huella dactilar, rostro o llave 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 ámbito a través de puntos finales de API estrechos, nunca se registran. Incluso nuestro soporte de IA no puede ver sus credenciales: el mismo cifrado que oculta sus secretos de nosotros, también los oculta 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 de ellas.

Amenaza	Cómo nos defendemos	Resultado
Phishing de credenciales	Los usuarios no conocen sus contraseñas (32 bytes aleatorios, nunca mostrados). La extensión solo se rellena con coincidencia de URL. El usuario no puede escribir lo que no sabe.	positivo: Bloqueado estructuralmente
Phishing de OTP / 2FA	TOTP vive en la bóveda, con ámbito al dominio real. Dominio incorrecto — sin código. Misma defensa que la contraseña.	positivo: Bloqueado estructuralmente
Brecha del servidor	Los 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.	negativo: Daño limitado
Agente de IA comprometido	Cada agente tiene un token con ámbito. El compromiso expone solo el ámbito del agente, no su bóveda completa.	positivo: Radio de explosión limitado
Malware en punto final	La bóveda está remota, no local. Los tokens de sesión tienen tiempo limitado. Los desafíos de WebAuthn están vinculados al origen: el malware no puede firmar por el usuario.	advertencia: Mitigado
Ataque interno	Los campos de identidad son matemáticamente inaccesibles para nosotros. No podríamos producir texto plano bajo citación judicial.	positivo: 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.