AIREITERUn worker puede estar detrás de tu firewall y aun así enviar fragmentos de código fuente, salidas de terminal, diffs y capturas de pantalla a Cursor. Cursor Self-Hosted Machines ofrece ejecución autogestionada, no un agente autogestionado ni una implementación de Cursor aislada de Internet.
Esta revisión analiza qué cruza ese límite y qué cambian realmente los controles, a partir del anuncio del 2 de septiembre de 2026 de Cursor, la documentación de Self-Hosted Machines y la política de uso de datos.
El límite de datos, resumido en una tabla
Cursor divide cada ejecución de Cloud Agent entre su nube y un worker que tú administras. «Self-hosted» describe dónde se ejecuta el trabajo, no todos los sistemas ni todas las rutas por las que circulan los datos.
| Dato o sistema | Dónde se ejecuta o permanece | ¿Puede llegar a Cursor? | Control o límite relevante |
|---|---|---|---|
| Bucle del agente, inferencia y planificación | Nube de Cursor | Ya está en Cursor | Self-Hosted Machines no lo traslada. |
| Ediciones de archivos y comandos de terminal | Tu worker | Se pueden devolver los resultados | El worker ejecuta las herramientas. |
| Checkout completo y caché de compilación | Tu worker | No se transfieren por defecto | La copia de trabajo completa permanece localmente. |
| Credenciales locales de la máquina | Tu worker | No se transfieren por defecto | Mantén los secretos fuera de los comandos, las salidas y los artefactos. |
| Contenidos de archivos y diffs | Tu worker y después el contexto/resultados del agente | Sí, cuando sea necesario | Privacy Mode aborda el uso para entrenamiento, no la transferencia. |
| Salida de terminal y resultados de MCP local | Tu worker y después los resultados de las herramientas | Sí, cuando se devuelven | Los resultados pueden contener código o datos confidenciales. |
| Capturas de pantalla y flujo del escritorio | Tu worker y después Cursor cuando se generan o comparten | Sí | Las sesiones de uso del ordenador pueden transmitir el escritorio del agente. |
| Vídeos, capturas de pantalla y referencias de registros | Almacenamiento de artefactos gestionado por Cursor | Sí, de forma predeterminada | Bloquea el host de artefactos para desactivar las subidas. |
| Peticiones de modelos mediante claves de API | Ruta de procesamiento de Cursor | Sí | BYOK no evita el backend de Cursor. |
La distinción clave es sencilla: el repositorio completo puede permanecer en tu máquina mientras determinados fragmentos de contexto siguen cruzando la red para la inferencia. Eso es control parcial sobre la ejecución, no una garantía de que no haya salida de datos.
Qué traslada realmente Cursor a tu infraestructura
Self-Hosted Machines traslada la ejecución de herramientas a una máquina controlada por el cliente. El worker puede editar archivos, ejecutar comandos, acceder a servicios internos, manejar un navegador y conectarse a servidores MCP locales. Cursor mantiene en su nube el bucle del agente, la inferencia, la planificación y la orquestación de las sesiones.
El worker se inicia con el comando de Cursor CLI agent worker start. A continuación, abre una conexión HTTPS saliente de larga duración con Cursor. Cursor indica que la conexión parte del worker: no hace falta abrir un puerto entrante, disponer de una dirección IP pública ni crear un túnel VPN.
El flujo de sesión documentado es el siguiente:
- Se inicia una sesión de Cloud Agent en la interfaz de Cursor.
- El bucle del agente en la nube de Cursor planifica la siguiente acción.
- Cursor envía una llamada a una herramienta a través de la conexión con el worker.
- El worker ejecuta el comando, la edición, la acción del navegador o la operación MCP.
- El worker devuelve el resultado para el siguiente paso de inferencia.
El worker sigue necesitando acceso saliente a api2.cursor.sh y api2direct.cursor.sh; las actualizaciones de CLI y parte de la configuración de uso del ordenador también pueden requerir downloads.cursor.com. El diseño basado solo en conexiones salientes evita el acceso entrante a tu red, pero no convierte el worker en un entorno de ejecución de modelos sin conexión.
Cursor plantea esta separación para repositorios o servicios privados a los que los workers alojados no pueden acceder, hardware especializado como GPU o Mac, y sistemas operativos o imágenes de compilación personalizados. Si el único requisito es la conectividad privada, la guía de decisión de runtimes de Cursor recomienda considerar primero los Cloud Agents gestionados con listas de permitidos, redes similares a Tailscale, AWS PrivateLink o Cloudflare Tunnel.
Qué puede salir del worker y qué cambia Privacy Mode
La documentación de Cursor enumera explícitamente los contenidos de archivos, las salidas de terminal, los diffs, las capturas de pantalla, los resultados de MCP local y los metadatos de enrutamiento como datos que el worker puede enviar. La cuestión de la privacidad tiene tres partes distintas: qué se transfiere, si se usa para entrenar modelos y durante cuánto tiempo se conserva.
Privacy Mode controla el entrenamiento, no bloquea la salida de datos
El resumen de uso de datos y privacidad de Cursor, actualizado el 28 de agosto de 2026, afirma que Privacy Mode impide que Cursor utilice los datos del cliente para entrenar modelos y que Cursor mantiene acuerdos de conservación cero de datos con sus proveedores. La misma página matiza esa afirmación: los clasificadores de riesgo pueden conservar prompts o conversaciones para investigarlos, y puede haber almacenamiento temporal de archivos por motivos de latencia y eficiencia de red.
Cursor describe los archivos almacenados en caché como cifrados con claves generadas por el cliente, que permanecen en los servidores de Cursor durante la duración de una petición. Es una afirmación de Cursor sobre conservación y protección; no demuestra que la petición no llegue nunca a sus servidores.
El detalle de las claves de API también importa. Cursor afirma que usar tu propia clave de API de un proveedor no evita su backend, porque las peticiones siguen pasando por Cursor para construir el prompt final. BYOK puede cambiar quién autoriza el uso del modelo, pero no debe interpretarse como una ruta de privacidad directa entre el cliente y el proveedor.
Un usuario llegó a la misma distinción arquitectónica al analizar la función:
«Límite importante: las máquinas autogestionadas de Cursor trasladan la ejecución, no el agente completo. Cursor afirma que la inferencia y la planificación permanecen en su nube; las salidas de las herramientas regresan y pueden contener código. En una revisión de seguridad, hay que tratarlo como ejecución autogestionada, no como un agente autogestionado». — @ham_zax, X
El interruptor de artefactos tampoco crea un aislamiento de datos
Cursor documenta una forma concreta de detener las subidas de artefactos: bloquear el tráfico HTTPS saliente hacia cloud-agent-artifacts.s3.us-east-1.amazonaws.com. Las llamadas a herramientas y sus resultados siguen funcionando, pero las capturas de pantalla, los vídeos y las referencias de registros no aparecerán en las pull requests ni en el panel de Cursor.
Es una medida útil cuando una organización no necesita artefactos visuales. No es una solución de privacidad completa, porque los contenidos de archivos, las salidas de terminal, los diffs, las capturas utilizadas durante la inferencia y los resultados de MCP todavía pueden devolverse a través de la conexión de la sesión del agente.
El transporte de MCP introduce otra diferencia práctica. La documentación de Team Pools de Cursor indica que los servidores MCP basados en comandos, o stdio, se ejecutan en el worker y pueden acceder a redes privadas. Los servidores MCP HTTP/SSE los gestiona el backend de Cursor para OAuth, el almacenamiento en caché de sesiones y la autenticación. Por tanto, un endpoint MCP privado requiere revisar también el transporte, no solo dónde está alojado.
Elige el runtime según tu restricción, no según la etiqueta
Cursor ofrece tres opciones de runtime. El alojamiento propio encaja mejor cuando el límite de ejecución, el hardware o el entorno son requisitos documentados y no simples preferencias.
| Runtime | Dónde se ejecutan las llamadas a herramientas | Más adecuado para | Responsabilidad principal |
|---|---|---|---|
| Cloud Agents gestionados por Cursor | VM aislada gestionada por Cursor | La mayoría de equipos que pueden utilizar redes gestionadas y entornos estándar basados en Ubuntu | Cursor gestiona el ciclo de vida de la VM, la capacidad, el aislamiento y la eliminación tras configurar tu entorno. |
| My Machines | El portátil, devbox, Mac o VM de un usuario concreto | Un flujo de trabajo personal, un repositorio con estado local o una prueba de concepto rápida | Tú gestionas la disponibilidad, las credenciales, las dependencias, la limpieza y el checkout. |
| Team Pools | Workers gestionados por la organización | Flotas empresariales, GPU, Mac, Kubernetes, enrutamiento mediante etiquetas y capacidad centralizada | Tu equipo gestiona los hosts, las imágenes, los secretos, el escalado, la monitorización, los reinicios y los fallos. |
Elige Cloud Agents gestionados si el único requisito es el acceso privado
Los Cloud Agents gestionados pueden ser suficientes si tu organización puede definir el límite mediante permisos de repositorio, listas de permitidos de red, un cliente similar a Tailscale o conectividad privada compatible. La guía de runtimes de Cursor recomienda la infraestructura gestionada para la mayoría de los equipos y la describe como la opción con menos carga operativa.
Así evitas operar una flota de workers y conservas el ciclo de vida de las VM gestionado por Cursor, además de la concurrencia elástica. Eso no significa que los agentes gestionados no intercambien datos; significa que el entorno de ejecución lo opera Cursor y no tu equipo.
Elige My Machines para un usuario y un entorno controlado
My Machines conecta una máquina personal con una cuenta individual de Cursor. Resulta práctico cuando un desarrollador ya dispone de un Mac, devbox o VM remota configurada, con dependencias locales y acceso de red que sería tedioso reproducir en otro lugar.
La contrapartida es operativa. La máquina debe permanecer conectada durante las sesiones activas, y el usuario se encarga de la limpieza, la actualización del checkout, el estado del disco, las credenciales y la reparación de dependencias. La documentación de alojamiento propio de Cursor indica que se pueden ejecutar varios agentes en la misma máquina, pero este no es el modelo de flota de equipo centralizada.
Elige Team Pools solo cuando el control de la flota compense la sobrecarga
Team Pools está pensado para equipos Enterprise. Utiliza autenticación mediante cuenta de servicio, capacidad compartida de workers, etiquetas y escalado basado en controladores. Un pool gpu puede dirigir el trabajo a máquinas con GPU; un pool ios puede enviarlo a Mac. Cursor documenta hasta 200 workers por usuario y 1.000 workers por equipo; las implementaciones de mayor tamaño requieren hablar sobre el escalado.
Los pools pueden escalar hasta cero y utilizar workers persistentes, contenerizados, basados en Kubernetes o alojados por partners. Cursor indica que restaurar un workspace liberado puede tardar varios minutos. La flexibilidad resulta útil para cargas variables, pero la gestión de imágenes, los reinicios de workers, la planificación de capacidad, la rotación de secretos y la monitorización pasan a ser responsabilidad del cliente.
El coste combina infraestructura y uso de modelos
La documentación de Self-Hosted Machines y la página de modelos y precios de Cursor describen las responsabilidades relativas a modelos, planes e infraestructura, pero no indican una tarifa independiente de Self-Hosted Machines por worker. El modelo de costes declarado es que sigues pagando a Cursor por el modelo seleccionado y, además, asumes el coste de la máquina, el contenedor, el clúster, el almacenamiento, la red, la monitorización y las operaciones que ejecutes.
Por eso, el alojamiento propio es un argumento débil para ahorrar costes cuando no existe un requisito especial de red o hardware. Los pools dinámicos y la hibernación pueden reducir el cómputo inactivo, pero el punto de equilibrio depende de la forma de la carga, el tiempo de arranque y cuánto estado haya que reconstruir; Cursor no publica una cifra universal.
Lista de comprobación de seguridad antes de activarlo
Usa esta lista con la persona responsable de seguridad, plataforma o cumplimiento, en lugar de tratar la palabra «self-hosted» como una señal automática de aprobación.
- Define el requisito de límite con precisión. Decide si la política exige que el checkout completo, la ejecución de herramientas, las credenciales, las peticiones de inferencia, los artefactos o todos ellos permanezcan dentro del perímetro. Self-Hosted Machines solo coloca bajo tu control el worker de ejecución y el estado local completo.
- Clasifica el contexto que se devuelve. Los contenidos de archivos, los diffs, las salidas de terminal, las capturas de pantalla y los resultados de MCP pueden enviarse a Cursor. Comprueba si esas salidas pueden contener código fuente, datos de clientes, tokens, URL internas o respuestas de producción.
- Activa Privacy Mode de forma deliberada. Cambia la postura declarada por Cursor respecto al entrenamiento y la conservación por parte de los proveedores; no impide el procesamiento de las peticiones, el almacenamiento temporal en caché ni el tratamiento para detectar riesgos.
- Interpreta BYOK correctamente. Según la página de uso de datos de Cursor, una clave de API no elimina el backend de Cursor de la ruta de la petición.
- Decide por separado sobre la salida de artefactos. Permite o bloquea
cloud-agent-artifacts.s3.us-east-1.amazonaws.comsegún aceptes o no las capturas, vídeos y referencias de registros en las pull requests y el panel. Si el firewall lo permite, es preferible una regla para el host exacto. - Usa una lista de permitidos solo saliente. Permite únicamente los endpoints de Cursor documentados y los hosts de actualización o de uso del ordenador que hayas habilitado expresamente. El worker no debería necesitar ningún puerto entrante ni una IP pública.
- Revisa el transporte de MCP. Usa MCP stdio en el worker cuando un servidor tenga que acceder a un servicio privado y analiza los resultados que devuelve. No des por hecho que un endpoint MCP HTTP/SSE permanece dentro de tu red solo porque el servicio sea privado.
- Aísla y reinicia los workers. En Team Pools, define cómo se borran o recrean las máquinas entre agentes, cómo se inyectan las credenciales y cómo se monitorizan los registros. Las guías y plantillas de Cursor son arquitecturas de referencia, no una flota de producción completamente gestionada.
- Prueba el comportamiento ante fallos. Confirma qué ocurre cuando los endpoints de Cursor, el almacenamiento de artefactos, el worker, un registro privado o un servidor MCP dejan de estar disponibles. No confundas un host de artefactos bloqueado con una sesión del agente bloqueada.
- Descártalo para cargas aisladas. Si el requisito es que no salga ningún contexto del modelo o que la inferencia no dependa de una nube de terceros, esta arquitectura no lo cumple. El bucle del agente sigue en la nube de Cursor.
| Tu requisito real | Decisión |
|---|---|
| Los comandos, el estado local o el hardware personalizado deben ejecutarse en tu entorno | Usa Self-Hosted Machines, con controles sobre la salida de contexto y artefactos. |
| Los agentes necesitan servicios privados, pero la ejecución puede producirse en una VM gestionada | Empieza con Cloud Agents gestionados y conectividad privada compatible. |
| Ningún contexto del modelo puede salir de la red o la inferencia debe funcionar sin conexión | Descarta esta arquitectura; sigue dependiendo de la nube de Cursor. |
Preguntas frecuentes sobre la privacidad de Cursor Self-Hosted Machines
¿Cursor Self-Hosted Machines es totalmente autogestionado?
No. Cursor mantiene en su nube el bucle del agente, la inferencia, la planificación y la orquestación. Tu máquina aloja la ejecución de herramientas y el estado de trabajo local.
¿El código fuente sale de la máquina autogestionada?
Determinados contenidos de archivos, diffs, salidas de terminal, capturas de pantalla y resultados de MCP local pueden salir del worker como entradas o resultados de herramientas para el agente. Cursor afirma que el checkout completo y la caché de compilación permanecen en el worker, por lo que el límite es parcial, no absoluto.
¿Privacy Mode evita que los datos crucen la red?
No. Privacy Mode se describe como una medida que impide el uso para entrenamiento por parte de Cursor y de los proveedores de modelos, conforme a las condiciones de conservación declaradas por Cursor. No evita que el worker envíe el contexto necesario para la inferencia.
¿BYOK evita pasar por Cursor?
No. La página de uso de datos de Cursor indica que las peticiones mediante claves de API siguen pasando por su backend para construir el prompt final. BYOK no debe interpretarse como una conexión directa entre tu worker y el proveedor del modelo.
¿Puedo impedir que se suban capturas de pantalla y vídeos?
Puedes bloquear el acceso saliente a cloud-agent-artifacts.s3.us-east-1.amazonaws.com. La ejecución de herramientas continuará, pero los artefactos no aparecerán en las pull requests ni en el panel de Cursor. Otros datos de la sesión del agente todavía pueden devolverse a Cursor.
¿El worker necesita una regla de firewall entrante o una VPN?
Cursor documenta un modelo de conexión saliente mediante HTTPS. Indica que no se necesita ningún puerto entrante, IP pública ni túnel VPN, aunque el worker sigue necesitando acceso saliente a los endpoints de Cursor documentados y a los servicios que deba utilizar.
¿Puedo usar Team Pools con un plan personal o de nivel inferior?
La documentación de Cursor sitúa Team Pools en el ámbito de Enterprise y exige una clave de API de cuenta de servicio. My Machines es la opción para un worker personal; no des por hecho que una clave de API personal puede iniciar un worker de Team Pool.
¿Puedo ejecutar Cursor Self-Hosted Machines completamente sin conexión?
No. El bucle del agente y la inferencia permanecen en la nube de Cursor, y el worker necesita una conexión saliente. Un requisito de funcionamiento sin conexión o en una red aislada exige otra arquitectura, con orquestación e inferencia de modelos alojadas localmente.
Usa Cursor Self-Hosted Machines cuando tu equipo necesite una ejecución controlada por el cliente, acceso a redes privadas, hardware personalizado o un entorno persistente. Si el requisito es mantener el tráfico de IA fuera de la nube, elige otro diseño: esta función cambia dónde se ejecutan los comandos, no dónde piensa el agente.