Comprender los flujos tóxicos en MCP y el riesgo oculto de los sistemas nativos de IA

La mayoría de las conversaciones sobre seguridad de IA todavía se centran en los prompts, los modelos y el acceso directo a los datos. Esas áreas son importantes, pero cuando se permite que un agente de IA llame herramientas, invoque API y actúe en varios sistemas, el riesgo real cambia. Ya no se trata únicamente de lo que el modelo puede ver, sino de lo que el agente puede hacer cuando empieza a combinar herramientas por su cuenta.

Este es el contexto en el que cobra importancia el concepto de flujo tóxico.

Un flujo tóxico es una secuencia de acciones de un agente que lleva un entorno desde instrucciones controladas por un atacante hasta datos confidenciales y, luego, a un punto de exfiltración. No es necesario que ninguno de los pasos individuales sea malicioso. Cada herramienta puede estar haciendo exactamente aquello para lo que fue diseñada. El peligro está en la ruta de extremo a extremo que se crea cuando se combinan herramientas, datos e instrucciones bajo el control de un agente de IA.

Model Context Protocol (MCP) amplifica ambos lados de esta ecuación. MCP estandariza la forma en que los modelos y agentes se conectan con herramientas, repositorios, servicios y fuentes de datos. Para los equipos de desarrollo, esto representa una clara ventaja: obtienen una forma consistente de integrar la IA en los flujos de trabajo cotidianos, como leer incidencias, actualizar tickets, consultar registros, modificar código y ejecutar scripts. Al mismo tiempo, MCP proporciona a los agentes un conjunto flexible de herramientas que facilita la creación involuntaria de flujos tóxicos.

En una aplicación determinista tradicional, una entrada determinada sigue una ruta definida a través del código. Los ingenieros pueden enumerar esas rutas, probarlas y analizar sus propiedades de seguridad. Un agente basado en MCP se comporta de otra manera. Puede elegir entre muchas herramientas y usarlas en distintos órdenes según las instrucciones en lenguaje natural, el contexto y las descripciones de las herramientas. Nadie escribe explícitamente todas las secuencias posibles. El modelo elige la ruta en tiempo de ejecución.

Este cambio crea una nueva categoría de exposición. Ya no basta con preguntar si un modelo tiene acceso a secretos o repositorios privados. La pregunta más pertinente es: ¿en qué condiciones decidirá un agente mover datos confidenciales por una cadena de herramientas que, en última instancia, los expone a una parte no confiable?

“Flujo tóxico” es el término que describe esa cadena. Recalca que el riesgo es emergente. Es una propiedad de la forma en que los datos y el control se mueven a través de muchos componentes, en lugar de ser una simple consecuencia de una sola configuración incorrecta. En los entornos MCP, comprender y controlar esos flujos es esencial porque los agentes ya están conectados a sistemas importantes: entornos de desarrollo, control de código fuente, flujos de trabajo de respuesta a incidentes y servicios cercanos a producción.

La tríada letal: cómo una cadena de herramientas se convierte en una brecha de seguridad

A pesar de la variabilidad del comportamiento de los agentes, el patrón detrás de los flujos tóxicos es notablemente consistente. Al analizar incidentes reales, suelen aparecer juntos tres elementos dentro de una sola ejecución del agente:

• instrucciones influenciadas por un atacante

• acceso a datos confidenciales

• una forma de exfiltrar esos datos

Cuando estas tres condiciones coexisten en un mismo flujo, el entorno queda expuesto, incluso si cada herramienta involucrada se agregó por un motivo legítimo.

Las instrucciones no confiables suelen ser el punto de partida. En un entorno MCP, no se limitan a un prompt de chat. Un atacante puede influir en el contenido de una incidencia de GitHub, un ticket de atención al cliente, un mensaje en un canal de chat monitoreado o cualquier otro objeto que el agente esté configurado para leer. Si el propósito del agente es clasificar, resumir o actuar sobre esos elementos, el atacante ha conseguido una vía para influir en el proceso de razonamiento del agente.

Los datos confidenciales suelen encontrarse detrás de herramientas que se incorporaron para mejorar la productividad. Estas pueden incluir acciones como leer el contenido de repositorios, recuperar archivos de configuración, consultar sistemas de seguimiento de incidencias, obtener registros o acceder a registros internos. Los ingenieros quieren que el agente vea la misma información que usarían para corregir un error o entender un problema de producción. Como resultado, el conjunto de herramientas del agente suele incluir acceso directo a datos de gran valor.

Los puntos de exfiltración son herramientas o canales que pueden sacar datos de sus límites seguros. Algunos ejemplos comunes son los clientes HTTP que pueden llamar a cualquier URL, los conectores que escriben en sistemas de terceros, las integraciones que envían correos electrónicos o mensajes de chat y, en algunos casos, la propia respuesta del modelo cuando quien la recibe no es de confianza. A menudo, estas capacidades se agregan de forma gradual a medida que los equipos conectan sus agentes con más flujos de trabajo.

Un escenario sencillo de MCP ilustra cómo se combinan los elementos de la tríada letal. Pensemos en un servidor MCP conectado a GitHub que impulsa un asistente de desarrollo. El asistente lee incidencias de un repositorio, usa herramientas de MCP para obtener archivos pertinentes y detalles de configuración, y genera resúmenes útiles para quienes mantienen el repositorio. Para admitir pruebas de integración, también se expone una herramienta HTTP que puede enviar solicitudes a cualquier endpoint.

Un atacante abre una incidencia en ese repositorio con instrucciones detalladas. La incidencia afirma que un error complejo solo puede diagnosticarse recopilando archivos de entorno y datos de configuración del código base y, luego, enviándolos como una carga JSON a una URL específica para que un sistema de análisis externo los revise. Desde la perspectiva del agente, parece una solicitud exhaustiva y razonable.

Si el agente sigue esas indicaciones, leerá la incidencia (instrucciones no confiables), recorrerá el repositorio para recopilar archivos de configuración y de entorno (datos confidenciales) e invocará la herramienta HTTP para transmitir esa información a la URL del atacante (punto de exfiltración). Ninguna herramienta individual está configurada incorrectamente de forma evidente. La brecha surge de la manera en que estas herramientas se combinan bajo el control del modelo.

Los controles tradicionales de seguridad de IA tienen dificultades con este patrón. Los filtros de prompts y los firewalls para LLM inspeccionan prompts y respuestas individuales. Tienen poca visibilidad de las llamadas intermedias a herramientas y los movimientos de datos que conectan esos prompts con sistemas externos. El análisis de código valida cómo se implementan las herramientas, no cómo se combinarán en tiempo de ejecución. Las revisiones de acceso confirman que cada herramienta tiene un propósito legítimo, pero rara vez evalúan si el contenido no confiable puede impulsar una secuencia que las conecte en un flujo tóxico.

El resultado es una brecha. Las organizaciones pueden creer que protegieron sus prompts, modelos y herramientas, mientras que el verdadero riesgo está en las cadenas dinámicas de acciones orquestadas mediante MCP. Considerar esta brecha como la “tríada letal” ayuda a centrarse en el problema real: cuando las instrucciones controladas por un atacante, los datos confidenciales y una ruta de exfiltración están al alcance dentro de un mismo flujo, el entorno está en riesgo, sin importar cuán cuidadosamente se haya incorporado cada componente.

Por qué la mayoría de los enfoques de seguridad de IA no detectan los flujos tóxicos

Una vez que se comprende la tríada letal, queda claro que muchos enfoques actuales de seguridad de IA están optimizados para resolver otro tipo de problemas. Se centran en lo que el modelo ve y dice, en lugar de en lo que hace el agente en sistemas interconectados.

Los controles de prompts, los filtros de contenido y los firewalls para LLM suelen ser el primer conjunto de controles que implementan las organizaciones. Estos sistemas inspeccionan las entradas y salidas para buscar infracciones de políticas o términos confidenciales. Pueden reducir el uso indebido evidente y prevenir ciertas categorías de inyección de prompts. Sin embargo, los flujos tóxicos suelen desarrollarse como una serie de pasos aparentemente legítimos. En el ejemplo de GitHub, el asistente parece seguir una solicitud detallada para depurar un problema. Nada en la respuesta final necesariamente revela que se exfiltraron secretos mediante llamadas intermedias a herramientas.

Las herramientas convencionales de seguridad de aplicaciones también se orientan a artefactos estáticos y rutas deterministas. Los analizadores estáticos, el análisis de composición de software y el análisis de infraestructura como código son adecuados para entornos donde el código y la configuración definen todas las acciones permitidas. Pueden validar que las herramientas de MCP estén implementadas de forma segura, que las dependencias estén actualizadas y que los tokens de acceso se administren correctamente. Lo que no pueden detectar con facilidad es que un agente decida encadenar esas herramientas de una forma inesperada a partir de una entrada en lenguaje natural.

El registro y la supervisión en tiempo de ejecución agregan otra capa, pero también tienen limitaciones en este contexto. Los ingenieros pueden recopilar rastros de invocaciones de herramientas, respuestas y errores. También pueden investigar incidentes individuales. El desafío es combinatorio: la cantidad de flujos posibles se dispara cuando se conectan más herramientas y sistemas mediante MCP. Depender de revisiones manuales para detectar patrones peligrosos se vuelve poco práctico, sobre todo cuando el comportamiento del agente puede cambiar con pequeñas variaciones en la entrada o el contexto.

Incluso las ofertas más recientes de seguridad específicas para IA suelen centrarse en verificaciones locales. Pueden imponer restricciones a los parámetros de una herramienta específica o limitar el acceso de un agente concreto a ciertos secretos. Estos controles siguen centrados en los componentes. En general, no analizan rutas completas que comienzan con contenido no confiable y terminan con datos que salen de los límites de confianza.

La consecuencia es una brecha de cobertura: las inversiones en seguridad de modelos, validación de prompts y seguridad de herramientas individuales no se extienden automáticamente al espacio de interacción que crea MCP. El entorno puede parecer bien controlado cuando se examina cada elemento por separado, pero aun así permite flujos tóxicos cuando se combinan.

Para abordar este problema, los equipos de seguridad deben hacer otra pregunta: ¿el entorno permite alguna ruta en la que instrucciones influenciadas por un atacante puedan dirigir datos confidenciales hacia un punto de exfiltración? Toxic Flow Analysis está diseñado para brindar una respuesta estructurada.

Presentamos Toxic Flow Analysis

Toxic Flow Analysis (TFA) ofrece una perspectiva basada en grafos de los sistemas con IA. En lugar de analizar los prompts o las herramientas de forma aislada, representa cómo se conectan los agentes, los servidores MCP, las herramientas y los sistemas subyacentes. Luego, busca rutas que puedan dar lugar a la tríada letal.

El primer paso es representar el entorno. En un contexto MCP, esto incluye los servidores MCP, sus manifiestos de herramientas, las configuraciones de modelos y agentes, y los sistemas externos a los que llegan esas herramientas, como los sistemas de control de código fuente, las plataformas de seguimiento de tickets, los sistemas de mensajería y los endpoints HTTP genéricos. A partir de estos datos, TFA crea un grafo de flujos que muestra qué componentes pueden llamar a qué herramientas, a qué pueden acceder esas herramientas y adónde pueden enviarse sus resultados.

Luego, este grafo se enriquece con atributos relevantes para la seguridad. Se agregan anotaciones a los nodos y las aristas para indicar si partes no confiables pueden influir en las instrucciones que los originan, si los datos que manejan son confidenciales y si el paso cruza un límite de confianza. Estas anotaciones permiten distinguir los flujos internos habituales de aquellos que conectan superficies controladas por atacantes con activos de gran valor y, luego, con destinos externos.

Con el grafo anotado, TFA puede buscar sistemáticamente rutas en las que se cumplan las tres condiciones de la tríada letal. Identifica secuencias en las que instrucciones no confiables pueden llegar a un agente, ese agente tiene una ruta hacia herramientas que exponen datos confidenciales y el mismo contexto incluye un punto de exfiltración. Estos son los flujos tóxicos que representan rutas de ataque realistas para un adversario decidido que usa lenguaje natural e integraciones existentes, en lugar de malware personalizado.

La detección es solo una parte de lo que se necesita. Para que TFA sea útil desde el punto de vista operativo, también debe permitir priorizar y actuar. No todos los flujos potenciales tienen el mismo nivel de riesgo. Una ruta que puede filtrar secretos de producción a un endpoint externo arbitrario tiene un perfil de impacto distinto al de una ruta que podría exponer metadatos no confidenciales a un sistema interno controlado. Toxic Flow Analysis puede asignar puntuaciones de impacto según factores como la clasificación de los datos, la facilidad de explotación, el alcance del acceso y la naturaleza del punto de exfiltración, para ayudar a los equipos a decidir dónde concentrar sus esfuerzos.

Esta perspectiva que tiene en cuenta los grafos permite que los equipos de seguridad y plataforma respondan preguntas que, de otro modo, serían difíciles de abordar. ¿Qué servidores MCP exponen combinaciones de herramientas que pueden crear flujos tóxicos? ¿Qué agentes están conectados simultáneamente a fuentes de instrucciones no confiables y a destinos de exfiltración? ¿Cómo cambia el conjunto de flujos posibles al introducir una nueva herramienta, como un cliente HTTP genérico?

Es importante destacar que el análisis de flujos tóxicos (TFA) no es un ejercicio que se realiza una sola vez. A medida que evolucionan los agentes, cambian las configuraciones de MCP y se agregan nuevas herramientas, es necesario actualizar y volver a evaluar el grafo de flujos. Si se aborda como una capacidad continua, el análisis de flujos tóxicos se convierte en la base de un enfoque más maduro del riesgo nativo de IA: uno que entiende cómo se comporta el entorno en su conjunto, no solo cómo están configurados sus componentes individuales.

Esto nos lleva al siguiente paso. Una vez que una organización puede ver y evaluar los flujos tóxicos, debe decidir cómo evitar que se ejecuten en la práctica. La visibilidad sin control no es suficiente en un entorno donde los agentes ya tienen la capacidad de actuar.

Por qué los entornos MCP necesitan barreras de protección, no solo visibilidad

El análisis de flujos tóxicos revela dónde se encuentran los riesgos nativos de IA, pero la información por sí sola no evita incidentes. Si un sistema puede identificar que una combinación específica de agente, servidor MCP y herramienta puede crear un flujo tóxico, también necesita un mecanismo para intervenir cuando ese flujo esté a punto de ejecutarse.

MCP aumenta la urgencia de este requisito porque conecta sistemas heterogéneos mediante un solo protocolo. A través de MCP, un agente puede acceder al control de código fuente, las canalizaciones de compilación, los sistemas de monitoreo, las plataformas de colaboración y los servicios internos. Cada una de estas integraciones está administrada por distintos equipos y proveedores. Por lo general, no hay un punto central en esos sistemas subyacentes donde se pueda aplicar una sola política para controlar todos los flujos que los involucran.

El lugar más práctico para aplicar políticas es dentro de la propia capa de IA: en el nivel de los servidores MCP, los agentes que exponen y la lógica de orquestación que decide qué herramientas están disponibles y cómo se pueden usar. En este contexto, las barreras de protección son mecanismos concretos de aplicación que pueden examinar secuencias de acciones planificadas o en curso, compararlas con los hallazgos y las políticas del análisis de flujos tóxicos y, luego, permitirlas, modificarlas o bloquearlas.

Para funcionar eficazmente, las barreras de protección necesitan contexto. Requieren más que el prompt actual o una sola invocación de herramienta. Deben comprender qué agente está en ejecución, qué herramientas están disponibles en el entorno, cómo están configuradas y qué datos y sistemas externos utilizan. Aquí es donde el AI-BOM y el escaneo de MCP desempeñan un papel fundamental.

El AI-BOM ofrece una descripción estructurada de la pila de IA: modelos, conjuntos de datos, frameworks, servidores MCP e integraciones clave. El escaneo de MCP aporta un inventario real de lo que está implementado en los endpoints de desarrolladores y operadores: qué servidores MCP están instalados, qué herramientas exponen y cómo están configurados. En conjunto, estas capacidades permiten que una capa de orquestación alinee los hallazgos del TFA con contextos de ejecución concretos.

Con esta información, las barreras de protección se pueden aplicar en puntos precisos. Si el análisis de flujos tóxicos identifica que un agente y una configuración de MCP determinados permitirían que problemas de GitHub no confiables hicieran llegar secretos a un endpoint HTTP externo, se puede implementar una política para impedir esa combinación específica y permitir los demás flujos. Así se evita recurrir a restricciones amplias e indiscriminadas que reducen la utilidad de los agentes.

Sin una aplicación integrada de este tipo, las organizaciones corren el riesgo de repetir un patrón conocido: paneles completos, hallazgos útiles, pero poco impacto en el comportamiento cotidiano. Las barreras de protección cierran la brecha entre el análisis y la acción, y garantizan que la conciencia sobre los flujos tóxicos se traduzca en límites concretos a lo que los agentes pueden hacer.

Del análisis al control: barreras de protección en la práctica y el valor de una gobernanza unificada

Convertir los hallazgos sobre flujos tóxicos en barreras de protección eficaces para MCP requiere políticas, orquestación y alineación con las herramientas existentes.

Las políticas son el punto de partida. Los equipos de seguridad, plataforma y desarrollo acuerdan límites que no se deben cruzar. Por ejemplo, se pueden prohibir los flujos en los que agentes expuestos a tickets externos acceden a secretos de producción y envían datos a URL arbitrarias, o exigir controles adicionales para flujos que involucran datos regulados. El análisis de flujos tóxicos proporciona la evidencia necesaria para definir y justificar estas políticas.

Luego, una capa de orquestación evalúa el comportamiento de los agentes en función de esas políticas. Cuando un agente está a punto de ejecutar, mediante MCP, una secuencia de llamadas a herramientas que completaría un flujo tóxico, la barrera de protección puede intervenir. Puede bloquear la secuencia, solicitar una autorización adicional o dirigir la solicitud por una alternativa más segura. La aplicación se realiza cerca del punto de decisión del agente, donde se ve todo el contexto del flujo.

Para escalar este enfoque, las organizaciones necesitan una capa de gobernanza que coordine todo su ecosistema. El AI-BOM y el escaneo de MCP proporcionan a esta capa información precisa y actualizada sobre los entornos MCP, tanto los administrados de forma centralizada como los instalados localmente. Así, la capa de gobernanza puede aplicar barreras de protección coherentes, ya sea que un agente se ejecute en una plataforma compartida o en la computadora de un desarrollador.

La corrección local sigue siendo esencial. El objetivo no es reemplazar los sistemas de CI/CD, los asistentes de IDE, las plataformas de gestión de tickets ni las herramientas de gobernanza de datos, sino garantizar que actúen sobre una comprensión compartida del riesgo. Cuando el TFA detecta un nuevo flujo tóxico, la plataforma de orquestación puede abrir incidencias, proponer cambios de configuración o actualizar las reglas de acceso en los sistemas que los equipos ya usan. La capa de gobernanza se convierte en el punto de coordinación; las herramientas existentes siguen siendo los motores que ejecutan los cambios.

A medida que crece la adopción, estas capacidades permiten que las organizaciones pasen de controles experimentales a un programa coherente de seguridad de IA. Pueden comenzar con la visibilidad que ofrece el análisis de flujos tóxicos, agregar barreras de protección específicas para sus flujos de mayor riesgo y, luego, ampliar esas barreras con el tiempo. Durante todo este proceso, el AI-BOM y el escaneo de MCP garantizan que las políticas se mantengan alineadas con el estado real del entorno.

MCP está destinado a ser un componente central de los sistemas nativos de IA. El análisis de flujos tóxicos, combinado con barreras de protección basadas en inventarios precisos y una gobernanza unificada, ofrece una manera de aprovechar sus beneficios y mantener bajo control los riesgos más importantes. A medida que evolucionan estas capacidades, el camino a seguir se vuelve claro: las organizaciones necesitan formas prácticas de poner en marcha este tipo de análisis.

¿Te interesa conocer más? Descubre cómo Snyk está avanzando en la protección de los sistemas nativos de IA y prueba Snyk MCP Scan hoy mismo.