Cursor Agent: tres barreras prácticas antes de darle acceso a tu proyecto

Vas a pedirle a Cursor Agent que arregle una ruta de autenticación. En el mismo repositorio tienes un archivo .env, una conexión MCP y comandos capaces de modificar datos. La pregunta útil no es si el agente «es seguro» en abstracto. Es qué puede leer, qué puede ejecutar y cómo verás lo que cambió antes de desplegarlo.

Cursor ofrece controles para esos tres momentos, pero cada uno cubre un riesgo diferente. Esta guía reúne una configuración inicial para proyectos pequeños y explica sus límites según la documentación de seguridad del agente, la de archivos ignorados y la de modos de ejecución. Es una guía de configuración, no una prueba de que un proyecto concreto esté protegido.

1. Quita secretos del contexto que recibe el agente

Crea .cursorignore en la raíz del proyecto. Un punto de partida para revisar y adaptar es:

**/.env
**/.env.*
**/credentials.json
**/secrets.json
**/*.pem
**/*.key

Prueba mental: si preguntas «¿qué hay en .env.production?», el contenido no debería entrar mediante las referencias normales de Agent, Tab o @. Si necesitas compartir nombres de variables, prepara un .env.example sin valores reales; ten presente que la regla amplia **/.env.* también lo excluye del contexto. Puedes sustituirla por patrones más concretos según la estructura del repositorio.

Límite decisivo: Cursor advierte que .cursorignore no es una frontera absoluta. Un comando de terminal o una herramienta MCP todavía pueden acceder a esos archivos. Tampoco corrige secretos ya registrados en Git, enviados al chat o expuestos por otra herramienta. Si una credencial apareció en un commit, debes rotarla; ocultarla al agente no la recupera.

2. Elige cómo se aprueban las acciones

En Settings → Agents → Approvals & Execution revisa el modo activo antes de abrir una sesión con acceso a producción. Según Cursor, los comandos de terminal requieren aprobación manual de forma predeterminada; las llamadas a MCP también la requieren salvo que hayas creado excepciones o listas permitidas. Revisa precisamente esas excepciones: una configuración cómoda de otro proyecto puede ser peligrosa aquí.

Para una tarea sensible, usa un flujo en el que los comandos y las llamadas nuevas pasen por tu revisión. Lee comando, argumentos y destino antes de aceptar. No basta con ver «npm» o «curl»: un argumento puede leer .env o enviar datos fuera del equipo. Mantén credenciales de producción fuera del entorno de trabajo cuando no son necesarias para la tarea.

Cursor documenta Auto-review, que combina lista permitida, sandbox y un clasificador. Su propia documentación dice que no debe tratarse como límite de seguridad. Run Everything ejecuta sin esas revisiones. En un repositorio con secretos o conectores de escritura, no lo elijas por comodidad. Una lista permitida estricta reduce interrupciones para comandos conocidos, pero revisa cada permiso que agregas.

3. Conserva un punto de retorno y revisa el diff

Antes de delegar, deja el árbol de trabajo limpio o guarda un commit que puedas identificar. Después de que el agente termine, ejecuta:

git status --short
git diff --check
git diff --stat
git diff

Busca cambios inesperados en permisos, dependencias, scripts de instalación, variables de entorno, configuración de CI y archivos que no estaban en la petición. Ejecuta las pruebas relevantes y despliega solo después de entender el diff. Este paso ayuda a detectar modificaciones, pero no deshace una lectura o envío de datos que ya ocurrió.

Un ejercicio de cinco minutos: en una rama de prueba, crea un archivo ficticio .env.local con un valor inventado, añade la regla de ignorar y formula una pregunta inocua al agente. Luego comprueba si tus permisos de terminal o MCP permitirían leerlo de todos modos. No uses secretos reales para la prueba. Documenta el resultado y ajusta reglas y aprobaciones antes de trabajar con datos de clientes.

Qué haría hoy en un proyecto pequeño

Usaría .cursorignore para reducir exposición accidental, aprobaciones para comandos y MCP, y revisión de Git antes de fusionar o desplegar. Si Cursor necesita tocar la base de datos, le daría credenciales de prueba con alcance mínimo. Si debe usar producción, separaría ese trabajo y observaría cada operación.

El error frecuente es presentar una sola configuración como garantía. Son capas: una limita contexto, otra interrumpe acciones y la tercera permite revisar cambios. La combinación puede reducir errores, pero no sustituye los permisos mínimos de los servicios externos ni una revisión humana de acciones sensibles.

Fuentes originales: seguridad de Cursor Agent, .cursorignore, aprobaciones y modos. Consultadas el 24 de octubre de 2026. No ejecuté Cursor Agent en una cuenta del usuario ni hice una prueba de extremo a extremo; los comandos Git se presentan para que el lector los ejecute en su propio repositorio.