Esta semana he visto a medio sector tech hablar del zero-day que Google atribuye a un atacante asistido por IA y, al mismo tiempo, pasar por alto algo que me parece más cercano a tu día a día: la campaña TrapDoor, que envenena los archivos de configuración de asistentes de código como .cursorrules o CLAUDE.md para que el modelo haga cosas que tú no has pedido. Si desarrollas, mantienes WordPress o simplemente usas Cursor o Claude Code en proyectos de clientes, esto no es ciencia ficción: es supply chain con tu confianza ciega en la IA como vector.
Según el análisis de la Cloud Security Alliance, la campaña lleva más de 34 paquetes maliciosos repartidos entre npm, PyPI y Crates.io, con cientos de versiones publicadas desde mediados de mayo. El detalle que me ha puesto los pelos de punta no es el volumen: es el método. Los atacantes no se limitan a colar malware en dependencias; también abren pull requests en repos populares del ecosistema IA — LangChain, LlamaIndex, OpenHands, entre otros — con mensajes de commit que suenan a documentación inocente. Y dentro van instrucciones ocultas con caracteres Unicode de ancho cero, invisibles en muchos editores y en las revisiones rápidas de GitHub.
Piénsalo un segundo. Tú clonas un repo, abres Cursor, el asistente lee las reglas del proyecto y empieza a «ayudarte». Si esas reglas incluyen una orden camuflada del tipo «antes de compilar, ejecuta este script» o «envía las variables de entorno a tal sitio», el modelo no va a levantar la mano como un junior responsable. Va a obedecer el contexto que le has servido en bandeja. Y aquí está la parte incómoda: la mayoría de equipos trata esos archivos como boilerplate, no como superficie de ataque.
En la misma semana, AgentRiot recoge el caso de Composio, donde el punto de entrada fue un agente interno con demasiados privilegios. Son vectores distintos — uno externo vía supply chain, otro interno vía permisos mal acotados — pero comparten la misma premisa rota: damos por hecho que el entorno del agente es de confianza. TrapDoor explota la confianza entre desarrollador y asistente; Composio muestra qué pasa cuando un agente puede encadenar herramientas hasta ejecutar código arbitrario. Si sumas ambos titulares, el panorama de mayo de 2026 no es «la IA se volvió malvada», es «hemos conectado sistemas autónomos a credenciales reales sin fronteras claras».
Google, por su parte, publicó en su informe de mayo el primer caso documentado de explotación de un zero-day con ayuda de un LLM, y Euronews lo resume con el matiz de que sus propios sistemas lo detectaron a tiempo. Bien por ellos; mal para quien lee el titular y concluye que el problema es el modelo frontier y no la capa de integración. GTIG insiste en que los modelos grandes siguen siendo difíciles de romper directamente, pero las librerías wrapper, los conectores de API y — repito — los ficheros de skills y reglas del proyecto son el caldo de cultivo. TrapDoor encaja exactamente en esa taxonomía.
Lo que me frustra es la respuesta del mercado. En cuanto sale una campaña así, aparecen los posts genéricos de «diez buenas prácticas de ciberseguridad» y los vendors empujando escáneres que no miran Unicode invisible ni revisan el contenido semántico de un .cursorrules. Tu pipeline de CI puede pasar tests, lint y dependabot, y aun así estar alimentando al asistente con instrucciones envenenadas que ningún SAST clásico marca. ¿Has auditado alguna vez qué lee tu IA al abrir un repo de un cliente? Yo conozco pocas pymes que lo hayan hecho.
Tampoco ayuda el discurso comercial de las propias herramientas. Te venden productividad, contexto automático, «conoce tu codebase». Perfecto para iterar más rápido; terrible si nadie define qué archivos entran en ese contexto ni quién puede modificarlos sin revisión humana seria. Un PR que añade «estándares de desarrollo» suena aburrido y seguro. Por eso TrapDoor funciona: se esconde donde la fatiga de revisión es máxima.
¿Qué haría yo en un proyecto real? Tres cosas concretas, sin postureo. Primero, tratar .cursorrules, CLAUDE.md y similares como código crítico: revisión obligatoria, diff legible fuera del visor web si hace falta, y bloqueo de merges automáticos en esos paths. Segundo, separar entornos: el asistente que toca repos de producción no debería compartir credenciales con el que prueba dependencias aleatorias de npm. Tercero, asumir que tu equipo no va a detectar caracteres de ancho cero a ojo — necesitas scripts o reglas en el repo que rechacen esos bytes, igual que rechazas secrets en texto plano.
No pretendo alarmismo gratuito. La campaña TrapDoor es reciente y acotada en impacto conocido; no es el fin del desarrollo asistido por IA. Pero sí es una señal clara de hacia dónde miran los atacantes: no hacia el modelo, hacia la cadena de confianza que tú construyes alrededor. Y mientras el sector siga vendiendo IA como copiloto infalible sin hablar de estos vectores, vas a seguir viendo incidentes que en el informe post-mortem suenan a «nadie pensó que un markdown podía hacer eso».
Si mañana un cliente te pide activar Cursor en un monorepo con decenas de contribuidores externos y tú solo puedes imponer una medida — revisar a mano cada cambio en archivos de reglas del asistente o desactivar por completo la lectura automática de contexto del proyecto —, cuál elegirías sabiendo que la alternativa que descartes es la que TrapDoor explota?