El lugar más seguro para tu trabajo es la computadora en la que ya está.

1. Nuestro enfoque

Dos principios rigen todo lo que sigue. Primero, local primero de forma predeterminada: en el entorno de ejecución local, la inferencia, la memoria y los archivos del agente se ejecutan en tu propia máquina, con modelos que tú alojas. La excepción es una herramienta facturada que elijas ejecutar - investigación web y en X, generación de imagen y video, acciones de conectores - que necesita claves de proveedor gestionadas que nosotros tenemos, por lo que esa única llamada a la herramienta la ejecuta Convira y se devuelve a tu dispositivo (y solo mientras estés en línea). Segundo, la nube es opcional y mínima: cuando usas el entorno de ejecución en la nube, tu ejecución se procesa y se reenvía al proveedor del modelo de IA, pero el contenido de la ejecución no se almacena en nuestros servidores - el registro vive en tu dispositivo. La única excepción es un intercambio que decides compartir al calificar una respuesta, que conservamos hasta 90 días, o hasta que quites la calificación. Menos datos de nuestro lado es menos que proteger y menos que pueda quedar expuesto.

El resultado es una arquitectura pensada para que tu trabajo más sensible nunca tenga que salir del hardware que tú controlas.

2. Dónde viven tus datos

Convira tiene tres entornos de ejecución, y se diferencian exactamente en esto:

En la ruta de nube, el contenido de la ejecución - el texto que escribiste, los archivos involucrados, las entradas y los resultados de las herramientas, y las respuestas del modelo - no se escribe en nuestras bases de datos. Nuestro código lo elimina antes de que algo se guarde, y pruebas automatizadas verifican ese invariante en cada compilación. El detalle está en la Política de Privacidad.

Team Hub

Team Hub no es un cuarto entorno de ejecución - no ejecuta ningún agente ni produce un registro de ejecución -, pero es donde vive en nuestros servidores el contenido compartido de un equipo, así que va junto a la tabla y no dentro de ella. Los mensajes, anuncios, archivos compartidos y nombres de conversación de un equipo los guardamos nosotros. Otro tipo de contenido puede vivir ahí: si activas la sincronización opcional en la nube para skills y conocimiento del proyecto, ese texto se almacena de nuestro lado como filas comunes de base de datos, como describe la sección de cifrado más abajo.

Se guardan como texto cifrado que no podemos abrir. Las claves provienen del grupo MLS propio de cada ámbito (RFC 9420, la implementación OpenMLS, con un conjunto de cifrado resistente a computadoras cuánticas): cada dispositivo miembro tiene una hoja en ese grupo y de ahí deriva el secreto de época, y ningún servidor de Convira tiene una hoja ni una clave que abra un mensaje, un anuncio, el nombre de una conversación o un adjunto. Si un espacio de trabajo ha registrado una frase de recuperación, el lector que esa frase deriva también es miembro del grupo compartido. La búsqueda se ejecuta en tu dispositivo, porque el nuestro no podría hacerla por ti.

Lo que nuestros servidores sí ven es lo que la entrega necesita: qué espacio de trabajo y qué conversación, un número de secuencia, una época, un tipo de contenido, un tamaño, un hash, qué cuenta lo subió y cuándo. Otras cuatro cosas se guardan en claro porque las funciones que las usan no podrían funcionar de otro modo: qué cuentas están en un mensaje directo o en un grupo, quiénes de ellas administran ese grupo, que un integrante identificado reaccionó a un mensaje identificado - nunca con qué emoji - y quién confirmó haber leído un anuncio que pedía confirmación, y cuándo.

Borrar un mensaje quita nuestra copia y las copias en los dispositivos de tus compañeros, en todos los lugares donde la app las guarda. Una computadora nueva solo se une a un espacio de trabajo cuando se aprueba: una de las propias computadoras de esa persona firma por ella o, si perdió todas sus computadoras, la aprueba alguien que tenga las 24 palabras de recuperación del espacio de trabajo, o bien el propietario o un administrador del espacio, y se avisa a todos los miembros del espacio de trabajo.

3. Cómo se aísla la ejecución del agente

La política de permisos de Convira revisa cada llamada a herramientas en el escritorio. El aislamiento nativo de procesos agrega por debajo una segunda capa de defensa independiente. Las primitivas que utiliza son:

• Linux: un confinamiento de espacios de nombres con bubblewrap. La herramienta recibe una raíz de sistema de archivos nueva que contiene solo los directorios que se le concedieron, más las rutas de sistema de solo lectura que necesita para arrancar; cualquier otra cosa no es simplemente ilegible, es que no está. Obtiene su propio espacio de nombres de identificadores de proceso y, si se ejecuta sin acceso a la red, su propio espacio de nombres de red cuyo único dispositivo es loopback, así que no hay ninguna ruta fuera de la computadora en la que abrir un socket.
• macOS: un perfil de Seatbelt (sandbox-exec) con una postura de denegación por defecto.
• Windows: un AppContainer nuevo en cada arranque, creado sin SID de capacidad, lo que deniega por defecto la red saliente y también el sistema de archivos, ya que un directorio que no se le concedió a la herramienta no tiene ninguna entrada para la identidad de ese contenedor. Un Job Object sobre el mismo proceso limita memoria, procesos y CPU.

Verificado en tu propia computadora. La primera vez que una herramienta necesita un sandbox, Convira verifica en tu computadora que el sandbox del sistema operativo esté disponible y pone sus límites de recursos a prueba con una ejecución real. El código que escribe la IA solo se ejecuta dentro de ese sandbox: si el sandbox no puede iniciarse, el código se rechaza en lugar de ejecutarse sin él. Cada acción registra el aislamiento con el que se ejecutó realmente, y la app te lo muestra.

Código abierto. La capa de aislamiento descrita arriba está publicada con licencia Apache 2.0 como convira-sandbox - los perfiles Seatbelt de macOS, los argumentos de namespace y montaje de bubblewrap en Linux, el código de AppContainer y Job Object en Windows y las verificaciones que deciden si un control se reporta como aplicado. Puedes leer exactamente qué hacen esas verificaciones, ejecutar tú mismo el conjunto de pruebas y ver que tu propia máquina se comporta como describe esta página.

La ejecución de código en la nube tiene un límite distinto: se ejecuta dentro de un entorno aislado de espacios de nombres con bubblewrap, dentro del contenedor del worker de la API - con su propia raíz de sistema de archivos, su propio espacio de nombres de identificadores de proceso y su propio espacio de nombres de red. Si ese entorno aislado no está disponible en el host, la herramienta se niega a ejecutarse en lugar de recurrir a un proceso sin confinamiento. Los resultados de la herramienta exponen la procedencia del aislamiento para que el agente y la interfaz puedan ver bajo qué aislamiento se ejecutó realmente cada llamada.

Salida de red. La mayor parte del acceso de red saliente de una ejecución pasa por un proxy HTTP CONNECT que aplica una lista de dominios permitidos por capas (una lista de denegación explícita, luego lo que hayas aprobado durante la sesión, luego los dominios permitidos de tu plan y de tu espacio de trabajo, y por último una pequeña base integrada de endpoints de modelos y paquetes). También bloquea las conexiones directas a IP, los rangos privados y de enlace local, y los endpoints de metadatos de la nube. En el entorno de ejecución local, el acceso a la web usa de forma predeterminada el nivel restringido, el Modo Sin Conexión corta la red por completo, y el proxy puede funcionar en modo auditoría (registrar todo) o en modo aplicación (bloquear y, si quieres, preguntarte).

Git a través de la red (clonar, hacer fetch, pull y push y abrir pull requests) y la instalación de las dependencias de tu proyecto usan sus propias herramientas, que se conectan directamente en lugar de pasar por el proxy. Se rigen por el Modo Sin Conexión y no por el interruptor de Acceso web, porque hacer push a tu propio repositorio no es navegar, y hacer push o abrir una pull request siempre te pide confirmación antes.

Cuando habilitas e invocas una herramienta facturada de web, medios o conectores, esa única llamada se enruta a Convira para ejecutarse con claves gestionadas; todo lo demás permanece en tu máquina y, sin conexión, las herramientas facturadas simplemente no están disponibles.

Aprobaciones. Un motor de políticas clasifica lo que está a punto de hacer cada acción de herramienta. Las acciones sensibles no ocurren sin más - la ejecución se pausa y genera una solicitud que tienes que aprobar o rechazar antes de continuar. En algunas acciones puedes elegir “permitir en esta sesión” o “permitir siempre”; otras siempre preguntan. Tus reglas de permisos se crean en tu dispositivo y se aplican a la ejecución; en la ruta de nube se envían junto con la ejecución, no se almacenan de nuestro lado.

4. Cifrado

En tránsito. Todo el tráfico entre las aplicaciones y nuestra API viaja por TLS, y nuestra API se conecta a su base de datos por TLS.

En reposo. Nuestra base de datos está cifrada en reposo. Además, ciertos valores sensibles almacenados - por ejemplo, las credenciales y la configuración de las integraciones que conectas - se cifran a nivel de aplicación con AES-256-GCM, usando claves por propósito derivadas de una clave maestra con HKDF-SHA256 y con soporte para rotar esa clave. El texto extraído de las skills y del conocimiento del proyecto que eliges sincronizar para la búsqueda en la nube se almacena como filas comunes de base de datos para que la recuperación pueda leerlo - cubierto por el cifrado en reposo de la base de datos, no por esa capa adicional. No hay contraseñas de cuenta, así que no hay ningún hash de contraseña que guardar. Los tokens de sesión, los códigos de un solo uso que te enviamos por correo y otros secretos similares se guardan solo como hashes, son de un solo uso cuando corresponde y expiran. Una passkey solo nos deja su clave pública, y una clave pública no puede firmar nada. Las claves API de proveedores de modelos externos se mantienen en el entorno de nuestro servidor, no en la base de datos.

En tu dispositivo. La app de escritorio guarda la copia de referencia de tus ejecuciones y sesiones en una base de datos SQLite local cifrada con SQLCipher. La clave de cifrado está protegida por el almacenamiento seguro de tu sistema operativo (Keychain en macOS, DPAPI en Windows, libsecret en Linux); una versión empaquetada se niega a iniciar si esa protección no está disponible, en lugar de recurrir a texto plano. La app de escritorio no guarda claves API de proveedores de modelos. Las credenciales de terceros que sí conserva - tu token de inicio de sesión de GitHub, y los tokens de inicio de sesión y la configuración de los servidores MCP que conectas - se guardan cifradas bajo la misma protección del sistema operativo.

Private Box. Una Private Box autoalojada se licencia con tokens Ed25519 firmados y de vida corta. La credencial de transporte de la caja nunca llega a Convira en una forma que Convira pueda leer: el instalador imprime un código de transferencia en la consola de la propia caja, y alguien que gestione la configuración del espacio de trabajo lo escribe en Convira en una máquina que ya ha fijado esa caja. Cuando añades miembros, un escritorio que gestione la configuración sella para cada miembro una clave propia contra la clave de dispositivo de ese miembro (acuerdo de claves X25519 + XChaCha20-Poly1305) y Convira solo transmite y almacena ese texto cifrado; el sobre de una segunda persona con administración de configuración contiene la propia credencial de transporte, sellada igual, porque solo ella puede volver a sellar para las demás. Convira no tiene ninguna clave que abra ninguno de ellos. Lo que Convira sí guarda en claro es la dirección de la caja y sus huellas TLS, para que el dispositivo de un compañero pueda comprobar que se conecta a la máquina correcta.

Si tu modelo de amenaza exige que el contenido de las ejecuciones se quede en hardware que tú controlas, usa el entorno de ejecución local o una Private Box, no invoques herramientas en línea gestionadas y no armes ninguna tarea para que se ejecute con la computadora apagada: una tarea armada es el único caso en el que los propios servidores de Convira montan la instrucción y lo envían a tu caja.

5. Autenticación y acceso

Las sesiones se respaldan en el servidor: el token de la cookie de tu navegador se compara con un hash almacenado, la cookie es HttpOnly, Secure en producción y SameSite=Lax, y las sesiones expiran. Los inicios de sesión fallidos tienen límite de frecuencia. La app de escritorio se autentica con tokens sin conexión de corta duración firmados asimétricamente (Ed25519) que incluyen protecciones anti-retroceso, para que un reloj atrasado no pueda extenderlos. La falsificación de solicitudes entre sitios se bloquea con un token de doble envío más una verificación de origen, comparados en tiempo constante.

Puedes agregar una passkey a tu cuenta: tu huella digital, tu rostro o una llave física, guardada por el dispositivo que tienes delante. Te inicia sesión sin esperar ningún código y es la prueba más fuerte que acepta la cuenta, así que también responde a la confirmación extra que pedimos antes de un cambio sensible. Convira almacena solo la clave pública de la passkey, que por sí sola no puede firmar nada. Tu huella digital y tu rostro nunca salen de tu dispositivo: nunca se nos envían y nunca los guardamos.

El acceso a los datos de los clientes dentro de Convira está delimitado por roles. El personal tiene roles de plataforma (independientes de cualquier cuenta de cliente) que determinan qué puede ver y hacer; dentro de un espacio de trabajo, los miembros tienen roles (propietario, administrador, operador, visualizador) que limitan lo que pueden hacer allí. Cada acción privilegiada del personal queda escrita en un registro de auditoría de solo adición, con el actor, el objetivo, el motivo y la fuente. La suplantación de identidad para soporte, cuando es necesaria, está restringida al rol de personal más alto, requiere que se escriba una confirmación y un motivo, tiene tiempo limitado y queda registrada en la auditoría. Los atajos de autenticación exclusivos de desarrollo están deshabilitados por completo en las compilaciones de producción.

6. Fortalecimiento de la aplicación

Web. La API y el sitio web envían encabezados estándar de fortalecimiento - HSTS (con preload en el sitio de marketing), una Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, una Referrer-Policy restrictiva y una Permissions-Policy que desactiva la cámara, el micrófono y la geolocalización. La API solo acepta solicitudes de origen cruzado desde una lista explícita de nuestros propios orígenes. Los formularios públicos están protegidos con Cloudflare Turnstile y campos honeypot, y tienen límite de frecuencia.

Escritorio. La app de Electron ejecuta la interfaz con el aislamiento de contexto activado, la integración de Node desactivada y el sandbox del renderizador habilitado. El renderizador se comunica con el resto de la app solo a través de un puente preload reducido cuyos mensajes se validan por esquema, y funciona bajo una Content-Security-Policy estricta (default-src 'self', sin plugins, sin framing, Trusted Types para los scripts). Las solicitudes de permisos del contenido web se deniegan, salvo una lista breve de excepciones.

7. Compilaciones y actualizaciones firmadas

Los instaladores para macOS y Windows están firmados digitalmente - notarización de Apple en macOS, Authenticode en Windows - y el actualizador automático de la app de escritorio verifica la firma de cada actualización antes de instalarla, de modo que una actualización alterada se rechaza. Las comprobaciones de actualización respetan la política de red: si un entorno de ejecución está configurado sin conexión, la app no contacta al servidor de actualizaciones.

8. Monitoreo y respuesta a incidentes

Usamos herramientas de monitoreo de errores en la API y en el panel web, configuradas para excluir encabezados de autenticación, cookies y valores que parezcan contraseñas, tokens o secretos. Los webhooks entrantes (por ejemplo, de Stripe) se verifican por firma y se deduplican para rechazar reenvíos. Investigamos las señales de seguridad y, si ocurre una violación de datos personales, notificaremos a los usuarios afectados y a las autoridades competentes dentro de los plazos que exige la ley.

9. Proveedores de servicios

Convira se apoya en un grupo reducido de proveedores de servicios verificados - pagos (Stripe), hosting de la API, la base de datos, el almacenamiento de archivos y las colas de tareas (Amazon Web Services, en Fráncfort), protección contra bots (Cloudflare), hosting del sitio web y analítica sin cookies (Vercel), monitoreo de errores (Sentry) y los proveedores de modelos de IA (Anthropic, OpenAI, Google, xAI, Meta). La lista actual completa, incluida la infraestructura de búsqueda, correo y conectores, con lo que hace cada uno y dónde opera, está en nuestra página de subencargados del tratamiento.

10. Tu parte

La seguridad es cosa de todos. Algunas cosas que importan:

• Agrega una passkey y mantén el bloqueo activado en el dispositivo que la guarda.
• Mantén la app actualizada - se actualiza sola, pero no te quedes con una versión de hace meses.
• Piensa bien qué conectas y qué permisos le das al agente; lee las solicitudes de aprobación.
• Para tu trabajo más sensible, usa el entorno de ejecución local o una Private Box, mantén apagadas las herramientas en línea gestionadas y lanza esas ejecuciones tú mismo en lugar de armarlas, para que el contenido de las ejecuciones se quede en hardware que tú controlas.
• Si algo se ve mal - una falla, un correo sospechoso que dice ser nuestro, una cuenta que no reconoces - avísanos.

11. Reportar una vulnerabilidad

Si crees que encontraste una vulnerabilidad de seguridad en Convira, repórtala a security@convira.ai. Incluye suficiente detalle para reproducirla - el componente o la URL afectados, los pasos y el impacto - y, si puedes, una prueba de concepto.

Lo que te pedimos:

• Danos un plazo razonable para investigar y corregir el problema antes de divulgarlo públicamente.
• No accedas, modifiques ni elimines datos que no sean tuyos; usa solo cuentas y datos de prueba que tú controles.
• No ejecutes ataques que degraden el servicio para otras personas (denegación de servicio, spam, fuerza bruta contra cuentas reales) ni uses ingeniería social contra nuestro equipo o nuestros usuarios.
• No exijas pagos a cambio de no divulgar la información.

Lo que puedes esperar de nosotros:

• Confirmaremos la recepción de tu reporte y te mantendremos al tanto mientras trabajamos en él.
• Cuando el problema esté corregido, con gusto te daremos el crédito si así lo deseas.
• No emprenderemos acciones legales contra la investigación de buena fe que siga estas pautas.

Nuestra política de divulgación de vulnerabilidades completa establece el alcance, los tiempos de respuesta a los que nos comprometemos y las condiciones de puerto seguro para la investigación de buena fe.

12. Preguntas

Preguntas de seguridad, o cualquier tema sobre esta página: security@convira.ai. Para todo lo demás, nuestra página de ayuda. Actualizaremos esta página a medida que cambien el producto y nuestras prácticas, y ajustaremos la fecha de la parte superior.