Los equipos de seguridad no paran de preguntarme qué significa realmente la seguridad de MCP. No en el sentido de «por favor, defina el acrónimo». Sino en el de «encontramos tres servidores MCP ejecutándose en los portátiles de los desarrolladores y nadie sabe quién es responsable de ellos». Esa es la verdadera pregunta. Y es distinta de las preguntas que la mayoría de las guías de seguridad de API están diseñadas para responder.
La seguridad de MCP no es la seguridad de API con un nombre nuevo. El protocolo crea una relación de confianza entre los agentes de IA y los sistemas de producción que la mayoría de los controles existentes nunca se diseñaron para inspeccionar. Una puerta de enlace de API estándar vigila el perímetro. MCP entrega a un agente de IA las llaves de lo que hay dentro y luego le pide que resuelva la gobernanza más adelante.
Esta es la parte que los equipos aprenden demasiado tarde.
La superficie de ataque para la que nadie presupuestó
- MCP crea una ruta de confianza bidireccional entre agentes de IA y sistemas internos que las puertas de enlace de API estándar no inspeccionan.
- El 53 % de los servidores MCP utiliza secretos estáticos de larga duración, exactamente el patrón de credenciales que facilita los ataques a la cadena de suministro.
- El secuestro a nivel de registro es posible sin ninguna vulnerabilidad a nivel de código; los metadatos por sí solos son suficientes.
- Un LLM reforzado y sistemas subyacentes reforzados aún le dejan expuesto si la capa de servidores MCP no está controlada.
- Las vulnerabilidades clásicas se aplican a gran escala: 43 % de inyección de comandos y 22 % de recorrido de rutas en las implementaciones analizadas.
Qué significa realmente la seguridad de MCP
La seguridad de MCP abarca los controles, las salvaguardas y la monitorización aplicados a hosts, servidores y registros MCP para evitar la exposición de datos, la ejecución no autorizada de herramientas y el abuso a nivel de protocolo. Esta definición parece manejable hasta que observa todo lo que debe cubrir en la práctica.
La seguridad de API estándar protege un límite de solicitud/respuesta. Usted autentica en el perímetro, valida las entradas y registra lo que cruza la línea. MCP hace algo estructuralmente diferente. Crea una relación de confianza bidireccional entre un agente de IA y los sistemas a los que se conecta, lo que significa que el agente no solo consulta un recurso: puede invocar herramientas, leer archivos, ejecutar comandos y encadenar esas acciones entre varios sistemas conectados. El agente de IA está dentro del perímetro. El servidor actúa como puente.
Ese puente es lo que la mayoría de las puertas de enlace de API no están diseñadas para inspeccionar. Pueden ver que se produjo una solicitud. Por lo general, no pueden ver qué se le indicó al agente de IA, qué herramienta decidió llamar o si la descripción de herramienta en la que confió fue manipulada antes de llegar a él. La superficie de ataque se extiende a la capa de protocolo, al registro donde se descubren los servidores y al entorno host donde se ejecuta el agente. Ninguna de esas capas existe en una integración de API convencional.
Esta distinción importa porque los equipos que tratan MCP como «una integración más» aplican los controles equivocados, auditan los registros equivocados y pasan por alto los fallos equivocados, normalmente hasta que algo ya ha movido datos que no debería haber movido.
Cómo funciona MCP y dónde se sitúa el límite de confianza
El Protocolo de Contexto de Modelo tiene tres componentes, y cada uno conlleva un problema distinto de límite de confianza. Entenderlos por separado no es un ejercicio académico. Es la diferencia entre saber dónde colocar los controles e instalarlos en el lugar equivocado.
El host es el entorno donde se ejecuta realmente el agente de IA. Un IDE como Claude Desktop o Cursor es un host. También lo es una plataforma de orquestación, un ejecutor de canalizaciones de agentes o una aplicación personalizada que incorpora un modelo de IA. El host decide a qué servidores puede acceder el agente, gestiona cómo se construye el contexto del agente y, en última instancia, determina el radio de impacto si algo sale mal. Un host comprometido o mal configurado no expone una sola herramienta. Expone todo lo que el agente puede ver desde ese entorno.
El cliente es el conector a nivel de protocolo. Gestiona la comunicación real entre el host y un servidor MCP específico: inicia sesiones, envía solicitudes y recibe respuestas de herramientas. El cliente es lo que traduce la intención de un agente en una llamada de red concreta.
El servidor es lo que expone herramientas, recursos y prompts al agente. Es el componente que se encuentra más cerca de sus sistemas reales: sus bases de datos, sus repositorios de código fuente, sus API de nube. Cuando el agente llama a una herramienta, el servidor la ejecuta. Esa ejecución puede leer archivos, activar canalizaciones de CI/CD, ejecutar consultas o llamar a API descendentes, según lo que exponga el servidor.
Lo importante aquí es que estos componentes forman una cadena de confianza delegada. El host confía en el cliente. El cliente confía en el servidor. El servidor confía en las definiciones de herramientas que expone. Un atacante que pueda influir en cualquier eslabón de esa cadena puede influir en el comportamiento del agente, no atacando directamente al LLM, sino manipulando el entorno en el que opera el LLM.
Host MCP y cliente MCP: qué controla cada componente
Los equipos confunden estos dos conceptos constantemente. He visto a arquitectos de seguridad definir controles para la capa del cliente porque ahí es donde ocurre la actividad de red, mientras pasan por alto por completo que el host es donde realmente se definen los permisos del agente.
El host MCP controla el entorno de ejecución más amplio. Define a qué servidores puede conectarse el agente, gestiona la configuración local del servidor MCP y determina qué contexto recibe el agente. El host es donde debería establecerse primero el perímetro de seguridad, porque gobierna todo el espacio de acción del agente. Un host mal configurado implica un radio de impacto mal configurado.
El cliente MCP envía solicitudes a nivel de protocolo a un servidor específico. Es un conector, no un regulador. El cliente no decide qué puede hacer el agente; esa es la función del host. Pero el cliente sí establece la sesión, gestiona la autenticación y administra la capa de transporte para cada conexión de servidor. Es un punto de control más limitado de lo que la mayoría de los equipos asume al escuchar «cliente».
MCP opera con estos dos componentes trabajando de forma secuencial. El host establece el entorno; el cliente ejecuta dentro de él. Si no los distingue, terminará con los controles de acceso en el lugar equivocado, que es exactamente donde comienzan la mayoría de las configuraciones erróneas.
Dónde encaja el servidor MCP en una canalización de IA agéntica
El servidor MCP es el objetivo de mayor valor de la canalización. Todo lo que el agente de IA puede hacer realmente pasa por él. Uno o más servidores MCP exponen las herramientas, recursos y prompts que el agente puede invocar, y «herramientas» en este contexto significa acceso real a sistemas: leer un archivo, consultar una base de datos, enviar código, llamar a una API externa o enviar una notificación.
Cuando un agente de IA realiza una llamada al servidor MCP, no está haciendo una pregunta. Está solicitando una acción. La respuesta del servidor determina lo que el agente hará después. Las herramientas disponibles se enumeran en el manifiesto del servidor, y el agente selecciona entre ellas según sus instrucciones y contexto. Por eso la seguridad del servidor MCP importa más de lo que puede parecer desde fuera: controle el servidor y controlará las acciones del agente. Comprometa el servidor y la canalización de IA agéntica se convertirá en un mecanismo de entrega para cualquier cosa que el atacante quiera ejecutar.
Aquí es donde suele comenzar el incidente.
Riesgos de seguridad de MCP que realmente encontrará
Los riesgos en una implementación de MCP no son casos extremos hipotéticos redactados por investigadores que buscan ponencias para conferencias. Son medibles, reproducibles, y varios de ellos están presentes en la mayoría de las implementaciones reales. El panorama de amenazas se divide en varias categorías distintas, y requieren defensas diferentes.
Envenenamiento de contexto e inyección indirecta de prompts mediante MCP
Esto toma a los equipos por sorpresa porque desde fuera no parece una vulnerabilidad. Un actor malicioso no necesita atacar el modelo de IA ni la base de datos subyacente. Solo necesita introducir contenido malicioso en la ventana de contexto del modelo mediante MCP: a través de un documento que lee el agente, una respuesta de API que recibe o una salida de herramienta que procesa.
Una vez que ese contenido está en el contexto, puede emitir instrucciones al modelo que anulen o redirijan su comportamiento. El usuario no lo ve. La interfaz visible parece normal. Pero el agente puede estar exfiltrando credenciales, enviando datos a un endpoint controlado por el atacante o realizando acciones que el usuario nunca autorizó, todo porque una entrada externa en el entorno MCP se lo indicó. Invariant Labs ha demostrado esta clase de ataque con ejemplos funcionales contra implementaciones reales de MCP. La defensa no consiste en confiar más en el modelo. Consiste en separar el contenido externo no confiable para que nunca llegue al contexto del modelo como una entrada con instrucciones.
Inyección de comandos, recorrido de rutas y SSRF: vulnerabilidades clásicas que siguen aplicándose
Una idea errónea recurrente es que la seguridad de MCP trata principalmente de la inyección de prompts, un problema de IA que requiere defensas de IA. Los datos indican lo contrario.
Un estudio empírico de implementaciones de MCP descubrió que el 43 % de los servidores analizados presentaba fallos de inyección de comandos, el 22 % permitía recorrido de rutas o lecturas arbitrarias de archivos y el 30 % tenía vulnerabilidades SSRF. Son debilidades tradicionales de aplicaciones web que aparecen en herramientas de IA a niveles que resultarían alarmantes en cualquier otro contexto. Se aplican aquí porque los servidores MCP aceptan entradas, las transmiten a comandos del sistema y operaciones de archivos, y realizan solicitudes de red salientes: todos los mismos patrones que producen estas vulnerabilidades en aplicaciones convencionales.
El enfoque de MCP no cambia la mecánica subyacente. Un servidor que transmite una entrada sin sanitizar a un comando de shell es vulnerable a la inyección de comandos tanto si un LLM generó esa entrada como si la escribió una persona. Lo que cambia con MCP es el alcance del atacante: puede influir en la entrada sin tocar nunca directamente el servidor, manipulando lo que se indicó al agente de IA que enviara.
📊 En cifras:
En las implementaciones de MCP analizadas, casi la mitad presentaba fallos explotables de inyección de comandos y casi un tercio tenía vulnerabilidades SSRF. No son casos extremos ni exposiciones teóricas: son las mismas clases de vulnerabilidades que causaron brechas importantes en la infraestructura web convencional, y ahora aparecen en la capa que otorga a los agentes de IA acceso directo a los sistemas internos.
Secuestro de servidores a nivel de registro y riesgo de cadena de suministro
Este es el aspecto que refuta de forma más directa el argumento de que «si reforzamos el LLM y los sistemas subyacentes, MCP es solo infraestructura».
Un estudio de medición de 67.057 servidores MCP en seis registros públicos encontró 833 servidores vulnerables y 18 con descripciones sospechosas que permitían la manipulación de invocaciones y el secuestro a nivel de registro. El ataque no requiere una vulnerabilidad a nivel de código. Bastan controles de propiedad débiles y metadatos no confiables en el registro. Un atacante que pueda insertar un servidor malicioso o modificado en el registro que descubre un agente o desarrollador puede moldear el razonamiento del modelo y el comportamiento del agente a escala, antes de que el agente llegue siquiera al LLM reforzado o a la base de datos reforzada.
Los servidores MCP de terceros obtenidos de registros públicos conllevan un riesgo de cadena de suministro comparable al de paquetes npm no evaluados y, en el ecosistema MCP, la infraestructura de evaluación es mucho menos madura. Los investigadores de seguridad han demostrado ataques de envenenamiento de herramientas en los que descripciones de servidores aparentemente inocuas contenían instrucciones ocultas que hacían que los agentes exfiltraran datos o redirigieran acciones sin ninguna indicación visible para el usuario final. La capa de descubrimiento del ecosistema MCP es una superficie de ataque. Los equipos que no la tratan como tal están haciendo una suposición que los datos no respaldan.
Controles de seguridad que realmente reducen el riesgo de MCP de teórico a gestionable
Aquí termina la teoría. Los siguientes controles abordan los modos de fallo específicos descritos anteriormente, no la categoría general de «proteger sistemas de IA». Se basan en la guía práctica de MCP de Coalition for Secure AI y la investigación de Astrix Security sobre las prácticas de credenciales de MCP.
Autenticación, autorización y acceso a herramientas con privilegios mínimos
Comience por la identidad. Toda conexión a un servidor MCP debería requerir una autenticación sólida. TLS como mínimo; TLS mutuo para conexiones de servidor a servidor en las que usted controle ambos extremos. Las credenciales deberían ser de corta duración y tener un alcance limitado, no claves API almacenadas en variables de entorno, que el «Estado de la seguridad de servidores MCP 2025» de Astrix Security encontró en el 79 % de las implementaciones y que son exactamente el tipo de secreto estático que facilita el robo de credenciales.
La autorización de MCP debería limitarse exactamente a lo que el agente de IA necesita para la tarea que está realizando, no a lo que resulta cómodo exponer. Una herramienta que un agente necesita para leer registros de CRM no debería tener también acceso de escritura, a menos que el flujo lo requiera explícitamente. Tratar las herramientas MCP como un límite de confianza, como recomienda la comunidad de seguridad, significa restringir el acceso a directorios y API específicos en lugar de conceder permisos amplios y confiar en que el modelo se mantenga dentro de los límites.
Una lista de comprobación práctica para comenzar:
- Sustituya las claves API estáticas por OAuth o tokens de corta duración Actualmente, solo el 8,5 % de los servidores MCP utiliza OAuth. Ese número debe ser mucho mayor en cualquier implementación que usted controle.
- Limite el alcance de las credenciales por herramienta, no por servidor Un servidor que expone diez herramientas no debería usar un único conjunto de credenciales con acceso a todo lo que las diez herramientas podrían necesitar teóricamente.
- Rote los secretos según un calendario, no tras una brecha Si la rotación de credenciales requiere pasos manuales, no ocurrirá de forma consistente. Automatícela o acepte que no sucederá.
- Audite trimestralmente el alcance de permisos de las herramientas Las herramientas disponibles acumulan alcance con el tiempo. Lo que comenzó como acceso de solo lectura tiende a expandirse. Revíselo.
Validación de entradas, ejecución aislada y qué no registrar
Dadas las tasas de inyección de comandos y recorrido de rutas en implementaciones reales, tratar todas las entradas externas como no confiables no es opcional. Valide y sanitice todo antes de que llegue a una herramienta que ejecute comandos, lea archivos o realice solicitudes salientes. Esto no es específico de MCP: es una práctica estándar de programación segura que el enfoque de IA a veces lleva a los equipos a omitir porque creen que el modelo es la capa de validación. No lo es.
La ejecución aislada limita el radio de impacto cuando algo logra atravesar los controles. Un servidor MCP que genera procesos secundarios o accede al sistema de archivos local debería ejecutarse en un entorno donde esas capacidades estén limitadas explícitamente: directorios específicos, destinos de red específicos y sin acceso a secretos de producción desde el entorno aislado. Los límites estrictos de sistema de archivos y red son una práctica recomendada por una razón: un servidor MCP local con acceso ilimitado al sistema de archivos es una vulnerabilidad de recorrido de rutas esperando a que alguien encuentre la entrada adecuada.
Sobre los registros: audite cada invocación de herramienta. Registre qué se llamó, con qué argumentos y qué se devolvió. Pero un servidor MCP malicioso podría intentar extraer tokens sensibles de los registros si esos registros son accesibles. No registre valores de credenciales sin procesar, tokens de autenticación ni secretos que aparezcan en las cargas útiles. Registre lo suficiente para reconstruir lo ocurrido, pero no lo suficiente como para entregar a un atacante lo que necesita si el registro se ve comprometido. Esta es la recomendación de Black Hills Information Security que los equipos omiten sistemáticamente.
Monitorización de interacciones MCP y mantenimiento de la visibilidad en todo el grafo
Un servidor MCP no realiza una única llamada de API. Puede activar cadenas de llamadas a herramientas en varios sistemas, y esas cadenas pueden ramificarse. Una única interacción comprometida puede propagarse por un flujo de maneras invisibles en los registros de cualquier sistema individual, pero claramente visibles en una vista a nivel de grafo de la secuencia de interacción.
La monitorización continua de implementaciones MCP implica rastrear no solo si se llamó a una herramienta, sino también qué llamó posteriormente. Vigile: llamadas a herramientas hacia recursos fuera de su alcance esperado, patrones de argumentos inusuales (cadenas largas en rutas del sistema de archivos, direcciones de red inesperadas), fallos de autenticación en invocaciones de herramientas y cualquier herramienta que de repente comience a ejecutarse con una frecuencia superior a su referencia habitual. Los archivos de configuración de servidores MCP obsoletos también son una señal: un servidor que no se ha modificado en seis meses puede haberse desviado de su postura de seguridad original sin que nadie lo note.
Los equipos que desarrollan esto en Latenode tienen una ventaja: AI Agent Builder permite una orquestación de varios pasos donde cada acción del agente es un paso discreto del flujo con su propio registro de ejecución. Esto significa que las cadenas de llamadas a herramientas se vuelven visibles como secuencias de ejecución estructuradas en lugar de rastros de inferencia opacos: una forma práctica de obtener la visibilidad a nivel de grafo que requiere la monitorización de MCP, sin crear desde cero una pila de observabilidad personalizada.
Quién necesita realmente controles de seguridad de MCP y qué intenta evitar
Tres equipos están lidiando ahora mismo con versiones diferentes de este problema. Cada uno intenta prevenir un fallo específico, no una categoría general de «riesgo de seguridad de IA».
Equipos de seguridad e ingeniería de plataformas que exponen datos de observabilidad y CI/CD a agentes de IA
Estos equipos conectan agentes de IA a canalizaciones de implementación, sistemas de monitorización y API de infraestructura para que los desarrolladores puedan consultar el estado de las compilaciones, activar reversión de cambios o investigar incidentes mediante una interfaz conversacional. Lo que intentan evitar es una vía de producción sin control: un agente que puede leer registros de implementación también puede, en condiciones equivocadas, activar implementaciones. El modelo de amenazas es un alcance de herramientas mal configurado junto con una inyección de prompts suficientemente persuasiva en un informe de incidentes o una entrada de registro. El control que más suelen echar en falta es el acceso a herramientas con privilegios mínimos: acceso de lectura y acceso de escritura claramente separados en la capa del servidor MCP. La adopción de IA en este contexto avanza con la rapidez suficiente como para que los controles de seguridad se añadan después, que es precisamente cuando la exposición ya se ha producido.
Equipos de experiencia de desarrollador y herramientas de IA que crean integraciones de IDE y flujos de asistentes de código
Estos equipos conectan servidores MCP a repositorios de código fuente, rastreadores de incidencias y sistemas de revisión de código para que los asistentes de IA ayuden a los desarrolladores a encontrar contexto, sugerir correcciones y comprender bases de código. Lo que intentan evitar son cambios de código no autorizados y la exfiltración de credenciales mediante envenenamiento de herramientas: un servidor MCP de terceros que parece una herramienta útil de búsqueda de código, pero contiene instrucciones ocultas en la descripción de su herramienta que redirigen al agente para exfiltrar claves API de archivos .env. Los profesionales de seguridad en este ámbito tratan cada vez más cada entrada de registro MCP de terceros del mismo modo que los equipos de seguridad de aplicaciones tratan los paquetes npm no evaluados: como un artefacto no confiable que requiere revisión antes de usarse en producción. Los asistentes de IA con acceso a repositorios de código son objetivos de alto valor, y el vector de cadena de suministro del registro es el que la mayoría de los equipos de herramientas para desarrolladores aún no ha tenido plenamente en cuenta.
Equipos de AppSec y DevSecOps que intentan anticiparse a una nueva superficie de seguridad de IA
Estos equipos se enfrentan a MCP como TI en la sombra: siguen apareciendo nuevas herramientas de IA en entornos de producción, cada una con su propia configuración de servidor MCP, sin inventario central y con alcances de acceso poco claros. Lo que intentan evitar son el secuestro de registros y las rutas de acceso no contabilizadas: situaciones en las que se ha concedido a un agente acceso a un sistema cuya auditoría exige conformidad, pero nadie añadió el servidor MCP al inventario de activos porque un desarrollador lo instaló un viernes por la tarde. El nuevo desafío de IA aquí no es técnico. Es de gobernanza. Los propios agentes están cada vez mejor gobernados; los servidores a los que se conectan no lo están.
Tres ideas erróneas sobre la seguridad de MCP que crean brechas reales
Estas tres ideas erróneas aparecen repetidamente antes de los incidentes. No en la etapa teórica, donde sería fácil corregirlas. En la etapa de diseño, donde determinan la arquitectura.
Primera idea errónea: MCP es solo otro sistema de complementos, así que los controles de seguridad de API lo cubren. Esto parece razonable hasta que se observa el modelo de confianza. Una integración de API convencional tiene un cliente definido, un endpoint definido y un conjunto fijo de operaciones que el cliente puede solicitar. MCP permite a un agente de IA descubrir e invocar herramientas dinámicamente según su contexto e instrucciones en tiempo de ejecución. Las decisiones del agente están determinadas por entradas que la pila de seguridad a menudo nunca procesa: descripciones de herramientas, contexto inyectado desde documentos externos y metadatos del registro. Los controles de API estándar no pueden auditar lo que se indicó al agente que decidiera; solo pueden observar lo que solicitó posteriormente. Esa brecha es la superficie de ataque específica de MCP.
Segunda idea errónea: si el LLM está reforzado y los sistemas subyacentes están reforzados, MCP es un detalle secundario de middleware. Este es el enfoque en el que más a menudo caen los equipos preocupados por la seguridad, y también por eso es el más peligroso. Los equipos que han invertido mucho en la seguridad del LLM y el refuerzo de infraestructura suelen tratar MCP como una tubería: el conducto entre dos elementos seguros. Pero ese conducto es exactamente la ruta de ataque que identificó la investigación a escala de registros. El estudio de arXiv sobre 67.057 servidores encontró condiciones para el secuestro a nivel de registro en registros públicos sin ninguna vulnerabilidad a nivel de código en los sistemas subyacentes. El agente solo puede actuar mediante herramientas MCP. Controle las herramientas y controlará el agente, independientemente de lo reforzado que esté el modelo o la base de datos que hay detrás.
🤔 Espere.
Si un agente de IA solo puede actuar mediante herramientas MCP, un servidor MCP comprometido tiene acceso directo a todo aquello para lo que se concedió permiso al agente. El entrenamiento de seguridad del LLM no ayuda en este caso: el entrenamiento de seguridad trata de lo que el modelo se niega a generar, no de lo que una instrucción de herramienta manipulada le indica que ejecute. El radio de impacto de un servidor comprometido es exactamente igual al alcance de permisos del servidor. ¿Ha revisado ese alcance recientemente?
Tercera idea errónea: la inyección de prompts es el único problema real de seguridad de MCP, así que si la gestiona, estará cubierto. Las estadísticas de inyección y SSRF de Equixly lo refutan directamente. 43 % de inyección de comandos, 30 % de SSRF, 22 % de recorrido de rutas: son vulnerabilidades de infraestructura clásicas que aparecen en herramientas de IA a tasas que activarían programas de corrección en cualquier contexto convencional. La inyección de prompts es una clase de amenaza real e importante. No es la única. Los servidores MCP aceptan entradas de agentes de IA y ejecutan operaciones reales contra sistemas reales. Son servicios accesibles mediante web. Deberían tratarse con las mismas prácticas de desarrollo seguro que cualquier otro servicio accesible mediante web.
Sigo viendo equipos que omiten el trabajo sobre vulnerabilidades clásicas porque la conversación sobre seguridad de MCP ha estado dominada por los vectores de ataque específicos de IA. Ese enfoque es preciso hasta cierto punto. No llega lo suficientemente lejos.
Cómo será el futuro de la seguridad de MCP a medida que madure el ecosistema
Algunas cosas están claramente en marcha. Otras son problemas verdaderamente abiertos que ningún proveedor ni organismo de estándares ha resuelto.
La gobernanza de registros es la brecha más evidente. La conversación sobre listas de comprobación de seguridad de MCP ha madurado rápidamente durante el último año, pero todavía no existe un proceso estandarizado de verificación de servidores para registros públicos. Cualquiera puede publicar un servidor MCP. La adopción de MCP en las herramientas para desarrolladores ha superado la capacidad del ecosistema para evaluar aquello que se está adoptando. Los servidores MCP remotos descubiertos mediante registros públicos conllevan el mismo riesgo de cadena de suministro que los paquetes de código abierto sin revisar, pero sin siquiera las señales de gobernanza social que las comunidades de npm y PyPI utilizan para identificar paquetes sospechosos.
La firma estandarizada de servidores es la respuesta técnica, pero implementar la firma a nivel del ecosistema MCP requiere coordinación entre varios operadores de registros y proveedores de cadenas de herramientas. Esa coordinación se encuentra en una fase temprana. El hallazgo de Astrix de que el 88 % de los servidores requiere credenciales mientras la mayoría utiliza secretos estáticos sugiere que la capa de identidad necesita trabajo de estandarización antes de que la capa de firma pueda importar.
El abuso de contexto entre agentes es un modelo de amenazas emergente que todavía no está bien definido. A medida que las implementaciones de múltiples MCP se vuelven comunes —un agente invoca herramientas de varios servidores y comparte contexto entre ellos—, la superficie de interacción para el envenenamiento de contexto y la escalada de privilegios crece de formas que los modelos de seguridad de un solo servidor no abordan. ¿Quién asume la responsabilidad de auditar una cadena de contexto que atraviesa tres servidores propiedad de tres equipos? Esa pregunta no tiene una respuesta clara hoy, y espero que genere la primera ola de incidentes graves de IA agéntica cuando alguien lo descubra de la manera difícil.
