¿Es seguro usar Windsurf? Riesgos, controles y buenas prácticas

Qué cambió en 2026. El 2 de junio de 2026, Cognition, la empresa detrás de Devin, rebautizó Windsurf como Devin Desktop y presentó Devin Local como sucesor de Cascade. La versión 3.9.19, del 8 de septiembre de 2026, cerró el cambio: Cascade se retiró y Devin Local es ya el único agente del editor. windsurf.com redirige a devin.ai. Como casi todo el mundo sigue buscando "Windsurf", esta guía mantiene el nombre; cuando un control cambió con el agente, se describe el actual.

¿Qué es Windsurf y por qué cambia el modelo de seguridad?

Windsurf es un editor de código nativo de IA construido alrededor de un agente (Cascade, luego Devin Local) que no solo completa una línea sino que lleva a cabo una tarea. Describes la intención en lenguaje natural (construye esta funcionalidad, arregla esta prueba que falla, refactoriza a través de estos módulos) y el agente indexa el repositorio para obtener contexto, edita múltiples archivos en una sola ejecución, ejecuta comandos de terminal y se extiende a través del Model Context Protocol (MCP) para alcanzar los sistemas con los que habla tu código. Es parte del movimiento más amplio hacia la seguridad de agentes de código IA como disciplina, porque el editor es ahora un actor, no un asistente.

Esa combinación es la que rompe el viejo modelo de seguridad. Un asistente de IDE clásico ofrecía un completado; una persona lo leía y elegía aceptarlo o rechazarlo. El radio de impacto de una mala sugerencia era un bloque de código que un desarrollador todavía tenía que pegar. El agente, en cambio, actúa. Lee archivos que nunca nombraste, ejecuta comandos que nunca escribiste, reescribe código por todo el árbol y llama a herramientas MCP que conectaste hace semanas y olvidaste. La superficie de ataque ya no es "qué sugirió el modelo". Es "qué puede hacer este agente con el acceso que tiene, qué código puede generar en volumen y quién puede influir en sus instrucciones".

Una sugerencia es un borrador que una persona elige aceptar. Una acción es algo que ya ocurrió. El modelo de seguridad tiene que pasar de revisar borradores a restringir acciones.

Hay un segundo cambio, y tiene que ver con la velocidad. El pull request se convirtió en el hogar de la seguridad de las aplicaciones porque se situaba a ritmo humano: una persona bajaba el ritmo, leía el diff y solo entonces fusionaba. El agente no corre a ritmo humano. Una sola sesión de agente puede producir más código en una tarde del que un revisor lee en una semana, y el editor generará con gusto código funcional que es silenciosamente inseguro. Cuando eso ocurre, el diff deja de ser un punto de control y se convierte en una transcripción de decisiones ya tomadas. Cualquier control que solo actúe en el pull request ahora revisa historia, no la previene. La misma dinámica aparece en Cursor y Claude Code; lo que distingue a Windsurf es cuánto se apoya su agente en MCP para trabajar.

Para la mayoría de los equipos la pregunta práctica no es si Windsurf tiene protecciones integradas. Las tiene, y varias son genuinamente buenas. La pregunta es si bastan para el uso diario. La respuesta honesta es no. Los controles de Windsurf reducen el riesgo, pero una adopción segura sigue dependiendo de los permisos, el aislamiento, la supervisión humana y la validación independiente sobre el código, las dependencias, los secretos y los pipelines.

¿Cómo funciona el modelo de seguridad de Windsurf?

El modelo de Windsurf se construye sobre tres ideas: demostrar que la plataforma maneja los datos de forma responsable, dar al desarrollador palancas para mantener el código sensible fuera del alcance del modelo y acotar las acciones que el agente puede realizar. En la práctica eso se manifiesta en un puñado de controles, y son una base razonable para un editor tan capaz.

La trampa es leer esa lista como una frontera de seguridad terminada. Zero Data Retention protege tus datos pero no dice nada sobre la seguridad del código que escribe el agente. Un archivo de exclusión solo funciona si lo mantienes al día. Las reglas de permisos solo ayudan si las mantienes ajustadas, y en cuanto añades un Allow amplio (o pasas el agente al modo Bypass, que aprueba todas las llamadas) el paso de aprobación que las hacía seguras desaparece. El cumplimiento atestigua cómo Windsurf opera su servicio, no lo seguro que se comporta el agente en tu máquina ni qué servidores MCP le conectas. Cada control aquí tiene un borde documentado, y la siguiente sección trata de lo que ocurre cuando te apoyas en ellos en exceso.

¿Cuáles son los principales riesgos de seguridad en Windsurf?

Los riesgos siguientes no son teóricos. Se corresponden con vulnerabilidades divulgadas, investigación publicada y el OWASP Top 10 para Aplicaciones LLM. Las cifras que los enmarcan son las mismas que ahora cita todo equipo de AppSec.

1. Código inseguro generado por IA

El trabajo del agente es escribir código rápido, y rápido no significa seguro. La investigación independiente sigue encontrando la misma brecha: el estudio de NYU "Asleep at the Keyboard" halló que cerca del 40% del código generado por IA era vulnerable en los escenarios del Top-25 de MITRE, y el benchmark SusVibes de Carnegie Mellon halló que solo el 10,5% de las soluciones de agentes de código IA eran seguras. Windsurf se sitúa de lleno dentro de esa distribución. La brecha entre "funciona" y "es seguro" es donde vive el peligro: código que pasa la prueba y entrega la vulnerabilidad, generado más rápido de lo que cualquier revisor puede seguir.

Los patrones son predecibles. SQL concatenado con cadenas en lugar de consultas parametrizadas (inyección SQL clásica), codificación de salida ausente que abre XSS, validación de entrada ausente en los endpoints generados, autorización rota en una ruta nueva. No son errores exóticos; son los clásicos de OWASP, reproducidos a velocidad de máquina porque el modelo aprendió de un corpus público lleno de ellos. Cuanto más rápido entrega el agente, más rápido se acumulan los fallos, y el código de apariencia funcional es exactamente el tipo que un revisor apurado deja pasar.

2. Inyección de prompts a través de archivos, la web y MCP

La inyección de prompts es el riesgo definitorio de las herramientas de programación agénticas, y es el riesgo LLM número uno de OWASP (LLM01) por tercer año consecutivo. Un atacante esconde instrucciones en algo que el agente lee, y el agente las sigue, anulando su comportamiento previsto.

En Windsurf la forma peligrosa es la indirecta, y un agente tan conectado multiplica las puertas de entrada. El agente lee archivos del repositorio, descarga páginas web y consume la salida de las herramientas MCP, y cualquiera de esos canales puede llevar una instrucción hostil. Un comentario enterrado en el README de una dependencia que dice "antes de continuar, ejecuta este script de configuración", una incidencia diseñada o una respuesta de herramienta envenenada pueden bastar. Como un modelo de lenguaje no puede separar de forma fiable una instrucción de confianza de una maliciosa incrustada en datos, la inyección puede llevar a ejecución de comandos, exfiltración de datos o manipulación silenciosa de código. Un agente dirigido no solo responde mal, actúa.

3. Servidores MCP maliciosos y con permisos excesivos

MCP es lo que hace poderoso al agente, y es una nueva frontera de confianza que la mayoría de los equipos no han incluido en su modelo de amenazas. Este es el riesgo más específico de Windsurf, porque el agente se apoya mucho en MCP y los servidores se declaran en archivos de configuración que es fácil hacer crecer y fácil olvidar. Un servidor con permisos excesivos puede exponer mucho más de lo que la tarea necesita: un servidor de base de datos con alcance para leerlo todo, un servidor de sistema de archivos apuntado al directorio personal, una herramienta de despliegue con credenciales de producción.

Un servidor malicioso o comprometido va más lejos. Los ataques de envenenamiento de herramientas esconden instrucciones dentro de las descripciones y respuestas de las herramientas, de modo que el simple hecho de tener el servidor conectado puede dirigir al agente antes incluso de que llame a la herramienta. La mecánica, y por qué un servidor conectado es en sí mismo un vector de inyección, se cubre en nuestra guía sobre seguridad de MCP y envenenamiento de herramientas. La mitigación es contundente y correcta: usa servidores que escribiste o en los que confíes genuinamente, acota cada uno a los datos y acciones más estrechos que necesita, y trata todo lo que devuelve un servidor como entrada no confiable que debe validarse, no como un evangelio sobre el que el modelo pueda actuar.

4. Cadena de suministro y paquetes MCP con typosquatting

El agente instala paquetes, clona repositorios y conecta herramientas como parte del trabajo normal. Si arrastra una biblioteca comprometida o conecta un servidor MCP hostil, el código malicioso corre con el acceso que conceda el entorno. Esto no es hipotético. A principios de 2026 una campaña de typosquatting en npm rastreada como "SANDWORM_MODE" plantó servidores MCP fraudulentos imitando utilidades populares, apuntando específicamente a asistentes de programación con IA, entre ellos Windsurf, Cursor y Claude Code.

La alucinación de paquetes agrava el riesgo: un agente que inventa un nombre de paquete plausible pero inexistente entrega a los atacantes un hueco para registrarlo y convertirlo en arma. El agente a menudo aprobará la instalación con confianza, porque el nombre parece correcto y la tarea lo pedía. Un package.json envenenado, un hook post-install malicioso o un paquete MCP con typosquatting pueden convertir un prompt rutinario de "configura este repo" en un robo de credenciales.

5. Exposición de secretos y de contexto sensible

Windsurf es útil porque su agente tiene contexto, y ese contexto rutinariamente incluye más que código fuente. Cualquier cosa alcanzable en el espacio de trabajo, un archivo .env, una configuración con cadenas de conexión, endpoints internos de API, puede arrastrarse al contexto del modelo a menos que la excluyas explícitamente con un archivo de exclusión. Las funciones de IA de Windsurf también envían código a una API externa para generar respuestas, así que para la lógica de negocio sensible la pregunta de adónde va ese tráfico es real, y Zero Data Retention, junto con la exclusión del entrenamiento, es la palanca que usas para controlarlo.

La exposición suele ser indirecta. Al resumir un repositorio o depurar un error, el agente puede sacar a la luz un token, una credencial o un nombre de host interno en una salida que luego acaba en un chat, un ticket o un archivo confirmado, donde sobrevive mucho después de que termine la sesión. La postura por defecto es la comodidad, y la comodidad significa acceso amplio salvo que lo acotes a mano.

6. Ejecución de comandos y modos de aprobación automática

El agente ejecuta comandos de shell y modifica sistemas, así que un agente manipulado puede ejecutar comandos dañinos. Las reglas de permisos y el aviso de aprobación por comando son los controles que mantienen esto seguro, y se erosionan de dos formas conocidas. La primera es la fatiga de aprobaciones: cuando el agente pregunta decenas de veces por hora, la gente deja de leer y empieza a pulsar "permitir siempre", y en una semana el cuidadoso valor por defecto se ha convertido silenciosamente en una concesión general. La segunda es el modo Bypass (Turbo, en tiempos de Cascade), donde el agente ejecuta cada llamada sin pausar para pedir aprobación, eliminando el único paso que se interpone entre una instrucción inyectada y un comando destructivo.

El peligro se agrava cuando el editor corre con acceso amplio a la máquina del desarrollador. Una cadena de acciones individualmente inofensivas, instala esta dependencia, ejecuta esta tarea, aplica esta edición, puede instalar malware, alterar una configuración de CI o abrir un mecanismo de persistencia. Por eso exactamente importan el control de comandos, el privilegio mínimo y los entornos aislados, y por eso la combinación que hay que temer es la habitual: un repo o servidor MCP no confiable, una configuración permisiva para evitar fricción y una instrucción inyectada que el agente trata como legítima.

¿Qué cubre la seguridad integrada de Windsurf y qué no?

Los controles nativos son reales, y conviene ser preciso sobre la línea entre lo que gestionan y lo que te dejan a ti.

Lee la columna de la derecha como el trabajo real. Los controles integrados de Windsurf están inclinados hacia la privacidad de datos y el cumplimiento del proveedor, que es donde aterrizan las primeras preguntas de un comprador. Nunca se diseñaron para frenar a un adversario decidido que controla las entradas del agente (un archivo, una página web, una herramienta MCP), y no dicen casi nada sobre la seguridad del código que escribe el agente. Todo lo que convierte "Windsurf está instalado" en "Windsurf está gobernado" vive en las prácticas que siguen.

¿Es seguro usar Windsurf en una empresa?

Windsurf es seguro de desplegar en una empresa cuando está configurado y contenido, y arriesgado cuando no lo está. Su atestación SOC 2 y FedRAMP, Zero Data Retention y los archivos de exclusión superan el listón de compras y previenen una clase real de fugas de datos. El riesgo residual vive en el comportamiento del agente, no en el cumplimiento del proveedor.

Para una organización regulada, la historia de cumplimiento responde a la pregunta del riesgo del proveedor (cómo maneja Windsurf los datos en su lado) pero deja abierta la pregunta del riesgo de la aplicación (qué escribe el agente, qué ejecuta y con qué servidores MCP habla). Esos son problemas separados, y una atestación no cierra el segundo. Un despliegue empresarial práctico trata a Windsurf como un agente poderoso que necesita barreras de protección: Zero Data Retention y la exclusión del entrenamiento comprobados para los repositorios sensibles, .devinignore mantenido como un artefacto de seguridad, reglas de permisos ajustadas fijadas a nivel de equipo (prevalecen sobre cualquier regla de usuario o de proyecto), un conjunto de servidores MCP verificado e inventariado, entornos aislados para el trabajo no confiable, y revisión humana obligatoria más SAST en todo lo que produce el agente. La insignia de cumplimiento te abre la puerta; el gobierno es lo que evita que la puerta sea el punto débil.

¿Cómo aseguras los servidores MCP en Windsurf?

Trata cada servidor MCP como una frontera de confianza, no como una comodidad. Usa servidores que escribiste o que provengan de proveedores en los que confíes genuinamente, acota cada uno a los datos y acciones más estrechos que necesita, y valida todo lo que devuelve un servidor en lugar de dejar que el agente actúe directamente sobre ello. El archivo de configuración de MCP es un artefacto de seguridad, y merece la misma disciplina de revisión que el control de acceso.

En concreto, audita la configuración de MCP como auditas la IAM. Mantén un inventario de cada servidor conectado para que un paquete fraudulento o con typosquatting (como los servidores "SANDWORM_MODE") no se cuele sin que nadie lo note, y elimina los servidores que ya no se usan. En los planes Teams y Enterprise, una lista de permitidos de MCP bloquea cualquier servidor que no figure en ella. Nunca conectes un servidor con credenciales de producción a un entorno que también ejecuta código no confiable, porque una sola carga de envenenamiento de herramientas puede convertir esa conexión en exfiltración. Acota los servidores de base de datos a solo lectura y a las tablas concretas que una tarea necesita; apunta los servidores de sistema de archivos a un directorio de proyecto, nunca a la carpeta personal; y da a las herramientas de despliegue tokens de corta vida y acotados en lugar de claves de producción permanentes. Como una descripción de herramienta envenenada es inyección de prompts por diseño, la conexión en sí es parte de tu superficie de ataque incluso antes de que se llame a una herramienta, y por eso un control independiente en el prompt que pueda bloquear una acción peligrosa importa incluso cuando todos los servidores parecen legítimos.

¿Cuáles son las buenas prácticas para usar Windsurf de forma segura?

Estas nueve prácticas cierran la brecha entre la base nativa y una postura de seguridad real. Ninguna es exótica; la disciplina está en aplicarlas de forma consistente en un equipo que se mueve rápido.

1. Comprueba Zero Data Retention para el trabajo sensible, y asume la contrapartida. Desde el paso a Devin, tus datos pueden usarse para entrenar salvo que un plan de pago se excluya en la página Data Controls (en Teams lo hace un administrador). Trata esa exclusión como el valor por defecto para cualquier repositorio con lógica de negocio real, datos regulados o código propietario. Donde un equipo la relaje, que sea una decisión explícita y documentada acotada al trabajo de baja sensibilidad, no un valor por defecto silencioso que nadie comprobó.

2. Cuida .devinignore como un artefacto de seguridad. Excluye los archivos .env, los almacenes de credenciales, la configuración de infraestructura, las cadenas de conexión y cualquier módulo sensible tanto de la indexación como del alcance del agente, y refuérzalo con una regla Deny Read(**/.env*): con el sandbox activado, también oculta esas rutas a los comandos de shell. Revísalo como revisas el control de acceso: según un calendario, después de cada nuevo secreto o servicio, y como parte del alta de un repo nuevo. Un archivo de exclusión desactualizado es la forma más común de que un secreto acabe en el contexto de un modelo.

3. Mantén las reglas de permisos ajustadas, y resiste la aprobación automática. Escribe reglas Deny para los comandos destructivos y los que tocan credenciales (un Deny siempre gana), deja Ask en todo lo que alcance datos reales y no uses el modo Bypass en ningún entorno con acceso a datos reales o hosts de producción. Bypass elimina el único paso de aprobación que se interpone entre una instrucción inyectada y un comando destructivo.

4. Verifica e inventaría cada servidor MCP. Conecta solo servidores que escribiste o en los que confíes genuinamente, acota cada uno a los datos y acciones más estrechos que necesita, mantén un inventario en la configuración de MCP, y nunca conectes un servidor con credenciales de producción a un entorno que ejecuta código no confiable. Trata las descripciones y respuestas de las herramientas como entrada no confiable.

5. Mantén a una persona en el bucle sobre el código generado. Trata la salida del agente como un borrador, no como una implementación final. Encamina todo el código generado o modificado por revisión de pull request y pruebas automatizadas, con escrutinio extra en autenticación, validación de entradas, consultas SQL y rutas con privilegios. Un agente que produce miles de líneas al día produce fallos sutiles más rápido de lo que afloran por sí solos.

6. Analiza el código generado por IA con SAST en CI. Como solo una fracción de las soluciones de IA es segura por defecto, una puerta de análisis estático no es opcional. Ejecuta SAST en cada pull request, falla la compilación ante hallazgos de severidad alta (inyección SQL, XSS, autorización ausente) y retroalimenta los resultados para que las mismas clases dejen de repetirse. Las pruebas funcionales no atraparán un endpoint vulnerable pero funcional; solo lo hará una comprobación consciente de la seguridad.

7. Gobierna dependencias y paquetes. Restringe las instalaciones a registros de confianza o espejos internos, exige aprobación para paquetes nuevos y analiza todo con análisis de composición de software. No dejes que el agente instale automáticamente paquetes oscuros por mucha confianza con la que los sugiera, y verifica que un paquete sugerido existe realmente antes de añadirlo.

8. Gestiona los secretos fuera de alcance. Mantén los secretos en texto plano fuera del espacio de trabajo que el agente puede ver. Usa una bóveda e inyéctalos en tiempo de ejecución, redacta los valores sensibles en los registros y la salida, y nunca dejes archivos de credenciales donde la indexación pueda alcanzarlos. Si alguna vez un secreto aparece en una transcripción, un archivo generado o un commit, rótalo de inmediato e investiga cómo llegó ahí.

9. Ejecuta el trabajo arriesgado en entornos aislados y de privilegio mínimo, y fija la política por sensibilidad. Usa contenedores o VM aisladas para el trabajo asistido por IA sobre código no confiable, ejecuta Windsurf sin privilegios elevados y bloquea las conexiones salientes no aprobadas para que una sesión comprometida no pueda exfiltrar. El sandbox de Devin Local, a nivel de sistema operativo, limita los archivos y dominios que alcanzan sus comandos, y los administradores de Enterprise pueden imponerlo. Clasifica los repositorios (público, interno, regulado, producción) y aplica controles más estrictos a los sensibles, manteniendo los sistemas críticos fuera de cualquier ruta directa a credenciales de producción.

Donde se detienen los controles integrados: asegurar al agente en el momento del prompt

Recorre de nuevo los riesgos y emerge un patrón. Zero Data Retention, el archivo de exclusión, las reglas de permisos y SAST actúan todos sobre lo que el agente ya ha decidido hacer, o sobre código que ya ha escrito. Se agrupan alrededor del pull request, porque ahí ha vivido siempre la AppSec. Pero el PR solo fue un punto de control porque una persona lo leía, y a ritmo de agente ya nadie lo lee de principio a fin.

El lugar para aplicar una regla ya no es el diff; es el prompt, antes de que se escriba la línea insegura. Cualquier regla que quieras que el agente siga tiene que estar en sus manos en el momento en que escribe, no esperando en un escáner que llega una vez que el código está en disco y el agente ha pasado a la siguiente tarea.

Esa es la capa que añade VibeDefend. Es una CLI de npm gratuita que se instala con un solo comando y conecta Windsurf (además de Claude Code, Cursor, OpenAI Codex y VS Code Copilot) en cuatro capas de gobierno que corren dentro del bucle del agente.

Las cuatro capas gestionan modos de fallo distintos. Las reglas de negocio son las convenciones de tu repo que nunca se escribieron (usa Decimal128 para el dinero, la autorización pasa por requireOwner); VibeDefend las extrae de cómo tu equipo ya programa y las carga en el contexto del agente antes de cada edición. Las reglas de seguridad llevan OWASP Top 10, SOC 2, RGPD e ISO 27001 al código mientras se escribe, así el requisito del marco se vuelve parte del código en lugar de una casilla a marcar en auditoría. En Windsurf, el Action Guard funciona con los hooks del editor, que cubren la escritura y la lectura de archivos y los comandos de shell: VibeDefend sirve las reglas antes de cada edición, y el guardián puede frenar una escritura de archivo que no cumple las reglas antes de que llegue al disco, una lectura cruda de un archivo .env, o un sudo rm -rf o un psql improvisado contra un host de producción antes de que se ejecute, advirtiendo o bloqueando según la regla, con cada intercepción en el registro de auditoría. Windsurf no tiene hook para las peticiones web y no filtra las llamadas a herramientas MCP: para esas, un fragmento de .windsurfrules pide al agente que compruebe primero, y funciona mientras el modelo siga su archivo de reglas. Live Findings conecta el agente con la plataforma de seguridad del código de CybeDefend, sus escáneres (SAST con alcanzabilidad, SCA, secretos, IaC y CI/CD) corriendo de forma continua, así que el agente no solo escribe código seguro, también tría y arregla las vulnerabilidades que ya tienes. En cuanto a adónde va tu código: los guardianes de acciones deciden en tu portátil, antes de que se ejecute una acción; para servir las reglas que encajan con la línea que se está escribiendo, VibeDefend envía un fragmento breve de ese código al backend de CybeDefend, y el escaneo previo al commit envía los archivos modificados, ambos en la región de la UE o de EE. UU. que eliges al instalar. Las dos regiones están físicamente separadas, y tu código nunca se usa para entrenar un modelo.

Preguntas frecuentes

¿Es seguro Windsurf?

Windsurf es seguro de usar cuando está configurado y contenido, y arriesgado cuando no lo está. Su atestación SOC 2 y FedRAMP, Zero Data Retention, los archivos de exclusión y las reglas de permisos previenen una clase real de fugas de datos y accidentes. El riesgo residual viene del código que genera el agente (solo una fracción es segura nada más sacarla de la caja), de las entradas (inyección de prompts en archivos, páginas web y salida de herramientas MCP), de los servidores MCP que conectas y del entorno circundante (secretos expuestos, repos no confiables, modos de aprobación automática). Trátalo como un agente poderoso que necesita exclusión de secretos, control de comandos, escrutinio de servidores, revisión humana y SAST, no como una herramienta segura por defecto.

¿Windsurf envía mi código a la nube?

Sí. Las funciones de IA de Windsurf envían código a una API externa para generar respuestas, lo que puede incluir contenidos de archivos y el contexto circundante de tu tarea. Lo que pasa después depende de tu plan. Windsurf mantenía el código fuera de sus servidores por defecto en Teams y Enterprise; desde el paso a Devin, Cognition dice que tus datos pueden usarse para entrenar salvo que un plan de pago se excluya en la página Data Controls, lo que también activa Zero Data Retention con los proveedores de modelos, y los datos de Enterprise nunca se usan para entrenar sin consentimiento por escrito. Para la lógica de negocio sensible, comprueba esa exclusión, excluye los secretos y los datos regulados del contexto con .devinignore y revisa la política de manejo de datos de Cognition frente a tus propios requisitos. Una capa de gobierno como VibeDefend también envía algo de código: un fragmento breve para servir las reglas y los archivos modificados para el escaneo previo al commit, a la región de la UE o de EE. UU. que eliges al instalar, y nunca se usa para entrenar un modelo.

¿Qué es Windsurf Cascade y es un riesgo de seguridad?

Cascade era el agente de Windsurf: leía el repositorio, editaba varios archivos, ejecutaba comandos de terminal y llamaba a herramientas MCP para completar una tarea descrita en lenguaje natural. Desde el 8 de septiembre de 2026 ya no está en el editor, ahora Devin Desktop: lo sustituye Devin Local, que hace el mismo trabajo bajo reglas Allow, Ask y Deny. Ninguno de los dos es un riesgo en sí mismo, pero ambos cambian el modelo de riesgo, porque actúan en lugar de ofrecer sugerencias que una persona acepta. Las preguntas de seguridad pasan a ser qué puede ejecutar el agente, qué código genera y quién puede influir en sus instrucciones. Mantén sus reglas de permisos ajustadas, sus servidores MCP verificados, su contexto libre de secretos y su salida bajo revisión humana y SAST.

¿Cómo aseguro los servidores MCP en Windsurf?

Trata cada servidor MCP como una frontera de confianza. Usa servidores que escribiste o que provengan de proveedores en los que confíes genuinamente, acota cada uno a los datos y acciones más estrechos que necesita, y valida todo lo que devuelve un servidor en lugar de dejar que el agente actúe directamente sobre ello. Mantén un inventario en la configuración de MCP para que un paquete fraudulento o con typosquatting no se cuele sin que nadie lo note, nunca conectes un servidor con credenciales de producción a un entorno que ejecuta código no confiable, y recuerda que una descripción de herramienta envenenada es inyección de prompts por diseño, así que la conexión es parte de tu superficie de ataque incluso antes de que se llame a una herramienta.

¿Puede Windsurf ejecutar comandos o código automáticamente?

Por defecto, el agente pide permiso antes de ejecutar un comando de shell o escribir un archivo, y las reglas Allow dejan pasar sin aviso los comandos que elijas. El riesgo llega cuando ese paso de aprobación se elimina, ya sea por fatiga de aprobaciones (pulsar "permitir siempre" hasta que el valor por defecto se convierte en una concesión general) o al pasar al modo Bypass, donde el agente ejecuta cada llamada sin pausar (Cascade lo llamaba Turbo). Mantén las reglas ajustadas, deniega los comandos destructivos y los que tocan credenciales, y deja Bypass desactivado en cualquier entorno con acceso a datos reales o hosts de producción.

¿Basta Zero Data Retention para que Windsurf sea seguro?

No, y conviene ser preciso. Zero Data Retention es un control de datos: limita dónde se guarda tu código y si se usa para entrenar. No dice nada sobre la seguridad del código que genera el agente, sobre si una inyección de prompts puede dirigir al agente o sobre si un servidor MCP es malicioso. Zero Data Retention protege tus datos; no protege tu aplicación. Sigues necesitando .devinignore, reglas de permisos ajustadas, servidores MCP verificados, SAST, revisión humana y un control en el prompt.

¿En qué se diferencia la seguridad de Windsurf de la de Cursor o Claude Code?

Los fundamentos son compartidos (privilegio mínimo, exclusión de secretos, revisión humana, análisis de dependencias), pero las superficies difieren. La superficie distintiva de Windsurf es lo mucho que su agente se apoya en MCP, lo que convierte la configuración de MCP y el envenenamiento de herramientas en el riesgo a modelar primero; Cursor salió con Workspace Trust desactivado por defecto y genera una alta tasa de código inseguro; Claude Code tiene una integración profunda con MCP y el shell, con permisos escalonados. Los tres comparten la misma brecha: los controles integrados se agrupan en el pull request, mientras que la regla necesita alcanzar al agente en el momento del prompt. El arreglo común es una capa de gobierno en el momento del prompt como VibeDefend, o reserva una sesión para verlo en tu propio repo.