Resumen de seguridad
Esta página explica cómo se crean y protegen los agentes en la nube. Describe qué ocurre cuando se ejecuta un agente, cómo se concede el acceso, dónde se alojan el código y los datos, cómo se aíslan y cifran, y qué controles tienes sobre cada etapa. Responde a las preguntas que surgen cuando un equipo evalúa los agentes en la nube frente a sus requisitos de seguridad.
Para consultar la referencia de configuración, incluidos los tipos de secretos, los modos de acceso de red y los rangos de IP de egreso, consulta Secretos y red. Para federar una VM en AWS, GCP, Azure o un verificador personalizado sin claves de larga duración, consulta tokens de OIDC. Esta página explica el modelo detrás de esos controles; esas páginas te indican cómo configurarlos.
Este contenido complementa la documentación general de seguridad de Cursor. Consulta el Trust Center para ver certificaciones, subprocesadores y arquitectura, y la referencia de Refuerzo de seguridad y privacidad para conocer los controles que administras en todo Cursor. Cursor cumple con SOC 2 Type 2 y se compromete a realizar pruebas de penetración al menos una vez al año por parte de terceros de confianza.
Cómo funcionan los agentes en la nube
Un agente en la nube es un agente de programación que se ejecuta en una máquina virtual en la nube de Cursor, en lugar de hacerlo en la portátil de un desarrollador. La VM contiene un entorno de desarrollo completo: el repositorio clonado, las dependencias instaladas, los secretos configurados y el acceso de red.
Una sola ejecución pasa por estas etapas:
- Inicio. Un usuario o una integración inicia una tarea desde la aplicación web, el IDE, la CLI, la API, Slack o desde un problema o pull request vinculado.
- Aprovisionamiento. Cursor aprovisiona una VM aislada para ese agente y clona en ella el repositorio autorizado.
- Ejecución. El agente ejecuta código y herramientas dentro de la VM, y transmite al usuario su progreso, salida y artefactos.
- Persistencia. El estado de la conversación, los metadatos y los artefactos se guardan en un almacenamiento gestionado por Cursor para que puedas revisar y reanudar la ejecución.
- Transferencia. El agente envía su rama y abre un pull request en borrador para que una persona lo revise antes de fusionar nada.
- Reciclaje. Los recursos de ejecución de la VM se hibernan y luego se eliminan según los temporizadores del ciclo de vida cuando la ejecución queda inactiva.
Acceso y autorización
Los agentes en la nube acceden a tu código a través de la app de GitHub o GitLab de Cursor, no mediante las credenciales de una sola persona.
- Los Admins instalan la app. Habilitar los agentes en la nube requiere privilegios de admin tanto en Cursor como en tu proveedor de Git. Un admin instala la app de Cursor en tu organización de Git y concede acceso solo a los repositorios que elijas.
- Los usuarios conectan su propia cuenta. Una vez instalada la app, cada usuario que quiera iniciar un agente de programación conecta su propia cuenta de Git. Esta es una segunda capa por usuario, además de la instalación a nivel de organización.
- El acceso se hereda; nunca se amplía. Un agente en la nube solo puede acceder a los repositorios a los que el usuario que lo activa ya tenía acceso. Iniciar un agente nunca concede acceso a un repositorio al que el usuario no tuviera acceso previamente.
Los administradores de equipo pueden ir un paso más allá y restringir una organización de Git a tu organización de Cursor con Ámbitos de Git protegidos, para que solo tus equipos puedan iniciar agentes en la nube en sus repositorios. También puedes excluir por completo los repositorios sensibles con una lista de bloqueo de repositorios.
Los empleados de Cursor no tienen acceso al código dentro de las VMs de los agentes en la nube. Los intentos de acceso son supervisados por el equipo de seguridad de Cursor.
Aislamiento e infraestructura
Cada agente se ejecuta dentro de los límites de su propia VM, no en un sandbox de procesos compartido. Un agente no puede ver el código, el entorno ni el estado de otro agente.
- VM por agente. Cada agente obtiene un entorno dedicado, aislado de otros agentes y de otros usuarios.
- Aislamiento con microVM. Los espacios de trabajo del entorno de ejecución se ejecutan sobre infraestructura de microVM basada en Firecracker.
- Separación a nivel de cuenta. Las VM de los agentes en la nube se ejecutan en una cuenta de AWS separada del resto de la infraestructura de producción de Cursor, por lo que el entorno de ejecución de código queda aislado de los demás servicios de Cursor.
Cifrado
Cursor cifra los datos del agente en la nube en tránsito y en reposo.
- En tránsito. TLS 1.2 o superior para el tráfico entre servicios y entre el cliente y el servicio.
- En reposo. AES-256, con claves por agente para que los datos de sesión de cada agente se cifren con su propia clave.
- Claves gestionadas por el cliente. Los equipos Enterprise pueden asociar una clave de KMS gestionada por el cliente (CMEK/BYOK) al cifrado del lado del servidor del agente en la nube, para controlar la rotación de claves y el acceso. Consulta Cifrado de datos.
Qué datos se almacenan, dónde y durante cuánto tiempo
Un agente en la nube utiliza cuatro tipos de datos. Cada uno se almacena en un lugar distinto y sigue su propia regla de retención.
| Datos | Qué contiene | Dónde reside | Retención |
|---|---|---|---|
| Espacio de trabajo en tiempo de ejecución | El repositorio descargado, los artefactos de compilación y el contexto de ejecución de herramientas de una ejecución activa | La VM aislada del agente en la nube | Se recicla automáticamente cuando la ejecución queda inactiva; el temporizador se reinicia cuando envías instrucciones de seguimiento |
| Instantáneas de VM | Copias puntuales del disco de la VM (incluido el código clonado) usadas para iniciar y reanudar sin volver a clonar | Capa de instantáneas y caché fuera de la VM activa, cifrada | 90 días de inactividad continuada; cada inicio o reanudación amplía ese plazo y luego se eliminan automáticamente |
| Estado de la conversación | Instrucciones, respuestas del modelo, llamadas a herramientas, contexto de diff y artefactos de demostración que componen la transcripción | Backend de Cursor, cifrado con claves por agente | Se conserva indefinidamente de forma predeterminada para que puedas volver a consultar y reanudar ejecuciones; se puede eliminar a petición |
| Secretos y tokens | Secretos del agente en la nube, tokens de OAuth y credenciales de API que configuras | Almacenes de credenciales cifrados en el backend de Cursor | Se conservan hasta que los elimines o los retires |
La Delete Agent API elimina a petición la transcripción de la conversación y los artefactos de un agente. Las instantáneas no se pueden eliminar a petición; siguen la ventana de inactividad de 90 días indicada arriba. Los equipos Enterprise también pueden limitar la retención de conversaciones con políticas de retención. Para obtener toda la información sobre retención y eliminación, consulta Retención de datos.
Privacidad y datos del modelo
Los agentes en la nube se ejecutan en modo de privacidad. Con el modo de privacidad activado, Cursor nunca entrena con el código al que acceden los agentes en la nube ni con las instrucciones y respuestas que generan en sus ejecuciones. La mayoría de los modelos también se ejecutan bajo los acuerdos de cero retención de datos de Cursor, por lo que los proveedores no almacenan las solicitudes y respuestas ni entrenan con ellas. Consulta Privacidad y gobernanza de datos para ver los detalles de cada modelo y las excepciones.
El modo de privacidad heredado no es compatible con los agentes en la nube, porque los agentes necesitan almacenar código y datos del entorno en la nube mientras se ejecutan. Aplica el modo de privacidad estándar en toda la organización para que cada ejecución herede sus garantías de cero retención de datos.
Autonomía e inyección de prompts
Los agentes en la nube ejecutan automáticamente comandos de terminal para poder iterar sobre las pruebas sin detenerse a pedir aprobación en cada paso. Esto es más autónomo que el agente en primer plano y cambia el modelo de riesgo: un atacante que inserte instrucciones en el contenido que lee el agente (un ataque de inyección de prompts) podría intentar hacer que el agente extraiga código hacia un host externo. Consulta la explicación de OpenAI sobre el riesgo de inyección de prompts para agentes en la nube.
Las capas que mitigan este riesgo:
- Control de egreso de red. Restringe el tráfico saliente a un conjunto predeterminado más tu lista de permitidos, o solo a tu lista de permitidos, para que un agente comprometido no tenga adónde enviar datos. Los administradores de Enterprise pueden bloquear la política en toda la organización. Consulta Acceso de red.
- Secretos de tiempo de ejecución ocultos. Marca los secretos como Secretos de tiempo de ejecución para que sus valores se eliminen de la transcripción, la salida de las herramientas y los commits, y nunca lleguen al modelo.
- Exclusión de archivos. Agrega rutas sensibles a
.cursorignorepara mantenerlas fuera del contexto del agente. - Transferencia con supervisión humana. Los agentes abren pull requests en borrador. No se fusiona nada hasta que una persona revise el cambio.
- Commits firmados. Cada commit del agente se firma con una clave Ed25519 respaldada por HSM y muestra una insignia "Verified", para que los cambios creados por el agente sean atribuibles y puedan cumplir con la protección de rama para commits firmados. Consulta Commits firmados.
Para una defensa más profunda, combina esto con hooks para aplicar políticas y registrar actividad en puntos del ciclo de vida del agente, y haz que Bugbot o agentes de seguridad revisen la salida del agente antes de que llegue a producción.
Consideraciones sobre riesgos
| Riesgo | Mitigación |
|---|---|
| Toda la base de código en la nube | VMs aisladas por agente, cifrado AES-256 y eliminación automática de VM e instantáneas según temporizadores del ciclo de vida. |
| Acceso de terceros o de personal interno | Ningún empleado de Cursor puede acceder al código en las VMs de los agentes; los intentos de acceso se supervisan. Las VMs se ejecutan en una cuenta de AWS independiente de otros servicios de Cursor. |
| Autonomía del agente | Limitada al repositorio y al acceso del usuario que lo activa. El acceso externo se limita a herramientas configuradas y comandos de terminal, con control de egreso de red y revisión mediante PR en borrador. |
| Acceso de red y exfiltración | El acceso a Internet está habilitado de forma predeterminada, pero puede restringirse a dominios de la lista de permitidos, limitarse exclusivamente a esa lista y bloquearse para toda la organización. |
| Exposición de secretos | Almacenamiento cifrado de secretos, secretos de tiempo de ejecución redactados que se mantienen fuera del modelo, secretos solo para creación limitados al build de Docker y tokens de OIDC para federación en la nube de corta duración. |
Auditabilidad
La actividad del agente en la nube queda registrada y puede atribuirse.
- Registro de sesiones. Las ejecuciones quedan registradas, y los administradores de equipo pueden revisar la actividad desde el Panel de control del agente en la nube.
- Cambios atribuidos. Cada commit y pull request que crea un agente se atribuye y es visible en tu historial de Git, con commits firmados y verificados.
- Registros de auditoría. Los eventos de autenticación y administración se envían a tus registros de auditoría, que los equipos Enterprise pueden redirigir a un SIEM, webhook o S3.
- Ejecutar diagnósticos. El Cursor Cloud MCP integrado ofrece acceso a las transcripciones, los eventos de ejecución, los detalles del entorno y los registros de configuración de una ejecución.
Eliminación de datos
| Mecanismo | Qué elimina | Cómo |
|---|---|---|
| Archivar | Oculta un agente del panel de control | Archivar desde el panel de control |
| Delete Agent API | La transcripción de la conversación de un agente y sus artefactos | Delete Agent API |
| Caducidad de instantáneas | Instantáneas de VM y código en caché | Automático tras 90 días de inactividad |
| Política de retención (Enterprise) | Conversaciones anteriores al período que elijas | Políticas de retención |
| Eliminación de la cuenta | La cuenta y sus datos asociados | Eliminar cuenta |
Preguntas frecuentes
Tienen un perfil de riesgo distinto, no peor. Ejecutar un agente sin supervisión en un entorno aislado, con restricciones de salida y permisos mínimos, puede ser más seguro que el portátil de un desarrollador, que normalmente tiene acceso completo a internet y privilegios elevados.
No. Cursor clona el repositorio para ejecutar el agente, y ese clon puede permanecer en instantáneas de VM para acelerar futuros inicios, pero no se conserva indefinidamente. Las instantáneas se eliminan tras 90 días de inactividad.
No. El acceso depende del acceso a Git del desarrollador que lo activa. Un agente en la nube no puede acceder a un repositorio al que el desarrollador no tuviera acceso previamente.
Sí. Los agentes en la nube solo pueden acceder a los repositorios que autorices mediante la conexión con tu proveedor de Git. Tú controlas qué repositorios están disponibles, y los admins pueden bloquear ámbitos con Ámbitos de Git protegidos o excluir repositorios con una lista de bloqueo.
Configura los secretos desde la pestaña Secrets de tu panel de control. Se cifran en reposo con KMS, se cifran en tránsito y se inyectan como variables de entorno en tiempo de ejecución. Marca los valores sensibles como Secretos de tiempo de ejecución para mantenerlos fuera de la transcripción, la salida de herramientas y los commits. Como práctica general, mantén los secretos fuera del repositorio; si es necesario guardar archivos sensibles allí, añádelos a .cursorignore. Para los roles en la nube, genera tokens de OIDC desde la VM en lugar de almacenar claves de acceso de larga duración.
Sí. Las sesiones quedan registradas, los admins pueden revisar la actividad desde el panel de control, y cada commit y pull request que crea un agente queda atribuido en tu historial de Git. Los equipos Enterprise pueden enviar registros de auditoría a un SIEM.
Archiva un agente desde el panel de control o usa la Delete Agent API para eliminar su transcripción y artefactos. La eliminación completa de la cuenta y las políticas de retención de Enterprise eliminan datos con un alcance más amplio.
Páginas relacionadas
- Secretos y red para tipos de secretos, modos de acceso de red, rangos de IP de egreso y commits firmados.
- Tokens de OIDC para JWT de corta duración y federación en la nube.
- Privacidad y gobernanza de datos para flujos de datos, modo de privacidad y cifrado.
- Refuerzo de seguridad y privacidad para los controles que configuras en Cursor.
- Trust Center para certificaciones, subprocesadores y arquitectura.
