Realiza estas 3 comprobaciones antes de que una app en vivo de Cursor toque datos reales

Estás a punto de dejar que un agente en la nube construya una app en vivo, la apunte a una base de datos y le entregue un enlace al equipo. Eso es útil hasta que la app lleva una credencial, una regla de acceso incorrecta o un compartimiento público de datos internos. El paso de publicación es donde decides si la app es lo suficientemente segura para el trabajo real.

Cursor permite a los equipos construir apps en vivo a partir de indicaciones y compartir el enlace resultante. Sus agentes en la nube pueden crear la estructura de la app, generar una base de datos Postgres cuando sea necesario, poner la autenticación detrás de Cursor SSO y provisionar el alojamiento. La ruta de despliegue cubre repositorios nuevos o existentes en Cursor Origin y GitHub, con el soporte para GitLab aún pendiente. La velocidad es el punto; quién puede verla es el problema.

Antes de la publicación, Cursor aplica comprobaciones deterministas de reglas fijas y comprobaciones agénticas de agentes de IA a la app. Están dirigidas a secretos en archivos de la app o credenciales expuestas. La app se mantiene fuera de la publicación hasta que las comprobaciones de seguridad superan y el usuario elige publicarla. Eso es un buen valor predeterminado, no un sustituto de una puerta de publicación que tú mismo ejecutes.

El paso de publicación es donde empiezan los datos reales

Cuando publicas, seleccionas un dominio único y Cursor devuelve un enlace en vivo. Puedes compartir la app con personas específicas, grupos o todo el equipo, todo detrás del inicio de sesión de Cursor. Para Teams y Enterprise, el compartimiento público está desactivado por defecto, y un administrador del equipo puede activarlo. Ordenado es una configuración, no una prueba. Un valor predeterminado que hoy está desactivado puede estar activado mañana.

Los administradores del equipo pueden inspeccionar todas las apps y secretos, añadir reglas personalizadas de revisión de seguridad, aprobar una publicación que la revisión bloqueó y retirar cualquier app de producción. Si eres el administrador, ese es tu punto de control. Si no lo eres, construye tus comprobaciones sobre la suposición de que el administrador puede ver lo que publicaste y puede retirar la app.

Tres comprobaciones mantienen los datos reales fuera de la app

Ejecuta estas como una puerta repetible antes de que la app llegue a datos de producción. Cada una es rápida, y cada una detecta un modo de fallo diferente.

• Confirma SSO y la provisión de la base de datos. Abre la vista de despliegue o configuración de la app y verifica que el inicio de sesión está detrás de Cursor SSO y que Postgres fue provisionado para la app. Si la app necesita una base de datos, asegúrate de que es la base de datos creada por el agente para esa app, no una base de datos de desarrollo compartida que olvidaste.
• Añade una credencial falsa y confirma que la publicación se bloquea. Una comprobación fallida impide la publicación hasta que se resuelva el problema. Coloca una clave API o token falso en un archivo no sensible de la app, intenta publicar y confirma que la comprobación lo detiene. Si se publica de todos modos, la revisión no está haciendo el trabajo que necesitas que haga.
• Prueba el aislamiento de acceso de una segunda cuenta. Una app publicada puede restringirse a personas específicas, grupos o todo el equipo, con el acceso controlado por el inicio de sesión de Cursor. Inicia sesión con una segunda cuenta de Cursor que no debería tener acceso, abre el enlace en vivo y confirma que no puede acceder a los datos ni a la app.

Las comprobaciones detectan fallos diferentes: identidad y canalización de datos incorrectas, una promesa del proveedor que no coincide con tu entorno, y una regla de acceso que parece correcta en la interfaz pero falla cuando una segunda cuenta intenta entrar.

Las credenciales viven en el código hasta que demuestres lo contrario

La mayoría de los incidentes de apps en vivo son aburridos: una credencial dejada en un archivo, una cadena de conexión pegada en una configuración, o un secreto copiado en un lugar donde un revisor no miraría. Tu credencial plantada es el caso de prueba. El primer lugar donde buscar es el código de la app y su configuración, no solo el panel.

Si tu equipo usa visibilidad de código, la cuestión de las credenciales se vuelve operativa. Si tu equipo no la usa, estás tomando una decisión de criterio en lugar de ejecutar una comprobación.

Mantén las credenciales reales de la app fuera del repositorio y fuera de los archivos de la app. Trata cualquier secreto encontrado en el código como una comprobación fallida, aunque la revisión automatizada no lo haya marcado. Publica solo después de que las tres comprobaciones superen, y solo a las personas que necesitan el enlace.