Durante meses, buena parte de la conversaci\u00f3n sobre seguridad de agentes se ha quedado atrapada en una idea \u00fanica: el\u00a0prompt injection<\/a><\/em>. Es comprensible. Es un problema visible, demostrable y f\u00e1cil de explicar. Pero en cuanto un sistema deja de limitarse a responder y empieza a\u00a0usar herramientas, leer recursos externos y ejecutar acciones<\/strong>, el foco de riesgo se desplaza. Ya no basta con preguntar qu\u00e9 texto puede manipular al modelo. Hay que preguntarse\u00a0con qu\u00e9 identidad act\u00faa, qu\u00e9 permisos hereda y qui\u00e9n gobierna la relaci\u00f3n entre el agente y sus herramientas<\/strong>. Ah\u00ed es donde el\u00a0Model Context Protocol<\/a>\u00a0deja de ser una comodidad de integraci\u00f3n y pasa a convertirse en un problema de arquitectura de seguridad.<\/p>\n\n\n\n Anthropic present\u00f3 MCP en noviembre de 2024 como un est\u00e1ndar abierto para conectar aplicaciones de IA con fuentes de datos y herramientas externas. La documentaci\u00f3n oficial del protocolo describe una arquitectura host\u2013client\u2013server<\/strong> en la que un host puede conectarse a m\u00faltiples servidores MCP, descubrir capacidades y exponer al modelo recursos, herramientas y prompts. OpenAI ya documenta tambi\u00e9n el uso de connectors y servidores MCP remotos<\/a> 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.<\/p>\n\n\n\n Pensar MCP como \u201cotro sistema de plugins\u201d lleva a subestimar el problema. En una API cl\u00e1sica, el desarrollador decide de forma expl\u00edcita qu\u00e9 llamada se hace, con qu\u00e9 par\u00e1metros y bajo qu\u00e9 credenciales. En MCP, parte de esa mediaci\u00f3n se desplaza al sistema ag\u00e9ntico: el cliente descubre las herramientas disponibles, registra esas capacidades y el modelo puede invocarlas durante la interacci\u00f3n seg\u00fan el contexto. La propia arquitectura oficial de MCP<\/a> explica que el protocolo es stateful<\/em> y que el conjunto de herramientas puede cambiar din\u00e1micamente durante una sesi\u00f3n. Eso mejora la flexibilidad, pero tambi\u00e9n convierte el entorno de ejecuci\u00f3n en un espacio mucho m\u00e1s dif\u00edcil de gobernar.<\/p>\n\n\n\n Ese matiz t\u00e9cnico tiene consecuencias directas. La especificaci\u00f3n de autorizaci\u00f3n de MCP<\/a> no trata el protocolo como una simple tuber\u00eda 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\u00e1s clara: MCP introduce un plano donde se delega capacidad operativa. No se trata solo de que el modelo \u201cvea\u201d m\u00e1s cosas; se trata de que puede actuar a trav\u00e9s de componentes que concentran permisos, contexto y conectividad. Cuando un agente encadena varias herramientas sobre sistemas distintos, el verdadero per\u00edmetro de seguridad ya no est\u00e1 en el prompt, sino en la delegaci\u00f3n de autoridad<\/strong>.<\/p>\n\n\n\n La documentaci\u00f3n oficial de Security Best Practices<\/a> de MCP es reveladora porque no gira alrededor de un \u00fanico vector, sino de una constelaci\u00f3n de problemas cl\u00e1sicos de seguridad reapareciendo en contexto ag\u00e9ntico: confused deputy<\/em>, token passthrough<\/em>, SSRF, secuestro de sesi\u00f3n, compromiso de servidores locales y necesidad de minimizaci\u00f3n de privilegios. Es decir, la conversaci\u00f3n t\u00e9cnica se est\u00e1 desplazando desde la manipulaci\u00f3n sem\u00e1ntica del modelo hacia los problemas duros de identidad, autorizaci\u00f3n y separaci\u00f3n de responsabilidades.<\/p>\n\n\n\n El caso de confused deputy<\/em> es especialmente ilustrativo. La gu\u00eda de seguridad de MCP advierte de escenarios en los que un servidor proxy mal dise\u00f1ado puede obtener c\u00f3digos de autorizaci\u00f3n o redirigir flujos de consentimiento de forma insegura si mezcla mal registro din\u00e1mico, client IDs<\/em> est\u00e1ticos y cookies de aprobaci\u00f3n. No hace falta imaginar una vulnerabilidad ex\u00f3tica: es el viejo problema de la delegaci\u00f3n mal contenida, reempaquetado dentro de sistemas ag\u00e9nticos. Cuando un agente opera entre varios servicios, un fallo de dise\u00f1o en el plano de identidad puede convertir una simple integraci\u00f3n en una v\u00eda de abuso transversal.<\/p>\n\n\n\n Algo parecido ocurre con el token passthrough<\/em>. La misma gu\u00eda lo trata expl\u00edcitamente como un antipatr\u00f3n: aceptar un token emitido para otro servicio y reenviarlo aguas abajo sin validaci\u00f3n estricta degrada el aislamiento entre componentes, rompe la atribuci\u00f3n y complica la auditor\u00eda. En una arquitectura con agentes, esa p\u00e9rdida de trazabilidad es m\u00e1s grave que en software convencional, porque las decisiones de ejecuci\u00f3n ya no est\u00e1n codificadas de forma determinista l\u00ednea a l\u00ednea, sino condicionadas por contexto, herramientas disponibles y orquestaci\u00f3n din\u00e1mica. Sin atribuci\u00f3n fuerte, una organizaci\u00f3n no sabe si est\u00e1 observando una acci\u00f3n leg\u00edtima, una escalada de privilegios o una cadena de llamadas inducida de manera maliciosa.<\/p>\n\n\n\n Aqu\u00ed aparece el problema que muchas organizaciones todav\u00eda no est\u00e1n formulando bien. Conectar un agente a un servidor MCP de terceros no equivale a instalar una extensi\u00f3n inocua. La gu\u00eda de OWASP A Practical Guide for Secure MCP Server Development<\/em><\/a> insiste en que los servidores MCP deben evaluarse teniendo en cuenta permisos delegados, arquitecturas basadas en herramientas y llamadas encadenadas<\/strong>. Y la gu\u00eda complementaria de OWASP para terceros, A Practical Guide for Securely Using Third-Party MCP Servers 1.0<\/em><\/a>, enumera riesgos como tool poisoning<\/em>, prompt injection<\/em>, memory poisoning<\/em> e interferencia entre herramientas.<\/p>\n\n\n\n Eso obliga a cambiar el lenguaje. Un servidor MCP de terceros no aporta solo una funci\u00f3n. Aporta tambi\u00e9n una descripci\u00f3n de herramientas, una forma de exponer recursos, un modelo de entrada y salida, una pol\u00edtica de autorizaci\u00f3n y, en la pr\u00e1ctica, una determinada manera de inducir decisiones operativas dentro del agente. En otras palabras: no solo ampl\u00eda capacidad, tambi\u00e9n modela conducta. Por eso tiene m\u00e1s sentido hablar de cadena de suministro cognitiva y operativa<\/strong> que de simple ecosistema de integraciones. Cada servidor nuevo a\u00f1ade superficie de ataque, dependencias sem\u00e1nticas y confianza prestada.<\/p>\n\n\n\n Este punto importa especialmente para una l\u00ednea editorial como la de RosmarOps, donde la manipulaci\u00f3n de visibilidad, el crawling<\/em> y la guerra de informaci\u00f3n no son temas perif\u00e9ricos. El informe de Unit 42, Web-Based Indirect Prompt Injection Observed in the Wild<\/em><\/a>, 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\u00f3n de revisi\u00f3n publicitaria asistida por IA. Tambi\u00e9n se\u00f1ala un dato importante: por ahora, buena parte de los casos observados parecen oportunistas y de impacto limitado, m\u00e1s cercanos a manipulaci\u00f3n t\u00e1ctica que a sabotaje de gran escala.<\/p>\n\n\n\n Ese detalle no reduce la gravedad del problema; la vuelve m\u00e1s interesante. Lo que Unit 42 est\u00e1 mostrando es que la web ya no es solo un repositorio de informaci\u00f3n para humanos. Tambi\u00e9n es una superficie donde se depositan instrucciones, sesgos y cebos destinados a sistemas autom\u00e1ticos que rastrean, resumen, clasifican y, cada vez m\u00e1s, act\u00faan. Cuando esa capa de contenido se acopla con herramientas con permisos reales v\u00eda MCP, el salto cualitativo es evidente: la manipulaci\u00f3n sem\u00e1ntica puede convertirse en ejecuci\u00f3n material. La frontera entre content poisoning<\/em> y abuso operativo se vuelve mucho m\u00e1s fina.<\/p>\n\n\n\n La primera decisi\u00f3n defensiva razonable es separar con claridad lectura<\/strong> y acci\u00f3n<\/strong>. No todas las herramientas deben vivir en el mismo r\u00e9gimen 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\u00edticos. La documentaci\u00f3n de OpenAI sobre MCP and Connectors<\/a> deja claro que las llamadas pueden ejecutarse de forma autom\u00e1tica o requerir aprobaci\u00f3n. Esa distinci\u00f3n no es un detalle de producto: es una pol\u00edtica de seguridad. En entornos sensibles, la automatizaci\u00f3n completa de acciones con efecto externo deber\u00eda ser excepcional y estar muy acotada.<\/p>\n\n\n\n La segunda es asumir que la identidad del agente necesita controles m\u00e1s finos que un \u00fanico token largo y sobreprovisionado. La gu\u00eda de seguridad de MCP insiste en consentimiento por cliente, validaci\u00f3n estricta del par\u00e1metro state<\/em>, rechazo del token passthrough<\/em> y aplicaci\u00f3n real de m\u00ednimo privilegio. Traducido a operaci\u00f3n, eso significa scopes<\/em> cortos, sesiones limitadas, elevaci\u00f3n puntual, revocaci\u00f3n sencilla y vinculaci\u00f3n fuerte entre usuario, cliente y servidor. En un sistema ag\u00e9ntico, \u201cdar acceso\u201d ya no es una frase aceptable. Hay que autorizar qu\u00e9 capacidad concreta puede ejercerse, durante cu\u00e1nto tiempo y bajo qu\u00e9 evidencia de consentimiento<\/strong>.<\/p>\n\n\n\n La tercera es tratar los servidores MCP como componentes de alto privilegio. OWASP recomienda revisar procedencia, aplicar sandboxing<\/em> cuando sea posible, endurecer despliegues, validar entradas con rigor y mantener supervisi\u00f3n humana en capacidades de mayor impacto. Eso aleja a MCP de la cultura de \u201cinstalar y probar\u201d que domin\u00f3 durante a\u00f1os los ecosistemas de extensiones y automatizaci\u00f3n ligera. Si el servidor tiene acceso a datos sensibles o puede disparar acciones, su evaluaci\u00f3n debe parecerse m\u00e1s a la de un componente cr\u00edtico de infraestructura que a la de una integraci\u00f3n menor.<\/p>\n\n\n\n No es casualidad que NIST haya lanzado en febrero de 2026 su AI Agent Standards Initiative<\/a>, orientada a promover un ecosistema interoperable y seguro para agentes. Tampoco es casualidad que el NCCoE haya publicado el concept paper<\/em> Accelerating the Adoption of Software and AI Agent Identity and Authorization<\/em><\/a>, centrado precisamente en identidad y autorizaci\u00f3n para agentes de software e IA. La se\u00f1al institucional es bastante n\u00edtida: el debate maduro sobre agentes ya no se est\u00e1 organizando solo alrededor de la calidad del modelo, sino alrededor de los mecanismos que permiten identificar, limitar, autorizar y auditar su actuaci\u00f3n.<\/p>\n\n\n\n Mi lectura es que ah\u00ed se juega una parte importante de la soberan\u00eda tecnol\u00f3gica real. Se puede discutir durante a\u00f1os sobre modelos fundacionales, nubes o dependencia de proveedores, pero si el plano de herramientas, permisos y conectores queda externalizado sin control fuerte, la autonom\u00eda sigue siendo parcial. En sistemas ag\u00e9nticos, quien controla el acceso, la mediaci\u00f3n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" Durante meses, buena parte de la conversaci\u00f3n sobre seguridad de agentes se ha quedado atrapada en una idea \u00fanica: el\u00a0prompt injection. Es comprensible. Es un problema visible, demostrable y f\u00e1cil de explicar. Pero en cuanto un sistema deja de limitarse a responder y empieza a\u00a0usar herramientas, leer recursos externos y ejecutar acciones, el foco de … Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":814,"comment_status":"closed","ping_status":"closed","sticky":true,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,59],"tags":[79,84,105,181,214,218,235,245,266,294],"class_list":["post-812","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ciberseguridad-en-ia","category-prompt-injection","tag-agentes-de-ia","tag-ai-security","tag-autorizacion","tag-identidad-digital","tag-mcp","tag-model-context-protocol","tag-owasp","tag-prompt-injection","tag-seguridad-de-agentes","tag-tool-use"],"_links":{"self":[{"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/posts\/812","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/comments?post=812"}],"version-history":[{"count":1,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/posts\/812\/revisions"}],"predecessor-version":[{"id":987,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/posts\/812\/revisions\/987"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/media\/814"}],"wp:attachment":[{"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/media?parent=812"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/categories?post=812"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/tags?post=812"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}De la entrada de texto a la delegaci\u00f3n de autoridad<\/h2>\n\n\n\n
Los riesgos de seguridad en MCP no se parecen a los de un plugin normal<\/h2>\n\n\n\n
Servidores MCP de terceros: una nueva cadena de suministro<\/h2>\n\n\n\n
La web ya est\u00e1 funcionando como superficie de entrega para agentes<\/h2>\n\n\n\n
C\u00f3mo deber\u00eda pensarse una arquitectura defensiva para MCP<\/h2>\n\n\n\n
El debate estrat\u00e9gico ya se est\u00e1 moviendo hacia identidad y autorizaci\u00f3n<\/h2>\n\n\n\n