El puente MCP entre un agente de IA y tu Drupal puede convertir cualquier texto público en instrucciones que el agente ejecutará.
Por qué el riesgo cambia con un agente conectado
Cuando tu sitio entrega HTML a un navegador, el visitante solo lee lo que tú muestras. Al conectarlo a un agente de IA mediante el protocolo MCP (Model Context Protocol), ese agente puede pedir datos estructurados y, si se lo permites, ejecutar acciones en tu Drupal: crear nodos, actualizar campos o activar colas. Ese cambio de paradigma trae tres diferencias clave para la seguridad.
Primero, el agente conserva el contexto entre llamadas. Una instrucción maliciosa que logre entrar no se pierde en una sola respuesta, sino que permanece disponible para las siguientes operaciones. Segundo, las respuestas que devuelven las herramientas entran directamente al prompt del modelo, con el mismo peso que tus instrucciones de sistema, sin que el modelo marque su procedencia de forma nativa. Tercero, los permisos del agente son los del usuario con el que se autenticó. Si ese usuario tiene permisos elevados, un error de configuración puede traducirse en escritura real sobre tu base de datos.
Este escenario es distinto a un ataque XSS tradicional. El objetivo ya no es ejecutar JavaScript en el navegador, sino inducir al agente a ejecutar acciones autorizadas con sus propios permisos. Por eso la defensa no pasa por refinar un solo prompt, sino por aplicar controles de arquitectura sobre lo que expones y lo que exige aprobación.
Tool poisoning: cuando la definición de la herramienta es el ataque
El vector MCP03:2025, identificado por OWASP MCP Top 10, recibe el nombre de tool poisoning. El atacante no envenena los datos, sino la descripción de la herramienta: ese texto le indica al modelo qué hace, cuándo usarla y qué argumentos espera.
La diferencia entre una descripción legítima y una envenenada puede ser imperceptible para quien revisa de prisa. Mientras la primera dice qué hace la acción, la segunda añade instrucciones ocultas dirigidas al modelo. El problema estructural es que esa descripción nunca la ve el usuario final: solo la interpreta el agente al momento de decidir si usa la herramienta. Si esa definición proviene de una fuente que puede modificarse sin revisión, el agente obedecerá esas instrucciones adicionales como si formaran parte de la especificación confiable.
En Drupal, las herramientas expuestas por MCP Server son entidades de configuración, no código PHP compilado. Esto facilita el control de cambios: cualquier adición o modificación queda registrada en archivos YAML y puede revisarse en un pull request. Como regla práctica, toda definición nueva o modificada debe aprobarse como si fuera código. Si el equipo no la entiende en su totalidad, no debe integrarse al entorno.
También existe una variante más difícil de detectar, conocida como rug pull: la herramienta es segura en la aprobación inicial, pero cambia después sin nueva revisión. Para mitigarla es necesario auditar periódicamente el historial de esas configuraciones. Con Git puedes revisar los cambios en la carpeta de configuración de MCP cada vez que importes configuración o actualices dependencias, lo que permite detectar modificaciones no autorizadas a tiempo.
Inyección contextual: el contenido público como instrucción
El vector MCP06:2025 es el más probable en un sitio Drupal en producción. No requiere acceso al servidor, solo que un atacante escriba texto en alguna superficie que el agente vaya a leer cuando ejecute una tarea. Ese texto puede contener instrucciones diseñadas para que el modelo las interprete como órdenes válidas.
Entre las fuentes de entrada no confiable conviene revisar campos de contenido con formulario abierto al público, comentarios, archivos adjuntos de los que una herramienta extraiga texto, títulos, nombres de términos de taxonomía y datos devueltos por herramientas de lectura agregadas. El ataque suele ser indirecto: una frase oculta en el cuerpo de un nodo no se percibe al visualizar la página, pero sí queda dentro del contexto que recibe el agente cuando solicita ese nodo.
Para reducir este riesgo conviene delimitar claramente los datos devueltos por herramientas de lectura, tratando ese contenido como no confiable dentro del sistema. También resulta útil restringir qué campos alimentan respuestas de agente, evitar concatenar entrada de usuario en herramientas que ejecuten acciones y reducir al mínimo las herramientas de escritura expuestas. Cuanto menor sea el radio de acción del agente, menor será la superficie aprovechable por este tipo de inyección.
Controles nativos para Drupal 11
La defensa práctica se apoya en módulos con soporte activo para Drupal 10.6+ y 11.3+. MCP Server expone las herramientas con autenticación OAuth 2.1, lo que permite otorgar tokens con alcance mínimo y expiración corta. A partir de ahí, puedes ampliar con MCP Server Tool Bridge y MCP Server Views para lectura estructurada.
El complemento clave para cerrar flujos peligrosos es MCP Sentinel. Entre sus capacidades destacan el gate de publicación para contenido creado por agentes, la cola de aprobación humana para operaciones destructivas, los roles temporales con TTL para permisos elevados y una cadena de auditoría verificable con hash encadenado. Esta última convierte cada acción del agente en un registro trazable: si alguien intenta alterar ese registro, el recalculo del hash lo detecta.
Para habilitar estas capas con un despliegue controlado, puedes seguir estos pasos de revisión:
# Instalar dependencias con versiones compatibles
composer require drupal/mcp_server
composer require drupal/mcp_sentinel
# Habilitar módulos
drush en mcp_server mcp_sentinel
drush cr
# Ver qué configuraciones de MCP cambian
drush config:status | grep mcp
# Revisar historial de definiciones en Git
git log --oneline -p -- 'config/yml/*mcp*'
Estos comandos permiten confirmar el estado real del sitio y asegurar que cualquier cambio en las herramientas queda bajo control de versiones.
Lista de verificación para exponer tu sitio de forma segura
Antes de conectar cualquier cliente MCP en producción, conviene aplicar este orden de mitigación. Empieza solo con lectura, activa el gate de publicación para todo contenido generado por agente y exige aprobación humana para cualquier operación que afecte datos sensibles o precios. Separa el cliente MCP en un entorno con acceso limitado, evita exponer rutas con archivos privados a herramientas de lectura y utiliza OAuth 2.1 con alcance mínimo. Además, revisa las definiciones de herramientas en cada despliegue y configura alertas para acciones fuera de horario o fuera de flujo sobre la cadena de auditoría. Esta lista no es opcional si el agente puede escribir en tu sitio.
Preguntas frecuentes
¿Un agente MCP puede modificar mi contenido sin revisión?
Sí, si el usuario autenticado tiene permisos de edición y no existe una capa de aprobación. El gate de publicación de MCP Sentinel evita que el contenido creado por el agente quede publicado automáticamente: queda en estado no publicado hasta que una persona lo valide.
¿El prompt injection es un problema del modelo o de mi Drupal?
Es un problema de arquitectura en lo que expones. El modelo no distingue entre instrucciones del sistema y texto no confiable devuelto por una herramienta. El control está en qué herramientas publicas, cómo delimitas los datos y qué operaciones exigen aprobación.
¿Basta con sanear el contenido de los campos?
No. El saneamiento evita XSS, pero un texto sanitizado sigue siendo legible por el modelo y puede transportar instrucciones. Es una medida complementaria, no suficiente por sí sola.
¿Por qué usar OAuth 2.1 en lugar de una clave estática?
Porque OAuth 2.1 permite revocar tokens por cliente, limitar su alcance y establecer expiraciones cortas. Si un cliente MCP se compromete o deja de usarse, puedes cerrar su acceso sin modificar la configuración global del sitio.
¿Cómo sé exactamente qué hizo el agente después de un incidente?
Mediante la cadena de auditoría de MCP Sentinel. Cada acción queda encadenada con hash, de modo que al recalcular la cadena puedes detectar cualquier registro alterado. Esto te brinda una fuente de verdad verificable, independiente del proveedor del modelo.
