Cursor anunció el 5 de noviembre de 2026 que sus agentes de nube pueden construir y publicar aplicaciones accesibles mediante un enlace. La función está disponible en planes de pago que tengan habilitados esos agentes. Para un equipo, la novedad acerca la creación de una herramienta interna a su puesta en uso; sigue haciendo falta decidir quién puede abrirla y qué datos maneja.
Qué pone Cursor y qué debe pedir el usuario
El anuncio de Apps describe un flujo que prepara la aplicación, una base de datos Postgres si hace falta, autenticación mediante el inicio de sesión de Cursor y alojamiento. Se puede partir de repositorios nuevos o existentes en Cursor Origin y GitHub. El soporte para otros proveedores, como GitLab, se presenta como futuro.
Hay que encargar explícitamente una aplicación a un agente de nube: esta función no se ejecuta con el agente local. Después se previsualiza y se elige una URL al publicar. La documentación de Apps deja la decisión de publicación en manos del usuario: generar el proyecto no lo hace público automáticamente.
El cambio complementa lo que contamos sobre Agent SDK. Allí el foco era definir un agente mantenible como proyecto de software; aquí es construir y compartir una aplicación web. Conviene distinguir qué producto se está evaluando antes de trasladar requisitos o condiciones de uno a otro.
Compartir exige una decisión de permisos
Las apps privadas y de equipo utilizan el inicio de sesión de Cursor. En planes individuales también existe publicación pública. La documentación añade que en Teams y Enterprise compartir públicamente está desactivado por defecto y un administrador puede habilitarlo.
Nuestra recomendación es elegir primero el público real de la herramienta. Una URL cómoda para enseñar un prototipo puede convertirse en una vía de acceso a información interna si se publica con una visibilidad inadecuada. Revisar el contenido y revisar quién lo puede consultar son dos comprobaciones distintas.
La revisión previa ayuda, pero la responsabilidad continúa
Cursor documenta controles para secretos incrustados y archivos de credenciales, junto a la exclusión de archivos .env y mapas del código fuente. Añade una revisión con IA; los administradores pueden configurar reglas y despublicar aplicaciones. Estos mecanismos no acreditan que todas las operaciones de una app respeten las reglas del negocio.
Ejemplo hipotético, no ejecutado por Puntoes: un equipo pide un tablero de incidencias con registros sintéticos y lo comparte con un grupo pequeño. Antes de conectar información real, comprobaríamos el acceso desde otra cuenta y qué acciones permite cada pantalla. También revisaríamos si un usuario autorizado puede ver registros que pertenecen a otra persona. Son criterios propuestos, no resultados de una prueba del producto.
Qué confirmar antes de depender de una app
La disponibilidad en un plan de pago no permite deducir aquí un presupuesto completo. Antes de adoptar la herramienta, confirmaríamos condiciones de alojamiento, costes, tratamiento de datos y cómo retirar el acceso o trasladar el proyecto. La propia documentación describe el alojamiento con condiciones específicas y sin una garantía universal sobre las apps creadas.
No hemos desplegado una aplicación ni medido su fiabilidad. La oportunidad es reducir los pasos para compartir una herramienta; decidir sus permisos, comprobar su lógica y mantenerla sigue siendo trabajo del equipo. Las fuentes se consultaron el 6 de noviembre.