Por qué Claude Code y Cursor disparan tu EDR (y qué hacer)

Los EDR marcan a Claude Code, Cursor y Codex como sospechosos porque su patrón de ejecución coincide con las heurísticas de detección de malware: un proceso Node.js o Electron que lanza subshells, escribe decenas de archivos por minuto y abre conexiones salientes a APIs desconocidas. No es un fallo del antivirus ni un capricho del producto: es exactamente el patrón que MITRE ATT&CK cataloga como Living-off-the-Land, la técnica favorita de atacantes reales para pasar desapercibidos dentro de un binario legítimo y firmado.

Un motor EDR no evalúa intenciones, evalúa comportamiento de proceso. No le importa si el binario se llama Claude Code, Cursor o Codex: le importa que un intérprete (Node.js, Electron, Python) esté generando subprocesos de shell, escribiendo o modificando archivos a un ritmo anómalo fuera de su carpeta de instalación y estableciendo conexiones HTTPS salientes hacia dominios que el modelo de detección no tiene catalogados como habituales en esa máquina. Esa combinación —intérprete que lanza shell, ráfaga de escritura de ficheros, egress a IP desconocida— es prácticamente la definición operativa de un beacon de C2 tipo Cobalt Strike. El agente de código IA hace, en superficie, lo mismo que haría un implante: ejecuta comandos arbitrarios que le llegan de fuera del binario original. La diferencia entre 'herramienta legítima de productividad' y 'malware' no está en la telemetría que ve el EDR, está en el contexto que el analista tiene que añadir a mano.

El árbol de procesos que activa la alarma

En la práctica, la cadena que dispara la regla suele ser idéntica en cualquier fabricante de EDR: un proceso node.exe o electron.exe (el editor o la CLI del agente) engendra powershell.exe, bash o cmd.exe como hijo directo, ese hijo escribe en rutas de proyecto que no pertenecen al propio agente, y casi en paralelo se registran conexiones salientes hacia dominios de API que no estaban en la lista blanca de la organización. El motor de detección no puede distinguir entre 'el desarrollador le pidió al agente que refactorizara un módulo' y 'un atacante ha inyectado instrucciones que ejecutan un payload', porque a nivel de proceso ambos escenarios generan la misma huella de comportamiento. Esto no es un defecto del EDR: es justo lo que se le pide que haga. El problema aparece después, cuando el equipo de seguridad decide cómo responder a esa alerta sin visibilidad real sobre qué estaba haciendo el agente.

MITRE ATT&CK ya tiene nombre para esto: Living-off-the-Land

La técnica T1059 (Command and Scripting Interpreter) de MITRE ATT&CK describe precisamente el abuso de intérpretes legítimos —shells, PowerShell, Python— para ejecutar código malicioso sin desplegar un binario nuevo que dispare firmas. Los llamados LOLBins (Living-off-the-Land Binaries) son binarios firmados y confiables que un atacante reutiliza para evadir defensas basadas en reputación de fichero. Un agente de código IA es, estructuralmente, un LOLBin voluntario: Node.js o Python, firmados y confiables, ejecutando instrucciones que no vienen del propio binario sino de un modelo remoto. Esto no convierte a Claude Code en una amenaza, pero sí explica por qué cualquier EDR razonablemente configurado lo trata con la misma sospecha que a una técnica de evasión conocida.

Lo que vemos una y otra vez en clientes que despliegan Claude Code, Cursor o Codex en máquinas de desarrollo es el mismo atajo: el SOC se cansa del volumen de alertas y añade una exclusión completa para node.exe, npm.cmd o electron.exe en la política EDR. Es la solución más rápida y, a corto plazo, funciona: las alertas desaparecen y el equipo de desarrollo deja de quejarse. El coste oculto es que esa exclusión no distingue entre el agente de código autorizado y cualquier otro proceso que decida esconderse detrás del mismo binario, porque la regla está definida por nombre genérico y no por hash, ruta ni proceso padre. A partir de ese momento, la máquina del desarrollador —normalmente la que tiene acceso a repositorios privados, tokens de despliegue y credenciales SSH— pasa a ser un punto ciego permanente para el EDR, justo donde más falta hace la visibilidad.

• Cualquier malware que abuse de node.exe o python.exe queda invisible bajo la misma excepción, sin relación real con el agente de código.
• El equipo de seguridad pierde telemetría exactamente en la máquina con acceso a repos, secretos y credenciales de despliegue.
• Las auditorías de compliance (ISO 27001, ENS) suelen señalar la excepción como hallazgo cuando no está acotada por hash ni ruta.
• Ningún analista vuelve a revisar alertas de esa carpeta, así que un compromiso real camuflado ahí tarda mucho más en detectarse.

• Excluir por hash del binario, ruta exacta y proceso padre concreto — nunca por nombre genérico como node.exe o npm.cmd.
• Restringir el egress a los dominios reales del proveedor (api.anthropic.com, api.openai.com, el dominio de Cursor) en lugar de permitir todo saliente desde esa carpeta.
• Ejecutar el agente con un usuario o contenedor separado, sin acceso directo a credenciales de producción ni a claves SSH del resto del equipo.
• Mantener el registro de comandos ejecutados por el agente fuera del propio proceso, para que un agente comprometido no pueda borrar su propio rastro.
• Revisar qué repositorios y ramas toca el agente habitualmente: una desviación de ese patrón es señal real, no ruido de EDR.
• Firmar y revisar los commits generados por el agente igual que los de una persona; ningún merge automático sin revisión humana.

Hay señales que separan el ruido habitual de un agente de código de un compromiso genuino, y conviene tenerlas escritas antes de que suene la alerta, no improvisarlas en caliente. Una conexión saliente hacia un dominio que no corresponde a la API conocida del proveedor es la primera bandera roja seria. El acceso del agente a ficheros de credenciales, claves privadas o variables de entorno que quedan fuera de su ámbito de trabajo habitual es la segunda. Cualquier intento de persistencia —tareas programadas, entradas de arranque, claves de registro— generado desde ese árbol de procesos no tiene justificación legítima en ningún flujo de trabajo de desarrollo. Y si la actividad sospechosa empieza justo después de que el agente abriera un PR externo, una dependencia nueva o un fichero de un repositorio no confiable, hay que asumir inyección de instrucciones hasta demostrar lo contrario, no descartarlo como falso positivo.

No toda PYME necesita un SOC dedicado ni contratar más servicios de monitorización solo para convivir con Claude Code o Cursor. Si el equipo de desarrollo es pequeño y las máquinas donde corre el agente no tienen acceso directo a producción ni a datos sensibles, la respuesta más barata y más efectiva suele ser simplemente no ejecutar el agente en la misma máquina que gestiona secretos de despliegue: un entorno de desarrollo aislado resuelve el problema sin tocar la política EDR de toda la organización. Definir reglas EDR a medida por hash y proceso padre solo empieza a justificarse a partir de cierto tamaño de equipo, cuando las máquinas de desarrollo sí tienen acceso real a sistemas críticos y el coste de una excepción mal acotada deja de ser hipotético.

La mayoría de alertas de EDR sobre Claude Code o Cursor que hemos revisado en clientes son ruido explicable. El problema casi nunca es el agente: es que casi ninguna empresa acota la excepción lo suficiente como para seguir viendo lo que sí importa.

Ante una alerta ya generada, el primer paso es aislar el proceso sin matarlo de inmediato, para poder revisar el árbol completo y qué comando concreto disparó la regla. El segundo es verificar que el hash del binario corresponde a una release firmada y conocida del agente, no a una copia modificada o a un binario con el mismo nombre en una ruta distinta. El tercero es contrastar el destino de la conexión saliente contra la lista de dominios oficiales del proveedor: si no coincide, se activa el playbook de respuesta a incidentes, no el descarte automático. Documentar cada excepción EDR con fecha, hash y responsable convierte esta gestión en algo auditable en lugar de en una carpeta olvidada.