La adopción de agentes inteligentes en entornos empresariales avanza a un ritmo vertiginoso. Sin embargo, muchas organizaciones caen en el error de confundir el protocolo con el control. El Model Context Protocol (MCP) se ha consolidado como el estándar para que los agentes descubran e invoquen capacidades empresariales, pero no debe ser tratado como el cerebro del sistema. En este artículo, desde la experiencia de Q2BSTUDIO, exploramos por qué MCP debe ser el plano de herramientas (tool plane) y no el controlador del agente (agent controller), y cómo diseñar una arquitectura de control que garantice seguridad, gobernanza y escalabilidad.
Imaginemos un ecosistema donde un agente de IA puede consultar bases de datos, ejecutar scripts en la nube, enviar correos y modificar registros. MCP proporciona una interfaz estandarizada para que el agente describa, invoque y reciba resultados de esas capacidades. Pero cuando el agente propone una acción —por ejemplo, reiniciar un servidor en producción—, el protocolo por sí solo no puede decidir si esa acción está autorizada, si está dentro del presupuesto o si debe requerir aprobación humana. Aquí es donde entra el plano de control del agente (Agent Control Plane).
La separación conceptual es clara: el agente propone, el controlador autoriza, MCP transporta la interacción gobernada, y el runtime ejecuta y verifica. Esta distinción es crítica para evitar que un error en el modelo o un ataque de inyección de prompts comprometa toda la infraestructura empresarial. En desarrollo de aplicaciones a medida, aplicamos este principio para construir sistemas donde la autoridad reside en servicios confiables, no en la capa de razonamiento del agente.
MCP estandariza el descubrimiento de herramientas, el acceso a recursos, la negociación de capacidades y los contratos de entrada/salida. Estas características lo convierten en un excelente plano de herramientas empresarial. Sin embargo, no debe asumir responsabilidades como la gestión de estados de flujo de trabajo, la autorización basada en políticas empresariales, los presupuestos de costes (incluyendo llamadas a modelos, reintentos y APIs externas), la detección de bucles infinitos, la verificación de postcondiciones o la compensación de efectos secundarios. Todo esto pertenece a un controlador de agente diseñado como un servicio aparte.
En Q2BSTUDIO, cuando trabajamos en proyectos de cloud AWS/Azure, implementamos capas de control que validan cada propuesta del agente antes de invocar cualquier herramienta MCP. El controlador conoce el contexto completo del usuario, la identidad autenticada, el alcance de sus permisos, el entorno (producción, staging, desarrollo), las políticas de seguridad vigentes y los límites de gasto. Solo después de esa validación, el controlador genera un 'sobre de ejecución' que incluye tanto lo que el agente propuso como los metadatos de autoridad: clave de idempotencia, identificador de traza, versión de política, y evidencia de aprobación (si se requiere). Este sobre se envía al runtime, que lo ejecuta a través de la capa MCP, y verifica el resultado contra el sistema de registro original.
Uno de los errores más comunes es permitir que el agente rellene campos como 'entorno: producción' o 'usuario: admin' dentro de los argumentos de la herramienta. El modelo no puede probar que esos valores son legítimos. La arquitectura segura separa los datos de propuesta (agente) de los datos de autoridad (runtime). El controlador nunca debe copiar campos de la propuesta al sobre de autoridad sin validación independiente. Por ejemplo, el agente puede sugerir 'entorno: producción', pero el controlador debe consultar el estado del flujo de trabajo para determinar si producción es el destino aprobado.
MCP también introduce conceptos como Tasks (experimental) y anotaciones de herramientas. Las Tasks permiten manejar operaciones de larga duración con estados (pendiente, en progreso, completado, cancelado). Pero no reemplazan a un motor de flujo de trabajo empresarial. Un Task MCP puede reportar el estado de una exportación de datos, pero no decide si esa exportación debe ejecutarse en paralelo con otra, si necesita un compensador cuando falla o si debe esperar una aprobación de dos personas. Del mismo modo, las anotaciones (readOnly, destructive, idempotent) son pistas, no controles de seguridad. Un servidor MCP comprometido o con un defecto puede etiquetar una operación como de solo lectura cuando en realidad modifica datos.
En la práctica, desde la perspectiva de ciberseguridad, recomendamos tratar las herramientas MCP como interfaces controladas. El controlador debe mantener un registro de servidores MCP aprobados, con su propietario, versión, revisiones de seguridad y entornos permitidos. Las herramientas deben exponerse dinámicamente según el contexto: un agente de solo lectura no debe ver herramientas de escritura. Además, es crucial que los tokens de autenticación sean audiencia-específicos: el token que el cliente MCP presenta al servidor debe ser válido solo para ese servidor, y nunca debe reenviarse a una API descendente sin transformación.
Otro aspecto fundamental es la verificación independiente de resultados. Un 'éxito' devuelto por una herramienta MCP no prueba que el resultado empresarial esperado se haya producido. Por ejemplo, si el agente solicita eliminar un registro y el servidor MCP devuelve 'success', el runtime debe consultar el sistema de registro para confirmar que el registro ya no existe, y almacenar esa evidencia. Esto es especialmente importante en implementaciones de BI/Power BI, donde las decisiones basadas en datos recién modificados pueden propagar errores si no se verifica la integridad de la fuente.
El flujo completo de una solicitud gobernada comienza con el agente que analiza la intención del usuario y construye una propuesta (operación, recurso objetivo, plan de ejecución, posibles alternativas). Esa propuesta se envía al controlador, que evalúa la identidad, las políticas, los presupuestos y las aprobaciones necesarias. Si todo está en orden, el controlador construye el sobre de ejecución con la autoridad y lo pasa al runtime. El runtime selecciona el servidor MCP adecuado (de entre los registrados y filtrados), invoca la herramienta con los argumentos validados, recoge la respuesta estructurada y ejecuta las comprobaciones de postcondición. Finalmente, el resultado se devuelve al controlador, que actualiza el estado del flujo de trabajo y, si es necesario, dispara el siguiente paso o notifica al usuario.
Esta arquitectura no solo mejora la seguridad, sino que también facilita el cambio de modelo de IA o de framework de agentes sin tener que rehacer toda la capa de integración. MCP actúa como un bus de herramientas estandarizado, mientras que el controlador y el runtime son servicios independientes que pueden evolucionar por separado. En Q2BSTUDIO, aplicamos este diseño en proyectos de automatización de procesos y automatización de procesos con agentes, logrando que las decisiones críticas queden siempre en manos de componentes deterministas y auditables.
Los modos de fallo principales que hay que diseñar contra incluyen: proliferación de servidores MCP sin control, exposición excesiva de herramientas a todos los agentes, inyección de prompts a través de resultados de herramientas, herramientas demasiado potentes (como ejecutar SQL arbitrario), confusión de credenciales (el servidor MCP que reenvía el token del cliente a un sistema descendente sin cambiar su audiencia), y falsa confianza derivada de la estandarización (creer que porque el protocolo es estándar, la operación es segura).
Para evitarlos, recomendamos mantener un catálogo de herramientas dinámico basado en la identidad del solicitante, el tipo de tarea, el entorno y el nivel de riesgo; validar cada propuesta antes de la invocación MCP; requerir claves de idempotencia generadas por el controlador para operaciones repetibles; verificar postcondiciones contra sistemas autoritativos; y mantener un registro de todas las decisiones (aprobadas, denegadas, pendientes de aprobación, presupuesto excedido, conflicto de estado, etc.).
En conclusión, MCP es un pilar fundamental para la interoperabilidad de agentes empresariales, pero no debe ser el controlador del sistema. La arquitectura robusta separa el razonamiento (agente), la autoridad (controlador), el transporte gobernado (MCP), y la ejecución verificada (runtime). Cada capa tiene responsabilidades distintas y no deben mezclarse. Desde Q2BSTUDIO, impulsamos esta visión para que las empresas puedan desplegar agentes de IA con confianza, sabiendo que cada acción está controlada, rastreada y respaldada por la autoridad adecuada. Si tu organización está evaluando cómo integrar agentes inteligentes en sus procesos, te invitamos a contactar con nuestro equipo para diseñar juntos una arquitectura de control adaptada a tus necesidades.
