Seguridad creada para mercados regulados
EthicVault está diseñado para satisfacer los requisitos regulatorios y de seguridad de la información más exigentes de los servicios financieros, no como una idea tardía, sino como el cimiento.
Cero custodia
La Friction Gate opera por completo dentro de tu frontera de despliegue. Los registros de auditoría, las reglas de política y los registros de ejecución se almacenan en tu infraestructura: EthicVault nunca tiene la custodia de tus datos.
Gobernanza con evidencia de manipulación
Cada decisión de gobernanza se firma criptográficamente en el momento de la ejecución y se encadena a la anterior, de modo que cualquier alteración posterior es detectable — ofreciendo a los reguladores evidencia verificable de la disposición alcanzada y de los controles aplicados.
Determinista por diseño
La Friction Gate usa lógica basada en reglas —no modelos de ML probabilísticos— para tomar decisiones de gobernanza. La misma entrada produce siempre la misma salida, lo que la hace auditable y explicable.
Qué está certificado, qué está diseñado y qué no es todavía ninguna de las dos cosas
Nuestro propio libro blanco sostiene que afirmado, implementado, medido, reportado, verificado de forma independiente y listo para producción son afirmaciones distintas que nunca deben confundirse. Esa regla tiene que obligarnos a nosotros primero.
“La confianza crece cuando la etiqueta de evidencia es tan precisa como la afirmación técnica.”
| Marco | Estado | Qué significa y qué no |
|---|---|---|
SOC 2 Type II AICPA | Diseñado para la auditoría | Un informe Type II exige una ventana de observación sobre un sistema en producción real. La arquitectura y el conjunto de controles están construidos para entrar en ella; la ventana se abre con el lanzamiento comercial. Hoy no tenemos ningún informe SOC 2, ni bajo NDA ni de otro modo. |
ISO 27001 ISO/IEC 27001 | Arquitectura alineada · SGSI en redacción | La arquitectura está construida sobre el conjunto de controles ISO 27001. El SGSI como marco de gestión —políticas escritas, registro de riesgos, registros— sigue en redacción y aún no está en estado auditable. No existe certificado, ningún organismo acreditado ha auditado alcance alguno, y no afirmamos tener hoy un cuerpo de políticas listo para imprimir. |
RGPD artículo 32 UE 2016/679 | Diseñado conforme a | La arquitectura está diseñada frente a las medidas técnicas y organizativas del artículo 32, y el modelo de custodia cero es la razón principal. La intención de diseño no es una determinación de cumplimiento, y ninguna autoridad ni auditor la ha evaluado. |
DORA UE 2022/2554 | Diseñado para | Construido para las obligaciones de gestión del riesgo TIC que asumen las entidades financieras bajo DORA, incluida la evidencia que debe producir una respuesta del artículo 11. DORA obliga a las entidades financieras, no a nosotros. Podemos aportar evidencia para su obligación; no podemos cumplirla en su lugar. |
Si alguna línea de arriba cambia, cambia aquí primero y con las mismas palabras. Ningún estado se elevará en esta página antes de que exista el artefacto que lo respalde.
No hacemos teatro de cumplimiento
Un informe SOC 2 Type II o una prueba de penetración contra un sistema que aún no está en producción real sería un documento, no evidencia. Todo nuestro argumento es que afirmado, implementado y verificado de forma independiente son palabras distintas. No vamos a romper esa regla para decorar esta página. La arquitectura está preparada para esas auditorías; empiezan cuando el sistema lleve tráfico real.
Artefactos que pedirá cualquier revisión de seguridad
Listados existan ya o no, porque la ausencia de uno es en sí misma algo que un revisor necesita saber pronto y no tarde.
| Artefacto | Estado |
|---|---|
| Política de divulgación responsable Publicada en /.well-known/security.txt con dirección de contacto e idioma preferido. | Disponible |
Acuerdo de tratamiento de datos (DPA) Se emite por cada contrato una vez definido el alcance del tratamiento. No es un documento permanente. | A petición |
Acuerdo de nivel de servicio (SLA) Definido por el modelo de despliegue y las obligaciones de aseguramiento. Véase cómo fijamos el precio. | Por contrato |
Lista de subencargados El motor lee, evalúa, firma y después permite o bloquea. La carga útil del cliente y los datos personales nunca se conservan; lo que retiene la cadena WORM son pruebas criptográficas y disposiciones. La lista es por tanto mínima por arquitectura, y se publica íntegra, con notificación de cambios, antes de tratar dato alguno de cliente. | Custodia cero de carga útil por diseño |
Enfoque del SGSI La capa administrativa —RR. HH., gestión de dispositivos, revisiones de acceso estándar— se gestiona con una plataforma de automatización de cumplimiento, por cobertura. Los controles del motor —la frontera de autorización, la custodia cero de carga útil, la ruta de decisión determinista— se redactan a mano, porque las plantillas de cumplimiento en la nube listas para usar suponen un sistema que almacena datos de cliente y no encajan en una arquitectura construida para no hacerlo. | Híbrido — automatizado + redactado a mano |
Resumen de prueba de penetración Una prueba contra un entorno de preproducción demuestra poco. Se ejecuta contra producción en la disponibilidad general, y el resumen y su alcance se publican aquí. | Programada para la GA |
Página de estado pública Una página de estado informa sobre un servicio en producción bajo SLA. Se publica junto con el primero. | En la GA |
Lo que se sostiene hoy y lo que está diseñado para la GA
Son propiedades del motor tal como está, demostrables ahora mismo; tres de ellas en el propio demostrador.
Frontera de decisión determinista
- Ningún modelo probabilístico se sitúa en la ruta de decisión de liberación
- La misma solicitud acotada, estado de política y conjunto de evidencia producen la misma disposición
- Cada disposición lleva los códigos de motivo frente a los que puede verificarse
Custodia cero de carga útil
- La carga útil del cliente y los datos personales nunca se conservan
- La cadena WORM solo retiene pruebas criptográficas y disposiciones, no contenido
- Los datos del cliente nunca se usan para entrenar ni ajustar un modelo
Cadena de auditoría a prueba de manipulaciones
- Registro de decisiones encadenado por hash, de solo anexado
- Cada registro vincula un hash de certificado SHA-256 al hash de política bajo el que se decidió
- Reejecutar una decisión reproduce un certificado idéntico bit a bit
Los controles de plataforma de abajo están diseñados y estarán activos cuando el sistema lleve tráfico de producción. Se listan como arquitectura objetivo, no como controles operando hoy. SOC 2, la prueba de penetración y el SLA figuran en el estado de aseguramiento de arriba, no se repiten aquí.
Transporte y almacenamiento
- TLS 1.3 en tránsito, impuesto sin degradación
- AES-256 en reposo en las capas de almacenamiento
- Gestión de claves aislada por inquilino, con BYOK
Acceso e identidad
- SSO mediante SAML 2.0 y OIDC para cuentas empresariales
- MFA por hardware para el acceso privilegiado
- Control de acceso basado en roles con mínimo privilegio
Resiliencia y operación
- Despliegue multirregión con conmutación por error automática
- Exportación regulatoria lista para el examinador
- Integración SIEM vía webhook o syslog
Ningún dato abandona tu entorno sin tu autorización explícita.
La Friction Gate opera por completo dentro de tu frontera de despliegue. Los registros de auditoría, las reglas de política y los registros de ejecución se almacenan en tu infraestructura: EthicVault nunca tiene la custodia de tus datos.
Nuestra propia puerta falló cuatro de cuatro, y esto es lo que cambiamos.
Publicado porque una política de divulgación sin un registro detrás te pide aceptar la postura por fe. Este es el resultado negativo más importante de nuestra evidencia de prototipo, en las palabras del propio informe.
- Lo que supusimos
Que el comportamiento dañino llegaría siempre a través de un nombre de herramienta ya registrado como restringido. La puerta clasificaba por nombre y denegaba lo que figuraba en la lista.
- Lo que ocurrió4 / 4
Cuatro acciones dañinas cuyos efectos no estaban representados en el registro de herramientas restringidas superaron la puerta en todos los casos probados. El informe lo consigna como un fallo real del prototipo y afirma con claridad que la clasificación por nombre de herramienta no basta como frontera de control de ejecución.
- Lo que cambió
Lista de permitidos con denegación por defecto, control de salida basado en el efecto y liberación ligada a la autoridad: la postura que el informe llama Phi-Invariant. La disposición se vincula a argumentos canonizados, objetivo, autoridad, prueba y versión de política, no a una etiqueta.
- En regresión0 / 4
Los mismos cuatro casos se reejecutaron contra la nueva postura. Ninguno pasó.
La pregunta que ahora hace la puerta
No «¿está este nombre de herramienta en una lista de denegación?», sino «¿está explícitamente permitido este efecto exacto, su objetivo, su autoridad, su estado de prueba y su ruta de liberación?». El agente que propone no clasifica su propia acción como segura.
Alcance, tal como lo declara el informe: evidencia de regresión para cuatro casos repetidos, no resistencia universal a exploits. La prevención de efectos dañinos desconocidos o de día cero figura como no respaldada. Las variantes de ataque redactadas de forma independiente, los canales encubiertos y el modelado adversario de trazas siguen sin probarse.
Divulgación responsable
Si crees haber descubierto una vulnerabilidad de seguridad en los sistemas de EthicVault, divúlgala de forma responsable. Nos comprometemos a acusar recibo de los informes válidos en 48 horas y a resolver los problemas críticos en 14 días.
Informar de una vulnerabilidad