El lugar más seguro para su trabajo es el ordenador en el que ya está.

1. Nuestro enfoque

Dos principios rigen todo lo que viene a continuación. Primero, local primero de forma predeterminada: en el runtime local, la inferencia, la memoria y los archivos del agente se ejecutan en tu propio equipo, con modelos que alojas tú. La excepción son las herramientas de pago que decidas ejecutar - investigación web y en X, generación de imagen y vídeo, acciones de conectores - que necesitan claves de proveedor gestionadas que custodiamos nosotros, así 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 runtime 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. Menos datos de nuestro lado es menos que proteger y menos que se pueda llegar a exponer.

No decimos que seamos inexpugnables. Lo que sí podemos decir es que la arquitectura está construida para que tu trabajo más sensible nunca tenga que salir de un hardware que tú controlas.

2. Dónde viven tus datos

Convira tiene tres runtimes, y se diferencian exactamente en esto:

En la vía de la nube, el contenido de la ejecución - el texto que has escrito, los archivos implicados, las entradas y salidas de las herramientas y las respuestas del modelo - no se escribe en nuestras bases de datos. Nuestro código lo elimina antes de que se persista nada, y hay pruebas automatizadas que verifican esa 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, tableros, archivos compartidos y nombres de canal de un equipo los guardamos nosotros. Hay otro tipo de contenido que puede vivir ahí: si activas la sincronización opcional en la nube de habilidades y conocimiento del proyecto, ese texto se almacena de nuestro lado como filas normales de base de datos, como describe la sección de cifrado de más abajo.

Se guardan como texto cifrado que no podemos abrir. Las claves de contenido se crean en los dispositivos de los miembros y se envuelven para el dispositivo de cada compañero; ningún servidor de Convira tiene una clave que abra un mensaje, una actualización de tablero, el nombre de un canal o un adjunto. 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é canal, un número de secuencia, una época, un tipo de contenido, un tamaño, un hash, qué cuenta lo subió y cuándo. Otras tres cosas se guardan en claro porque las funciones que las usan no podrían funcionar de otro modo: qué dos cuentas están en un mensaje directo, que un miembro 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.

Tres límites, dichos en vez de sobreentendidos. Borrar un mensaje quita nuestra copia y las copias en los dispositivos de tus compañeros de equipo; lo que no alcanza es una copia que ya salió de la aplicación: una exportación o una captura de pantalla. Un mensaje directo registra qué dos cuentas están en él - lo guardamos en claro para poder entregarlo, y nada de lo que se dijo. Y en el formato de clave actual un dispositivo acepta una rotación de clave hacia adelante bajo nuestra palabra: si eso llegara a pasar, la aplicación levanta una alerta de confianza y deja de tratar la identidad como verificada, en lugar de aceptar la clave nueva en silencio.

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

Las llamadas a herramientas del escritorio siempre se comprueban con la política de permisos de Convira. El aislamiento nativo de procesos es una capa independiente de defensa en profundidad, que se aplica siempre que el sistema anfitrión lo proporciona. Estas son las primitivas que utiliza:

• Linux: una jaula 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 del equipo 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 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.

Comprobamos la mayor parte de esto en su máquina, y decimos cuál es la parte que no. La primera vez que una herramienta necesita un proceso aislado, Convira ejecuta los controles de recursos en su máquina real: un shell devuelve los límites que heredó, se mata un grupo de procesos de verdad y el hijo en segundo plano que había lanzado debe morir con él, y en Linux una reserva mayor que el tope debe fallar mientras que una menor bajo un tope generoso lo consigue; un control cuya comprobación no pasa se reporta como ausente durante el resto de esa sesión. El aislamiento de archivos y de red solo se comprueba así en Windows, lanzando contra él un proceso confinado de verdad; en macOS y Linux esos dos se dan por la presencia del propio entorno aislado del sistema operativo en lugar de ejercitarse. Cuando una herramienta necesita un aislamiento que el equipo no puede dar, la herramienta se retira en lugar de ejecutarse sin él: el código escrito por el modelo se rechaza de plano en lugar de ejecutarse sin confinar. La excepción es una lista corta de utilidades auxiliares que Convira invoca por su cuenta y que el modelo no puede escribir - git, extracción de archivos comprimidos, OCR -, que conservan una vía de compatibilidad más estrecha si el entorno aislado de denegación por defecto no se carga en su máquina.

Código abierto. La capa de confinamiento descrita arriba está publicada bajo Apache 2.0 como convira-sandbox: los perfiles Seatbelt de macOS, los argumentos de espacios de nombres y montajes de bubblewrap en Linux, el código de AppContainer y Job Object de Windows, y las comprobaciones que deciden si un control se informa como aplicado. Publicar el código no demuestra que la versión que instaló lo contenga; lo que le da es la capacidad de leer qué hacen esas comprobaciones, ejecutar el conjunto de pruebas usted mismo y observar en su propio equipo si se comporta así.

La ejecución de código en la nube tiene otro límite: se ejecuta dentro de un entorno aislado por 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 ID 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 confinar. Los resultados de las herramientas 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, después lo que hayas aprobado durante la sesión, después los dominios permitidos por tu plan y 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 link-local, y los endpoints de metadatos de la nube. En el runtime local, el acceso web usa por defecto el nivel restringido y puedes desactivarlo por completo, y el proxy puede funcionar en modo auditoría (registrarlo todo) o en modo aplicación (bloquear y, si quieres, preguntarte).

Hay dos cosas que no pasan por él, y preferimos nombrarlas antes que dejar que el párrafo anterior las dé por cubiertas. Git a través de la red - clonar, hacer fetch, hacer pull, hacer push, abrir un pull request - y la instalación de las dependencias de tu proyecto ejecutan sus propias herramientas, que se conectan directamente: sin proxy y sin lista de dominios permitidos. 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. Convira solo inicia sesión en github.com, pero git en sí acepta cualquier dirección https a la que se le apunte, así que un repositorio que no hayas leído puede nombrar un host que nosotros no comprobamos. Hacer push y abrir un pull request te preguntan antes de ejecutarse.

Cuando activas e invocas una herramienta de pago de web, medios o conectores, esa única llamada se enruta a Convira para ejecutarse con claves gestionadas; todo lo demás permanece en tu equipo y, sin conexión, las herramientas de pago sencillamente 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 preguntan siempre. Tus reglas de permisos se crean en tu dispositivo y se aplican a la ejecución; en la vía de la nube se envían 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 específicas para cada propósito derivadas de una clave maestra mediante HKDF-SHA256, con posibilidad de rotar esa clave. El texto extraído de las habilidades y del conocimiento del proyecto que decides sincronizar para la búsqueda en la nube se almacena como filas normales 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. Las contraseñas nunca se almacenan ni se cifran de forma reversible - se procesan con Argon2id (un algoritmo moderno de alto consumo de memoria). Los tokens de sesión, los códigos de verificación por correo, los tokens de restablecimiento de contraseña y otros secretos similares se guardan solo como hashes, son de un solo uso cuando procede y caducan. Las claves de API de los proveedores de modelos externos se custodian en el entorno de nuestro servidor, no en la base de datos.

En tu dispositivo. La aplicación de escritorio guarda la copia de referencia de tus ejecuciones y sesiones en una base de datos SQLite local cifrada con SQLCipher. La propia clave de cifrado está protegida por el almacenamiento seguro de tu sistema operativo (Keychain en macOS, DPAPI en Windows, libsecret en Linux); una compilación empaquetada se niega a arrancar si esa protección no está disponible, en lugar de recurrir a texto plano. La aplicación de escritorio no guarda claves de 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 los ajustes de los servidores MCP que conectes - se almacenan cifradas bajo la misma protección del sistema operativo.

Private Box. Un Private Box autoalojado se licencia con tokens de corta duración firmados con Ed25519. Durante la vinculación única, el box envía su credencial bearer a Convira por TLS; Convira la sella en memoria con la clave de tu dispositivo (acuerdo de claves X25519 + XChaCha20-Poly1305) y almacena solo el texto cifrado. Cuando añades miembros al equipo, tu propia aplicación de escritorio vuelve a sellar esa credencial con la clave de dispositivo de cada miembro, así que esas entregas nunca exponen el texto plano a Convira.

Si tu modelo de amenazas exige que el contenido de las ejecuciones permanezca en hardware que tú controlas, usa el runtime local o un Private Box y no invoques herramientas online gestionadas.

5. Autenticación y acceso

Las sesiones están respaldadas por 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 caducan. Los inicios de sesión fallidos tienen límite de frecuencia. La aplicación de escritorio se autentica con tokens sin conexión de corta duración firmados asimétricamente (Ed25519) que incluyen protecciones antirretroceso, de modo que atrasar el reloj no puede prolongarlos. La falsificación de peticiones entre sitios se bloquea con un token de doble envío más una comprobación de origen, comparados en tiempo constante.

El acceso a los datos de los clientes dentro de Convira está delimitado por roles. Nuestro 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, lector) que acotan lo que pueden hacer allí. Cada acción privilegiada del personal se escribe en un registro de auditoría de solo anexado, con el actor, el objetivo, el motivo y la fuente. La suplantación por parte de soporte, cuando es necesaria, queda restringida al rol de personal más alto, exige escribir una confirmación y un motivo por escrito, tiene un límite de tiempo y queda registrada en la auditoría. Los atajos de autenticación exclusivos de desarrollo están desactivados de forma irrevocable en las compilaciones de producción.

6. Refuerzo de la aplicación

Web. La API y el sitio web envían cabeceras estándar de refuerzo - 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 peticiones de origen cruzado desde una lista explícita de orígenes propios. Los formularios públicos están protegidos con Cloudflare Turnstile y campos trampa, y tienen límite de frecuencia.

Escritorio. La aplicación 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 aplicación únicamente a través de un puente de precarga muy limitado cuyos mensajes se validan contra un esquema, y funciona bajo una Content-Security-Policy estricta (default-src 'self', sin plugins, sin marcos y con Trusted Types para los scripts). Las solicitudes de permisos del contenido web se deniegan, salvo una breve lista 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 aplicación de escritorio verifica la firma de cada actualización antes de instalarla, de modo que una actualización manipulada se rechaza. Las comprobaciones de actualización respetan la política de red: si un runtime está configurado como sin conexión, la aplicación no contacta con el servidor de actualizaciones.

8. Supervisión y respuesta ante incidentes

Usamos herramientas de monitorización de errores en la API y en el panel web, configuradas para excluir cabeceras 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 se produce una brecha de datos personales, lo notificaremos a los usuarios afectados y a las autoridades competentes en los plazos que exige la ley.

9. Proveedores de servicios

Convira se apoya en un pequeño conjunto de proveedores verificados - pagos (Stripe), alojamiento de la API (Railway), base de datos (Supabase), protección frente a bots (Cloudflare), alojamiento del sitio web y analítica sin cookies (Vercel), monitorización de errores (Sentry) y los proveedores de modelos de IA (Anthropic, OpenAI, Google, xAI). La lista completa actual - incluida la infraestructura de búsqueda, correo, colas y conectores -, qué hace cada uno y dónde opera aproximadamente está en nuestra página de subencargados del tratamiento.

10. Tu parte

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

• Usa una contraseña segura y única para tu cuenta de Convira.
• Mantén la aplicación actualizada - se actualiza sola, pero no te quedes con una versión de hace meses.
• Actúa con criterio sobre lo que conectas y los permisos que concedes al agente; lee las solicitudes de aprobación.
• Para el trabajo más sensible, utiliza el runtime local o un Private Box y mantén desactivadas las herramientas en línea gestionadas para que el contenido de las ejecuciones permanezca en hardware que tú controlas.
• Si algo te parece raro - un fallo, un correo sospechoso que dice ser nuestro, una cuenta que no reconoces - dínoslo.

11. Informar de una vulnerabilidad

Si crees que has encontrado una vulnerabilidad de seguridad en Convira, comunícanoslo en security@convira.ai. Incluye los detalles suficientes para reproducirla - componente o URL afectados, pasos e impacto - y, si puedes, una prueba de concepto.

Lo que te pedimos:

• Danos un plazo razonable para investigar y solucionar el problema antes de divulgarlo públicamente.
• No accedas a datos que no sean tuyos, ni los modifiques o elimines; usa únicamente cuentas y datos de prueba que controles.
• No lances ataques que degraden el servicio para los demás (denegación de servicio, spam, fuerza bruta contra cuentas reales) ni utilices ingeniería social contra nuestro personal o nuestros usuarios.
• No exijas un pago a cambio de no divulgar la información.

Lo que puedes esperar de nosotros:

• Acusaremos recibo de tu informe y te mantendremos al tanto mientras trabajamos en él.
• Si lo deseas, te daremos crédito público cuando el problema esté resuelto. Actualmente no tenemos un programa remunerado de recompensas por errores.
• 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 sobre seguridad o 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 modificaremos la fecha que figura arriba.