La promesa de MCP es elegante: ofrecer a los agentes una forma consistente y auditable de llamar a herramientas. Pero está surgiendo una matiz crítica: después de que un usuario autoriza un servidor, la superficie de riesgo no se reduce; se desplaza. Una instrucción oculta en la respuesta o contexto del servidor puede inducir al modelo a usar las mismas herramientas que tiene permitido llamar, ahora orientadas a filtrar tokens, claves API o datos internos. Esto no es un jailbreak en el sentido clásico; es un ataque de redirección posterior a la aprobación que aprovecha una capacidad legítima.

El patrón es engañosamente simple. Un usuario aprueba un servidor y un conjunto de herramientas. Más tarde, el servidor devuelve una carga útil que parece inofensiva pero que incluye instrucciones estratégicamente diseñadas. El modelo, operando dentro de sus permisos concedidos, cumple: invoca un comando aprobado, lee un archivo o variable de entorno y transmite el resultado a un punto final controlado por un atacante. Como cada paso está técnicamente dentro del alcance, las verificaciones de políticas ingenuas pasan y los filtros tradicionales de jailbreak rara vez se activan. El límite de confianza se ha desplazado del clic de un botón a todo el ciclo conversacional y de invocación de herramientas.

Para las empresas que pilotan flujos de trabajo agenticos, las implicaciones son operativas, no teóricas. Los controles de seguridad deben gobernar cómo, cuándo y con qué parámetros se pueden usar las herramientas, especialmente para el acceso a secretos, la introspección del sistema y las llamadas a redes externas. Los equipos de cumplimiento y auditoría deben tratar a los servidores MCP como software de terceros: exigir certificaciones, aislarlos mediante controles de red y espacios de nombres, rotar credenciales efímeras y exigir registros a prueba de manipulaciones. Lo más importante, separar la autoridad para aprobar una herramienta de las circunstancias que permiten su uso en una solicitud dada.

Existen mitigaciones, pero deben ser precisas. Hacer cumplir listas blancas de parámetros y negar comodines peligrosos por defecto. Requerir confirmaciones fuera de banda para operaciones de alto riesgo (lectura de secretos, escritura de archivos, publicación en URLs externas). Usar firmas criptográficas en las respuestas del servidor y vincular las aprobaciones a sesiones de corta duración con ámbitos limitados. Insertar un firewall de contexto para eliminar o poner en cuarentena instrucciones que buscan herramientas y que provienen de contenido no confiable. Finalmente, monitorear patrones coercitivos: exfiltración repentina de datos, evasión repetida de esquemas o modelos que repiten instrucciones para divulgar tokens, y revocar sesiones automáticamente cuando se detecten.