Seguridad de Windsurf: riesgos, controles y buenas prácticas

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

Windsurf es un editor de código nativo de IA construido alrededor de Cascade, un agente 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 Cascade 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. Cascade, en cambio, realiza acciones. 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. Cascade 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; el matiz propio de Windsurf es lo profundamente que Cascade se apoya en MCP para hacer su trabajo.

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 controlar las acciones que Cascade 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-Day Retention protege tus datos pero no dice nada sobre la seguridad del código que Cascade escribe. .codeiumignore solo funciona si lo mantienes. La lista de permitidos de comandos solo ayuda si la mantienes ajustada, y en el momento en que añades una entrada amplia (o cambias Cascade a auto-ejecución) el paso de aprobación que lo hacía seguro 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 de Cascade 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 Cascade, 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 Cascade amplía la apertura. 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 a Cascade, 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 Cascade se apoya mucho en MCP y los servidores se declaran en un archivo de configuración que es fácil de hacer crecer y fácil de 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 a Cascade 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

Cascade 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 Cascade 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 .codeiumignore. 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-Day Retention es la palanca que usas para controlarlo.

La exposición suele ser indirecta. Al resumir un repositorio o depurar un error, Cascade 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 modo de auto-ejecución

Cascade ejecuta comandos de shell y modifica sistemas, así que un agente manipulado puede ejecutar comandos dañinos. La lista de permitidos de comandos 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 de auto-ejecución, donde Cascade ejecuta comandos 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 Cascade escribe. 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-Day Retention y .codeiumignore 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 Cascade, 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-Day Retention activo para los repositorios sensibles, .codeiumignore mantenido como un artefacto de seguridad, una lista de permitidos de comandos ajustada, 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 Cascade produce. 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 Cascade 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. 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. Mantén Zero-Day Retention activo para el trabajo sensible, y asume la contrapartida. Trátalo como el valor por defecto para cualquier repositorio con lógica de negocio real, datos regulados o código propietario. Donde un equipo lo 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 .codeiumignore 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 contexto de Cascade. 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 la lista de permitidos de comandos ajustada, y resiste la auto-ejecución. Mantén una lista de permitidos y de denegados deliberada para los comandos de terminal de Cascade, deniega de plano los comandos destructivos y los que tocan credenciales, y mantén la auto-ejecución desactivada en cualquier entorno con acceso a datos reales o hosts de producción. La auto-ejecución 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 de Cascade 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 Cascade 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 Cascade 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. 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-Day Retention, .codeiumignore, la lista de permitidos de comandos 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 Cascade 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 en unos cinco segundos 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 de Cascade 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. El Action Guard intercepta las llamadas destructivas (un sudo rm -rf, una lectura cruda de una variable de entorno con forma de secreto, un psql improvisado contra un host de producción) antes de que se disparen, advirtiendo o bloqueando según la regla, con cada intercepción en el registro de auditoría. Live Findings conecta el agente con la plataforma completa de AppSec 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. Es importante destacar que nada de tu código cruza la red: las decisiones ocurren localmente junto al agente, y solo metadatos de gobierno estructurados (la regla que se disparó, la ruta del archivo, la severidad, una marca de tiempo) llegan al backend. Los tenants de EU y US están físicamente separados, y eliges la región en el momento de la instalación. Ese modelo de privacidad es lo que permite que un control se sitúe tan cerca del código sin convertirse, por sí mismo, en un riesgo de exfiltración de datos.

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-Day Retention, .codeiumignore y la lista de permitidos de comandos previenen una clase real de fugas de datos y accidentes. El riesgo residual viene del código que Cascade genera (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, modo de auto-ejecución). 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. Zero-Day Retention cambia lo que ocurre con ese código en el lado de Windsurf: con él activo, tus prompts y tu código no se persisten, y los planes empresariales no se usan para entrenar. Para la lógica de negocio sensible, mantenlo activo, excluye los secretos y los datos regulados del contexto con .codeiumignore y revisa la política de manejo de datos de Windsurf frente a tus propios requisitos. Una capa de gobierno como VibeDefend se mantiene separada y no transmite código fuente.

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

Cascade es el agente de Windsurf: lee el repositorio, edita múltiples archivos, ejecuta comandos de terminal y llama a herramientas MCP para completar una tarea a partir de un prompt en lenguaje natural. No es un riesgo en sí mismo, pero cambia el modelo de riesgo, porque realiza acciones en lugar de ofrecer sugerencias que una persona acepta. Las preguntas de seguridad pasan a ser qué puede ejecutar Cascade, qué código genera y quién puede influir en sus instrucciones. Mantén su lista de permitidos de comandos ajustada, 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 Cascade 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?

Cascade pregunta antes de ejecutar un comando de terminal por defecto, y puedes mantener una lista de permitidos de comandos que puede ejecutar sin aviso. 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 activar el modo de auto-ejecución, donde Cascade ejecuta comandos sin pausar. Mantén la lista de permitidos ajustada, deniega los comandos destructivos y los que tocan credenciales, y mantén la auto-ejecución desactivada en cualquier entorno con acceso a datos reales o hosts de producción.

¿Zero-Day Retention de Windsurf lo hace seguro?

No, y es importante ser preciso. Zero-Day Retention es un control de datos: garantiza que tus prompts y tu código no se persisten en los servidores de Windsurf. No dice nada sobre la seguridad del código que Cascade genera, sobre si una inyección de prompts puede dirigir al agente o sobre si un servidor MCP es malicioso. Zero-Day Retention protege tus datos; no protege tu aplicación. Sigues necesitando .codeiumignore, una lista de permitidos de comandos ajustada, 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 Cascade 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.