Durante meses, buena parte de la conversación sobre seguridad de agentes se ha quedado atrapada en una idea única: el prompt injection. Es comprensible. Es un problema visible, demostrable y fácil de explicar. Pero en cuanto un sistema deja de limitarse a responder y empieza a usar herramientas, leer recursos externos y ejecutar acciones, el foco de riesgo se desplaza. Ya no basta con preguntar qué texto puede manipular al modelo. Hay que preguntarse con qué identidad actúa, qué permisos hereda y quién gobierna la relación entre el agente y sus herramientas. Ahí es donde el Model Context Protocol deja de ser una comodidad de integración y pasa a convertirse en un problema de arquitectura de seguridad.
Anthropic presentó MCP en noviembre de 2024 como un estándar abierto para conectar aplicaciones de IA con fuentes de datos y herramientas externas. La documentación oficial del protocolo describe una arquitectura host–client–server en la que un host puede conectarse a múltiples servidores MCP, descubrir capacidades y exponer al modelo recursos, herramientas y prompts. OpenAI ya documenta también el uso de connectors y servidores MCP remotos para dar nuevas capacidades a los modelos, lo que confirma que no estamos ante una curiosidad experimental, sino ante una capa que empieza a consolidarse en productos reales.
De la entrada de texto a la delegación de autoridad
Pensar MCP como “otro sistema de plugins” lleva a subestimar el problema. En una API clásica, el desarrollador decide de forma explícita qué llamada se hace, con qué parámetros y bajo qué credenciales. En MCP, parte de esa mediación se desplaza al sistema agéntico: el cliente descubre las herramientas disponibles, registra esas capacidades y el modelo puede invocarlas durante la interacción según el contexto. La propia arquitectura oficial de MCP explica que el protocolo es stateful y que el conjunto de herramientas puede cambiar dinámicamente durante una sesión. Eso mejora la flexibilidad, pero también convierte el entorno de ejecución en un espacio mucho más difícil de gobernar.
Ese matiz técnico tiene consecuencias directas. La especificación de autorización de MCP no trata el protocolo como una simple tubería de datos, sino como un marco en el que un cliente puede solicitar acceso a servidores restringidos en nombre de propietarios de recursos. Dicho de forma más clara: MCP introduce un plano donde se delega capacidad operativa. No se trata solo de que el modelo “vea” más cosas; se trata de que puede actuar a través de componentes que concentran permisos, contexto y conectividad. Cuando un agente encadena varias herramientas sobre sistemas distintos, el verdadero perímetro de seguridad ya no está en el prompt, sino en la delegación de autoridad.
Los riesgos de seguridad en MCP no se parecen a los de un plugin normal
La documentación oficial de Security Best Practices de MCP es reveladora porque no gira alrededor de un único vector, sino de una constelación de problemas clásicos de seguridad reapareciendo en contexto agéntico: confused deputy, token passthrough, SSRF, secuestro de sesión, compromiso de servidores locales y necesidad de minimización de privilegios. Es decir, la conversación técnica se está desplazando desde la manipulación semántica del modelo hacia los problemas duros de identidad, autorización y separación de responsabilidades.
El caso de confused deputy es especialmente ilustrativo. La guía de seguridad de MCP advierte de escenarios en los que un servidor proxy mal diseñado puede obtener códigos de autorización o redirigir flujos de consentimiento de forma insegura si mezcla mal registro dinámico, client IDs estáticos y cookies de aprobación. No hace falta imaginar una vulnerabilidad exótica: es el viejo problema de la delegación mal contenida, reempaquetado dentro de sistemas agénticos. Cuando un agente opera entre varios servicios, un fallo de diseño en el plano de identidad puede convertir una simple integración en una vía de abuso transversal.
Algo parecido ocurre con el token passthrough. La misma guía lo trata explícitamente como un antipatrón: aceptar un token emitido para otro servicio y reenviarlo aguas abajo sin validación estricta degrada el aislamiento entre componentes, rompe la atribución y complica la auditoría. En una arquitectura con agentes, esa pérdida de trazabilidad es más grave que en software convencional, porque las decisiones de ejecución ya no están codificadas de forma determinista línea a línea, sino condicionadas por contexto, herramientas disponibles y orquestación dinámica. Sin atribución fuerte, una organización no sabe si está observando una acción legítima, una escalada de privilegios o una cadena de llamadas inducida de manera maliciosa.
Servidores MCP de terceros: una nueva cadena de suministro
Aquí aparece el problema que muchas organizaciones todavía no están formulando bien. Conectar un agente a un servidor MCP de terceros no equivale a instalar una extensión inocua. La guía de OWASP A Practical Guide for Secure MCP Server Development insiste en que los servidores MCP deben evaluarse teniendo en cuenta permisos delegados, arquitecturas basadas en herramientas y llamadas encadenadas. Y la guía complementaria de OWASP para terceros, A Practical Guide for Securely Using Third-Party MCP Servers 1.0, enumera riesgos como tool poisoning, prompt injection, memory poisoning e interferencia entre herramientas.
Eso obliga a cambiar el lenguaje. Un servidor MCP de terceros no aporta solo una función. Aporta también una descripción de herramientas, una forma de exponer recursos, un modelo de entrada y salida, una política de autorización y, en la práctica, una determinada manera de inducir decisiones operativas dentro del agente. En otras palabras: no solo amplía capacidad, también modela conducta. Por eso tiene más sentido hablar de cadena de suministro cognitiva y operativa que de simple ecosistema de integraciones. Cada servidor nuevo añade superficie de ataque, dependencias semánticas y confianza prestada.
La web ya está funcionando como superficie de entrega para agentes
Este punto importa especialmente para una línea editorial como la de RosmarOps, donde la manipulación de visibilidad, el crawling y la guerra de información no son temas periféricos. El informe de Unit 42, Web-Based Indirect Prompt Injection Observed in the Wild, documenta ataques observados en la naturaleza en los que contenido web oculto o manipulado acaba influyendo en sistemas basados en LLM. El propio informe menciona casos que van desde instrucciones embebidas para alterar el comportamiento del modelo hasta evasión de revisión publicitaria asistida por IA. También señala un dato importante: por ahora, buena parte de los casos observados parecen oportunistas y de impacto limitado, más cercanos a manipulación táctica que a sabotaje de gran escala.
Ese detalle no reduce la gravedad del problema; la vuelve más interesante. Lo que Unit 42 está mostrando es que la web ya no es solo un repositorio de información para humanos. También es una superficie donde se depositan instrucciones, sesgos y cebos destinados a sistemas automáticos que rastrean, resumen, clasifican y, cada vez más, actúan. Cuando esa capa de contenido se acopla con herramientas con permisos reales vía MCP, el salto cualitativo es evidente: la manipulación semántica puede convertirse en ejecución material. La frontera entre content poisoning y abuso operativo se vuelve mucho más fina.
Cómo debería pensarse una arquitectura defensiva para MCP
La primera decisión defensiva razonable es separar con claridad lectura y acción. No todas las herramientas deben vivir en el mismo régimen de confianza. Un servidor que solo expone recursos documentales no merece el mismo tratamiento que otro capaz de modificar registros, enviar correos, abrir incidencias o interactuar con sistemas críticos. La documentación de OpenAI sobre MCP and Connectors deja claro que las llamadas pueden ejecutarse de forma automática o requerir aprobación. Esa distinción no es un detalle de producto: es una política de seguridad. En entornos sensibles, la automatización completa de acciones con efecto externo debería ser excepcional y estar muy acotada.
La segunda es asumir que la identidad del agente necesita controles más finos que un único token largo y sobreprovisionado. La guía de seguridad de MCP insiste en consentimiento por cliente, validación estricta del parámetro state, rechazo del token passthrough y aplicación real de mínimo privilegio. Traducido a operación, eso significa scopes cortos, sesiones limitadas, elevación puntual, revocación sencilla y vinculación fuerte entre usuario, cliente y servidor. En un sistema agéntico, “dar acceso” ya no es una frase aceptable. Hay que autorizar qué capacidad concreta puede ejercerse, durante cuánto tiempo y bajo qué evidencia de consentimiento.
La tercera es tratar los servidores MCP como componentes de alto privilegio. OWASP recomienda revisar procedencia, aplicar sandboxing cuando sea posible, endurecer despliegues, validar entradas con rigor y mantener supervisión humana en capacidades de mayor impacto. Eso aleja a MCP de la cultura de “instalar y probar” que dominó durante años los ecosistemas de extensiones y automatización ligera. Si el servidor tiene acceso a datos sensibles o puede disparar acciones, su evaluación debe parecerse más a la de un componente crítico de infraestructura que a la de una integración menor.
El debate estratégico ya se está moviendo hacia identidad y autorización
No es casualidad que NIST haya lanzado en febrero de 2026 su AI Agent Standards Initiative, orientada a promover un ecosistema interoperable y seguro para agentes. Tampoco es casualidad que el NCCoE haya publicado el concept paper Accelerating the Adoption of Software and AI Agent Identity and Authorization, centrado precisamente en identidad y autorización para agentes de software e IA. La señal institucional es bastante nítida: el debate maduro sobre agentes ya no se está organizando solo alrededor de la calidad del modelo, sino alrededor de los mecanismos que permiten identificar, limitar, autorizar y auditar su actuación.
Mi lectura es que ahí se juega una parte importante de la soberanía tecnológica real. Se puede discutir durante años sobre modelos fundacionales, nubes o dependencia de proveedores, pero si el plano de herramientas, permisos y conectores queda externalizado sin control fuerte, la autonomía sigue siendo parcial. En sistemas agénticos, quien controla el acceso, la mediación y la capacidad de actuar controla buena parte del poder efectivo del sistema. MCP no es un accesorio de interoperabilidad. Es el lugar donde la IA deja de ser solo interfaz y empieza a convertirse en infraestructura.