Conectaste una herramienta a tu agente para resolver algo concreto. Leer una carpeta, consultar una base de datos, abrir un navegador. Meses después sigue ahí, con los mismos accesos. No ha pasado nada. Ese es precisamente el problema.
En noviembre de 2024, Anthropic presentó el Model Context Protocol, un estándar abierto para que los modelos de lenguaje se conectaran con herramientas, fuentes de datos y otros sistemas. En menos de dos años se ha convertido en la forma habitual de dar manos a un agente: un servidor MCP por cada cosa que queremos que haga, y el agente decidiendo cuándo usarlo. La comodidad es evidente. Lo que no es tan evidente es qué hemos montado cuando llevamos una docena conectados.
Breaking the Model Context Protocol: Agentic Attacks and Defenses for MCP-Powered AI Systems, de Srinivasan Sekar y Thejes Sree Satheesh Kumar (Apress, 2026), se ocupa justo de esa pregunta. Sekar trabaja construyendo plataformas de IA sobre MCP; Satheesh Kumar se dedica a las estrategias defensivas para estos ecosistemas y habla con frecuencia en conferencias de seguridad como NullCon. Es un libro técnico, con laboratorios y casos de ataque, pero su tesis de fondo se entiende sin necesidad de escribir una línea de código.
Cuando el cliente es un modelo, cambian las fronteras de confianza
La seguridad informática clásica se construyó sobre una idea bastante estable: un programa hace lo que su código dice, y el código lo escriben personas que responden de él. Las fronteras de confianza se trazaban alrededor de eso. Este usuario puede leer esto, este proceso puede escribir aquello.
Sekar y Satheesh Kumar parten de que esos supuestos dejan de valer cuando el cliente que usa las herramientas es un modelo de lenguaje. Las herramientas siguen siendo deterministas: leen el archivo que se les pide, ejecutan la orden que reciben. Pero quien decide qué pedirles es un sistema probabilístico que interpreta texto. Y ese texto le llega de muchas partes: de la persona que lo usa, sí, pero también de las descripciones de las propias herramientas, de las respuestas que devuelven, de las páginas que lee y de los documentos que abre.
De ahí salen los ataques que el libro recorre con laboratorios prácticos: el envenenamiento de herramientas, que esconde instrucciones en la descripción o en la respuesta de un servidor; el camuflaje de firmas; los abusos de los mecanismos con los que un servidor puede pedirle cosas al modelo. Lo que tienen en común es incómodo. No hace falta romper nada. Basta con que el modelo lea algo y lo trate como una orden.
Un intermediario legítimo también puede ser el problema
Uno de los capítulos del libro se titula, en traducción libre, «El adjunto confundido: el agente con demasiadas llaves». El concepto que da nombre al capítulo es bastante más antiguo que los agentes. En 1988, Norm Hardy publicó un artículo breve, «The Confused Deputy», que describía un problema aparentemente doméstico. Un compilador tenía permiso para escribir en un archivo de facturación del sistema, porque lo necesitaba para registrar su uso. Un usuario sin ese permiso le pidió que guardara el resultado de su trabajo justo en ese archivo. El compilador obedeció: él sí podía. El archivo quedó destruido.
Nadie había atacado nada en el sentido clásico. El compilador era legítimo, el usuario no tenía privilegios especiales y cada pieza hacía lo que debía. El fallo estaba en que un intermediario con permisos amplios actuaba en nombre de alguien que no los tenía, sin distinguir con qué autoridad lo hacía.
Un agente conectado a una docena de herramientas es, en ese sentido, el adjunto perfecto. Tiene acceso a lo que le hemos dado, que suele ser bastante, y actúa a partir de instrucciones que le llegan por canales que no siempre distingue: lo que pide la persona, lo que dice una página, lo que devuelve otra herramienta. Si una de esas fuentes consigue que el agente haga algo, lo hará con todas las llaves que lleva encima. El peligro no es el intruso. Es el intermediario de confianza con demasiado acceso.
El permiso que nadie recuerda haber dado
Lo que hace este riesgo especialmente difícil de gestionar no es la sofisticación de los ataques, sino la forma en que se acumulan los permisos. Cada conexión tiene sentido en el momento en que se hace. Un servidor para leer el repositorio, otro para consultar la base de datos de pruebas, otro para el navegador, otro para el calendario. Ninguna decisión es temeraria por separado.
El problema aparece en la suma y en el tiempo. Al cabo de unos meses, el agente tiene un alcance que nadie ha decidido como tal: es el resultado de veinte decisiones pequeñas, cada una olvidada en cuanto se tomó. Las configuraciones por defecto de los propios agentes, además, cambian de una versión a otra, a veces en direcciones que nadie revisa. Y lo que queda es una pregunta que muy poca gente sabría responder sobre su propio ordenador: qué puede hacer hoy, exactamente, cada uno de mis agentes.
Suena a higiene menor, hasta que se recuerda lo que dice el libro: el daño no exige que el agente quiera hacer nada malo. Exige solo que tenga acceso y que alguien consiga dirigirlo.
Lo que no se ve no se puede retirar
Antes de defenderse de un ataque hay que saber qué tiene uno expuesto. Es una idea antigua en seguridad y la razón de ser de RosmarOps, una herramienta que estoy construyendo y que intenta responder a esa pregunta previa. Se ejecuta en el ordenador, solo lee y no cambia nada: revisa la configuración de los agentes de programación instalados y dibuja un mapa de lo que cada uno puede leer, modificar y qué claves alcanza. Devuelve una puntuación por agente y el primer cambio que conviene hacer. Es de código abierto, que en una herramienta de seguridad no es un detalle: cualquiera puede comprobar qué hace.
Hay que ser igual de claro con lo que no hace, porque es justo lo que el libro enseña a no olvidar. RosmarOps analiza configuraciones y exposiciones potenciales. No detecta ataques mientras ocurren ni vigila lo que hace un agente en tiempo real. Hoy puntúa unos pocos agentes y solo detecta otros. Y no encontrar nada no significa que un sistema sea seguro: significa que, en lo que la herramienta sabe mirar, no ha visto un problema. En seguridad, esa diferencia no es un matiz.
Explicar qué puede hacer una herramienta es parte de su seguridad
La pregunta tiene también una cara que me afecta del otro lado. UXMachine, el otro producto que construyo, se conecta a agentes para que puedan medir una web en un navegador real. Es decir, es una de esas herramientas que se añaden al entorno de un agente. Y el libro obliga a hacerse la pregunta incómoda: qué capacidades estoy añadiendo cuando alguien la conecta.
Hay una decisión de diseño que ilustra bien el principio. Para medir una web que todavía está en el ordenador de quien la desarrolla, UXMachine abre un túnel temporal que se cierra solo a los treinta minutos. No es una medida espectacular. Es un permiso con caducidad, que es exactamente lo que suele faltar en los permisos que se acumulan sin que nadie los recuerde.
No quiero sacar de ahí más de lo que da. Que una herramienta explique qué hace, qué datos recibe y cuánto dura su acceso no la vuelve segura. La vuelve auditable, que es la condición previa. Cualquier servidor MCP legítimo debería poder contestar esas tres preguntas en una página, y cualquiera que lo conecte debería poder leerla antes.
Menos llaves, no mejores cerraduras
En 1975, Jerome Saltzer y Michael Schroeder publicaron «The Protection of Information in Computer Systems», uno de los textos fundacionales de la seguridad informática. Entre sus principios estaba el del mínimo privilegio: cada programa y cada usuario deberían operar con el menor conjunto de permisos necesario para su tarea. Medio siglo después, sigue siendo la defensa más eficaz y la más incumplida.
Con los agentes se vuelve más urgente, porque la tentación va en la dirección contraria. Un agente con más acceso es más útil, resuelve más cosas sin pedir permiso, molesta menos. Cada llave que le damos tiene una justificación inmediata. Retirarla, en cambio, no tiene ninguna, porque el beneficio de no tenerla solo se ve el día que algo sale mal.
Hay, eso sí, un límite. Hoy describimos las superficies de ataque de estos sistemas bastante mejor de lo que sabemos medir con qué frecuencia se explotan de verdad. El riesgo es real y está bien documentado. Su frecuencia, todavía no la conocemos.
Mientras tanto, hay un gesto sencillo que no exige esperar a los datos. Antes de conectar otra herramienta, revisar las que ya tienen acceso.
