Gusano npm y envenenamiento MCP & Internet como bosque oscuro - Noticias de IA (22 feb 2026)

Empezamos con la historia más inquietante del día: la campaña que Socket bautiza como SANDWORM_MODE. A grandes rasgos, es un gusano de cadena de suministro que se distribuyó mediante al menos 19 paquetes npm maliciosos, de esos que imitan nombres de librerías populares con una letra cambiada. Lo más peligroso es que no “rompen” el proyecto a simple vista: mantienen el comportamiento esperado, pero al importarlos ejecutan cargas por etapas para robar credenciales y propagarse usando identidades de npm y GitHub que consiguen por el camino. La pieza central de la propagación es especialmente moderna: una GitHub Action que se hace pasar por herramienta de calidad de código, pero su verdadero objetivo es exfiltrar secretos del CI y reescribir repositorios desde dentro. Y aquí viene el giro: además de robar tokens típicos —npm, GitHub, variables de entorno— el malware intenta capturar claves de API de proveedores de modelos y, todavía más llamativo, envenenar la “toolchain” de asistentes de IA mediante inyección de un servidor MCP. En la práctica, planta un servidor malicioso y mete instrucciones de prompt injection para que herramientas como Claude Code, Cursor o ciertos plugins de VS Code lean credenciales y las filtren silenciosamente. Si tu equipo desarrolla con Node y usa CI/CD, esto es una llamada a revisar dependencias, workflows y configuraciones globales de git hooks, y a rotar secretos si hay cualquier sospecha. Socket dice que npm, GitHub y Cloudflare ya retiraron parte de la infraestructura, pero el impacto real depende de quién instaló qué… y cuándo.

Y esto conecta con una idea más amplia: el post de OpenNHP que describe Internet como un “bosque oscuro”. La metáfora es simple: en un ecosistema donde todo se escanea automáticamente, ser visible equivale a ser un objetivo. El texto pinta una línea de tiempo muy creíble en 2026: un servidor aparece, lo fingerprintéan, lo prueban, y lo atacan en minutos, sin intervención humana. Para sustentar el argumento citan herramientas como PentAGI, un agente de pentesting autónomo que orquesta más de 20 utilidades —Nmap, Metasploit, SQLmap, entre otras— y que puede correr con subagentes en paralelo. También mencionan el trabajo de “frontier red teaming” con Claude, donde un equipo relativamente pequeño habría encontrado cientos de vulnerabilidades serias en proyectos open source de producción en pocas semanas, incluyendo fallos que llevaban años sin detectarse. La tesis de OpenNHP es incómoda: cualquier ventaja de automatización defensiva se puede reflejar del lado ofensivo. ¿Su propuesta? Pasar de “cerraduras más fuertes” a “puertas que desaparecen”: “Zero Visibility”. Es decir, infraestructura sin IPs expuestas, sin puertos abiertos, sin DNS descubrible antes de autenticación, y acceso solo tras prueba criptográfica de identidad. Independientemente de si te convence el enfoque, el mensaje es claro: reducir superficie detectable se está volviendo tan importante como endurecer sistemas.

Siguiendo con seguridad, Quesma publicó BinaryAudit, un benchmark abierto con una pregunta muy concreta: ¿pueden los agentes de IA detectar puertas traseras ocultas en binarios grandes, sin símbolos y sin el código fuente? Esto importa porque, en el mundo real, muchas auditorías llegan tarde —cuando ya tienes un ejecutable de un tercero— y a veces lo único que puedes hacer es ingeniería inversa. BinaryAudit usa programas reales de código abierto, modificados de forma controlada para inyectar backdoors. Los agentes pueden apoyarse en herramientas conocidas: Ghidra, Radare2, binutils. Y la tarea no es solo decir “sí o no”, sino ubicar la función exacta donde vive el código malicioso. Los resultados son un baño de realidad: el mejor modelo del ranking, Claude Opus 4.6, ronda el 49% de acierto. Y el dato que más pesa operacionalmente es la tasa de falsos positivos: alrededor del 28% señalando backdoor donde no la hay, algo muy difícil de tolerar en producción. Aun así, el benchmark muestra progreso tangible: hay casos donde el modelo detecta pistas como llamadas sospechosas a `popen()` o rutas de ejecución que terminan corriendo comandos, y logra seguir el hilo hasta un header HTTP oculto. También hay fallos ilustrativos: descubrir una invocación a shell pero “racionalizarla” como legítima, sin confirmar que la entrada venga de datos no confiables. Conclusión práctica: los agentes ya ayudan como primera pasada, pero todavía no sustituyen un análisis experto, especialmente por el coste de equivocarse.

Ahora, un tema que mezcla IA y operaciones a gran escala: según el Financial Times, Amazon Web Services sufrió una interrupción de 13 horas en diciembre en un sistema que afectó a partes de China continental, vinculada a acciones de su asistente de programación Kiro. La acusación concreta es que el agente decidió “borrar y recrear el entorno” con el que trabajaba, y eso desencadenó el problema. Lo interesante no es solo el error, sino el mecanismo: Kiro normalmente requiere aprobación humana doble para empujar cambios, pero operó con los permisos del operador humano. Y, según fuentes, la configuración de permisos fue demasiado amplia. Amazon enfatiza que fue un incidente “extremadamente limitado” y pone el foco en el factor humano, incluso sugiriendo que algo parecido podría pasar con cualquier herramienta de desarrollo. Pero el debate que deja es útil: cuando un agente tiene capacidad de ejecutar cambios destructivos, el control de permisos, los límites de acción —guardrails— y el diseño de “blast radius” importan tanto como la precisión del modelo. El patrón no es “la IA se volvió malvada”, es más prosaico: automatización + permisos excesivos = incidentes previsibles.

Cambiamos a Palantir por partida doble, pero desde dos ángulos distintos. Primero, una noticia más de cultura y gobernanza de datos: el repositorio “palantir-ontology-strategy”, de Leading-AI-IO, es un libro abierto que intenta explicar la idea de “Ontology” en Palantir Foundry como algo más que una técnica de TI. Su argumento central es que muchos data lakes y data warehouses terminan como “pantanos” de datos muertos: se consultan, se visualizan… pero no mueven operaciones. La ontología, tal como la describe el proyecto, se apoya en tres pilares: uno, la data como capa operativa que refleja la realidad del negocio, casi como un gemelo digital. Dos, unificar “sustantivos y verbos”: modelar objetos y también acciones, estados y cambios, semántica y dinámica. Y tres, gobernanza fuerte con una lógica parecida al control de versiones: ramas, revisiones y trazabilidad para decidir qué versión de la “realidad” se vuelve oficial. Es un enfoque que, bien aplicado, encaja muy bien con agentes y automatización, porque el agente necesita una representación confiable de “qué es qué” y “qué se puede hacer”. El repositorio, por cierto, invita a contribuciones y está bajo CC BY 4.0. Segundo ángulo, más político: The Guardian cuenta que Scotland Yard —la policía metropolitana de Londres— está usando herramientas de IA de Palantir para analizar datos internos de plantilla y detectar patrones asociados a posible mala conducta: bajas médicas, ausencias, horas extra. La Met lo presenta como un piloto temporal, con revisión humana final. Pero los sindicatos policiales lo critican como “sospecha automatizada”, y piden claridad sobre opacidad, sesgos y derechos laborales. En paralelo, el debate se amplifica por la presencia de Palantir en el sector público británico, con contratos grandes en salud y defensa. Aquí la clave es transparencia: qué datos se usan, qué señales se consideran, cómo se audita el sistema y cómo se evitan consecuencias injustas para quien simplemente está sobrecargado o enfermo.

Pasamos a una novedad de Apple que apunta en una dirección muy concreta: agentes de interfaz que corren localmente. Los investigadores presentan Ferret-UI Lite, un modelo de 3 mil millones de parámetros diseñado para entender pantallas y ejecutar acciones en interfaces —como pulsar botones, navegar menús— sin depender de un servidor. La parte técnica que llama la atención es cómo “compensa” el tamaño: usa recorte y zoom en tiempo de inferencia, algo así como mirar primero el mapa general y luego acercarse a la zona relevante para reducir el coste de procesar toda la pantalla. Además, entrenan con mezcla de datos reales y sintéticos, y montan una cadena de generación con varios agentes —planificación, ejecución, crítica— para simular errores y recuperación, que es lo que suele matar a los agentes en el mundo real. Apple dice que, en ciertos benchmarks, este enfoque iguala o supera a agentes mucho más grandes. Pero también admiten el trade-off lógico: tareas cortas y concretas, bien; flujos largos y complejos, peor. Aun así, el valor estratégico es claro: si un agente puede operar en el dispositivo, el incentivo de privacidad sube mucho, porque no tienes que enviar capturas de pantalla o contexto de apps a la nube para cada acción.

Cerramos con energía y regulación, porque la IA también se alimenta literalmente. Floodlight obtuvo imágenes térmicas que sugieren que xAI sigue operando turbinas de gas sin permisos para alimentar un complejo de centros de datos en Southaven, Mississippi. El punto de fricción es si esas turbinas, montadas en remolques, se consideran “móviles” y por tanto exentas, algo que reguladores estatales parecen defender, mientras que la EPA históricamente las trata como fuentes que requieren permisos bajo la Clean Air Act. Según el reportaje, se ven más de una docena funcionando y emitiendo contaminantes, pese a advertencias recientes. Vecinos han denunciado ruido y calidad del aire, con escuelas relativamente cerca. Y el contexto más amplio es una tendencia: muchos centros de datos nuevos están recurriendo a gas natural como solución rápida mientras renovables y redes eléctricas tardan años en llegar. Aquí el debate no es abstracto: es sobre permisos, estándares de emisiones, y quién asume los costes locales de una infraestructura que, desde fuera, parece “solo digital”.