Seguridad y gobernanza

VAULTE · Last updated 22 July 2026

Lo que protege tus datos y limita lo que el sistema puede hacer en tu nombre. Esta página describe controles que están implementados. Donde algo aún no existe, lo dice.

Aislamiento de inquilinos

Cada registro lleva la organización a la que pertenece, y cada consulta se limita a ella. La seguridad a nivel de fila está activada en las tablas gobernadas y el acceso se concede solo al rol de servicio — los roles de base de datos anónimos y de usuario final no tienen ruta de lectura a los datos del cliente.

Los recursos de correo están además limitados al propietario: el acceso exige que el usuario autenticado sea propietario del recurso. Pertenecer a la misma organización, un rol de administrador o conocer un identificador de mensaje son, cada uno por sí solo, insuficientes. Esto se verifica con una suite de aislamiento que ejecuta doce intentos de acceso hostiles contra el esquema real.

Autenticación

• Inicio de sesión mediante enlace mágico enviado por correo, con tokens de sesión firmados.
• Se admite el registro y la autenticación con passkey.
• Las sesiones están vinculadas a un dispositivo y pueden revocarse.
• Las rutas protegidas fallan de forma cerrada — una petición no autenticada se rechaza o redirige, nunca se sirve parcialmente.

Autorización

Los roles determinan qué superficies y acciones están disponibles. Las funciones de política y aprobación a nivel de fundador están separadas de las funciones del inquilino cliente, y ningún proceso de agente tiene acceso ilimitado simultáneo a correo, pagos, despliegue y secretos.

Secretos

Las credenciales de integración se almacenan mediante cifrado de sobre (AES-256-GCM) vinculado a la organización propietaria, de modo que un texto cifrado movido entre inquilinos no se descifrará. Los secretos se guardan solo en el servidor y se redactan de cualquier contenido pasado a un modelo de lenguaje.

Pagos

• Los pagos los procesa Stripe. Los datos de la tarjeta nunca llegan a nuestros sistemas.
• Las firmas de los webhooks se verifican; una petición sin firmar o mal firmada se rechaza.
• Los eventos de modo prueba y modo real están aislados — un evento de prueba no puede activar una cuenta real y viceversa.
• Una cuenta de pago se aprovisiona solo a partir de un evento de webhook verificado, nunca desde un navegador que regresa con un parámetro de éxito.
• Los eventos de webhook repetidos no pueden registrar el mismo pago dos veces.

Límites a la acción autónoma

Los límites se aplican en el código de la aplicación, no por instrucción a un modelo de lenguaje. Cada acción prevista se registra con su decisión de política antes de que ocurra la llamada externa, de modo que lo que se permitió es verificable después sin volver a ejecutar nada.

Algunas acciones se rechazan de plano y no pueden autorizarse mediante la cola de aprobación del producto:

• contactar a un destinatario después de que se haya dado de baja;
• garantizar un resultado comercial;
• enviar sin una justificación respaldada por evidencia;
• iniciar la ejecución antes de verificar el pago;
• enviar desde un buzón que no ha pasado las comprobaciones de configuración;
• actuar sobre contenido identificado como un intento de inyección de prompt.

Otras acciones — transacciones por encima de tu límite, descuentos por encima de tu tope, alcance a medida, cambios de contrato, cuestiones legales o de seguridad — se ponen en cola para tu decisión con la evidencia adjunta.

Contenido no confiable

Las respuestas, los sitios web, los documentos y los datos de proveedores se tratan como entrada adversaria. El contenido se despoja de credenciales, se analiza en busca de patrones de inyección de instrucciones y se acota para que un modelo lo reciba como datos a analizar en lugar de instrucciones a seguir. La inyección sospechada se pone en cuarentena y se rechaza.

Paradas de emergencia

Una parada global detiene toda operación autónoma de inmediato. Las paradas acotadas detienen un buzón, campaña, mercado, oferta, cliente, flujo o integración mientras todo lo demás continúa. Las paradas son datos, no despliegues — surten efecto en la siguiente acción, y el sistema también puede activarlas sobre sí mismo cuando señales de entregabilidad, disputa, calidad o duplicación cruzan un umbral.

Historial de auditoría

Las acciones gobernadas se registran con actor, acción, objetivo y metadatos. Las decisiones de aprobación, los cambios de política y las paradas son atribuibles y tienen marca de tiempo.

Gestión de incidentes

Los fallos se clasifican por gravedad. Los incidentes de seguridad y sistémicos detienen los sistemas afectados, se escalan de inmediato y no se reanudan por el propio criterio del sistema. Un incidente no se cierra porque se desplegara una corrección — el cierre exige que el flujo afectado tenga éxito, que las regresiones pasen y que la monitorización confirme la estabilidad, con esa evidencia registrada.

Cuando un problema te afecte, te diremos qué está afectado y proporcionaremos una solución alternativa si existe. No te diremos que está resuelto hasta que la validación haya pasado realmente.

Exportación y eliminación de datos

Puedes exportar tus datos en cualquier momento. Tras la cancelación puedes solicitar su eliminación; confirmaremos cuando esté completa. Los registros que estamos legalmente obligados a conservar (por ejemplo, registros de transacciones) se guardan durante el periodo requerido y no más.

Lo que no afirmamos

No poseemos ninguna certificación de seguridad de terceros. No estamos certificados en SOC 2, ISO 27001 ni HIPAA, y no afirmamos estarlo. No ofrecemos una garantía contractual de disponibilidad a los precios actuales. Si tu compra exige una certificación que no tenemos, dínoslo antes de comprar.

Reportar una vulnerabilidad

Escribe a hello@vaultehq.com con «Security» en el asunto. Danos un plazo razonable para investigar antes de cualquier divulgación pública. Acusaremos recibo y te diremos qué encontramos.