roobriefNoticias de TI para desarrolladores

Dev y lanzamientos

Los comandos de los agentes de Cursor pueden ejecutarse en equipos de la empresa, pero el análisis de vulnerabilidades corre en la nube de Cursor

Las llamadas a herramientas de los agentes en la nube pueden quedarse en equipos de la empresa, pero el contenido de los archivos que el modelo lee para responder no se queda dentro de la empresa por defecto.

Cursor abrió dos funciones empresariales en septiembre. El 2 de septiembre anunció Self-Hosted Machines, que llevan las ediciones de archivos y la ejecución de comandos de los agentes de IA en la nube (programas que realizan por su cuenta tareas de varios pasos para el usuario) a ordenadores que posee la empresa. El 23 de septiembre abrió Security Review en los planes Teams y Enterprise. Security Review busca errores explotables en pull requests (un cambio de código propuesto para que otra persona lo revise antes de integrarlo).

Design Mode, que permite pinchar elementos en pantalla para corregirlos, y Agent Tabs, que muestran varios chats en paralelo en el editor, no formaban parte de esos lanzamientos de septiembre. Design Mode apareció con Cursor 3 el 2 de abril; la selección múltiple y la voz se añadieron el 5 de junio. Agent Tabs también está en el registro de cambios del 2 de abril.

Señalar elementos en pantalla y pasárselos al agente

Design Mode se usa en el navegador de la Agents Window, no en un navegador web normal. En Mac se enciende y se apaga con Cmd+Shift+D. La documentación no indica un atajo para Windows.

Al pinchar un elemento, ese elemento y el código detrás van al agente. Desde el 5 de junio se pueden seleccionar varios y pedir, por ejemplo, «que este coincida con aquel», o dictar el siguiente cambio. El micrófono sigue abierto mientras los agentes trabajan. Si se rodea una zona, la marca queda sobre una imagen congelada, para que el agente parta de la escena vista.

De un elemento seleccionado salen dos señales: dónde está en la página y qué componente es (ruta, nombre, atributos, estilos calculados, props), y una captura del layout alrededor. Cuando termina la edición, la app redibuja sin recargar del todo. Cursor recomienda su modelo Composer 2.5 para este flujo.

La ventana multiagente y las pestañas del editor son distintas

La Agents Window es una pantalla aparte, disponible de forma general desde el 2 de abril. En el editor, Cmd+Shift+P y Open Agents Window la abren. Ahí se ven agentes locales, en la nube y por SSH remoto (trabajar conectándose a otro ordenador) en un solo sitio, y se pueden lanzar varios en paralelo en la nube. Para volver al editor anterior, elegir Open IDE en la misma lista. Durante dos semanas tras el lanzamiento, los admins de Enterprise podían limitar el acceso; ese plazo ya pasó.

Las Agent Tabs del editor están en el mismo registro, pero hacen otra cosa: muestran varios chats en paralelo o en cuadrícula. La pantalla para ejecutar muchos trabajos en la nube a la vez es la Agents Window.

Comandos en equipos de la empresa, decisiones en la nube de Cursor

El registro del 2 de septiembre resume Self-Hosted Machines así: la ejecución de herramientas queda en la red de la empresa; la base de código (todo el código del repositorio), los artefactos de compilación y los secretos se quedan en máquinas internas.

La documentación de Cursor sobre Self-Hosted Machines deja la planificación en la nube de Cursor. Las ediciones de archivos, los comandos de terminal, los clics en pantalla y los servidores MCP locales (un estándar que permite a la IA usar herramientas externas) corren en un worker: la máquina que acepta y ejecuta el trabajo. Decidir qué hacer y la inferencia (usar un modelo ya terminado para generar respuestas) se quedan en Cursor.

Durante una ejecución, el worker envía a Cursor el contenido de archivos necesario, la salida del terminal, los diffs, capturas, resultados MCP locales y metadatos de enrutado. Si está activo el uso compartido del escritorio, ese flujo también sale. Las capturas, vídeos y referencias de registros para pull requests y el panel también suben a un almacenamiento gestionado por Cursor. Dentro de la empresa quedan el repositorio completo, la caché de compilación (archivos intermedios para no reconstruir) y las credenciales de esa máquina. La documentación dice que no se pongan secretos en salidas de herramientas ni en artefactos.

Con Privacy Mode, Cursor y los proveedores de modelos no entrenan con el código que envía el worker. Eso no significa que el código no salga. Los workers no abren puertos de entrada: basta una conexión web cifrada saliente hacia Cursor. Para bloquear solo artefactos, bloquear el tráfico saliente a cloud-agent-artifacts.s3.us-east-1.amazonaws.com. El trabajo sigue; los artefactos dejan de verse en pull requests y en el panel.

Hay dos formas de usarlo:

  • My Machines es personal. Se conecta el propio ordenador a la cuenta con inicio de sesión en el navegador o una clave API personal (una cadena secreta que un programa presenta en lugar de un inicio de sesión). En una máquina pueden correr varios agentes. Los secretos del panel no bajan a este worker.
  • Team Pools agrupa workers para una organización. La documentación de Cursor exige el plan Enterprise. La autenticación solo admite una clave API de cuenta de servicio. Una cuenta de servicio es de equipo, no de una persona. Con la opción activada se puede elegir por petición; si no, corre en la infraestructura de Cursor. Si se obliga, cada ejecución de agente en la nube va a workers propios. En un pool, un agente ocupa una máquina a la vez.

Los entornos citados el 2 de septiembre incluyen AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel y E2B. La documentación también menciona Kubernetes (un sistema de código abierto que gestiona muchos contenedores). Límites: 200 workers por usuario y 1.000 por equipo. El precio del modelo no cambia; la empresa paga las máquinas. Los agentes gestionados por Cursor incluyen la máquina de ejecución.

La documentación recomienda primero los agentes en la nube gestionados para la mayoría de los equipos. El self-hosting conviene cuando el código no debe salir de la red, o cuando hacen falta GPU o Mac para apps de iPhone e iPad. Si el único problema es un servidor Git privado o un registro de paquetes interno, la documentación dice probar primero un enlace privado a la red de la empresa en agentes gestionados. Ejemplos: AWS PrivateLink y Cloudflare Tunnel.

Buscar errores explotables en propuestas de cambio

Security Review abrió el 23 de septiembre en Teams y Enterprise. Se eligen repositorios en el panel; lee pull requests que no son borrador en el contexto de la base de código y deja un comentario de revisión sobre errores explotables. El estilo y la calidad siguen en Bugbot. No fusiona ni reescribe el código por sí solo.

Este análisis no corre en equipos de la empresa. La documentación de Security Agents indica que Security Review y los escaneos de vulnerabilidades del repositorio corren sobre agentes en la nube y usan la nube de Cursor sin instalación extra. Un agente en la nube clona el repositorio autorizado en una máquina virtual de la nube de Cursor. Esa copia no se borra en cuanto termina la ejecución; las instantáneas se eliminan tras 30 días sin uso. Hay una excepción: el Security Review de un equipo disparado por un evento de pull request corre en un alojamiento gestionado por Cursor, no en un agente en la nube. Tampoco es un equipo de la empresa. Esas páginas no dicen si ese alojamiento clona el repositorio entero.

El alcance incluye inyección en consultas a bases de datos, comandos de shell y plantillas de página; faltas de comprobaciones de inicio de sesión o de permisos, incluidas las que dejan de ejecutarse tras un refactor; secretos subidos al código; SSRF (un fallo en el que un servidor envía una petición a una dirección elegida por un atacante) y redirecciones sin validar; deserialización insegura al volver a convertir datos guardados en valores del programa; cambios de dependencias que traen vulnerabilidades conocidas; y el rastro de dónde entra la entrada del usuario y por dónde pasa.

Cada hallazgo lleva gravedad, ruta de ataque y una corrección propuesta. Si se descarta con un motivo, no se vuelve a plantear en esa pull request. Las reglas de equipo se aplican a cada pull request: por ejemplo, que las llamadas externas pasen por un cliente fijo, o que ciertas tablas no se consulten desde los manejadores de peticiones. En este anuncio no hay un precio aparte.

El mismo día también abrió Rollouts en Teams y Enterprise. Al desplegar, informa por entorno si todo parece sano, peor que antes o dudoso. No fusiona ni revierte solo; según la configuración puede abrir una pull request de revert para revisar o pasar una corrección a un agente en la nube. El control de código se conecta a Origin o GitHub, y las señales a Datadog y herramientas similares. La integración de feature flags (interruptores que activan o desactivan funciones por usuario) solo se anuncia como «próximamente»; al 16 de octubre no pudimos confirmar si ya estaba abierta. Los créditos de prueba de Rollouts duraron 10 días desde el lanzamiento: unos 50 cambios para Teams y unos 500 para Enterprise. El 16 de octubre esa ventana ya había cerrado; no pudimos confirmar si quedaban créditos después.

Lo que no pudimos confirmar o conviene tratar con cautela

  • Ver estas funciones como una sola gran actualización es incorrecto. Señalar en pantalla es del 2 de abril y el 5 de junio; el self-hosting, del 2 de septiembre; Security Review, del 23 de septiembre.
  • «El código y los artefactos de compilado no salen nunca» va más allá de la documentación de Cursor. El repositorio completo, la caché de compilado y las credenciales de la máquina se quedan; el contenido de archivos necesario para la ejecución y los artefactos van a Cursor.
  • Decir que el self-hosting abrió a la vez en Teams y Enterprise no encaja con la documentación de Cursor. Los Team Pools exigen Enterprise. El registro del 2 de septiembre solo habla de una cola para equipos o empresas; la inclusión del plan Teams no se puede fijar solo con esa frase.
  • Que la adopción se acelera entre clientes empresariales sensibles a la seguridad no tiene cifra ni anuncio oficial que hayamos podido verificar.
  • Tampoco hay en el anuncio de Cursor afirmaciones de que Security Review bloquee toda vulnerabilidad o corrija los errores por sí solo.

Qué podría cambiar para los desarrolladores

Lo que sigue es nuestra estimación y consejo a partir de los informes.

  • No escribir «el código no sale» en un informe de seguridad. Separar lo que se queda y lo que sale según la documentación de Cursor. Bloquear la subida de artefactos es otra pregunta: si se corta el tráfico saliente a ese host de almacenamiento.
  • Los Team Pools exigen el plan Enterprise y el coste de operar las máquinas. El precio del modelo no cambia. Probar en el propio ordenador es My Machines. La documentación sigue recomendando los agentes en la nube gestionados por Cursor para la mayoría de los equipos.
  • Security Review no corre en equipos de la empresa. Activarlo por repositorio; las pull requests en borrador no entran. Un hallazgo descartado no vuelve en esa pull request: dejar un motivo antes de cerrarlo. Estilo y calidad siguen en Bugbot.
  • Design Mode no se ve si solo está abierto el editor. Activarlo con Cmd+Shift+D en el navegador de la Agents Window. Las tablas de atajos de la documentación son solo para Mac.

Qué vigilar

Si los feature flags se conectan a Rollouts, si se publican el precio y la tasa de falsos positivos de Security Review, y si aparece una opción que deje también el contenido de archivos de inferencia dentro de la empresa.

Fuentes

Fuente: cursor.com

← Volver