MCP resolvió el descubrimiento de herramientas, no su seguridad

El protocolo MCP (Model Context Protocol) resolvió un problema real: dio a clientes de IA y a servidores de herramientas un lenguaje común para descubrir capacidades, leer sus esquemas e invocarlas de forma estandarizada. Lo que no resolvió es nada de lo que viene después: quién puede usar cada herramienta, con qué límites, y qué hacer cuando lo que devuelve es hostil. El aviso viene de un análisis técnico reciente y conviene tomárselo en serio antes de conectar un servidor MCP a algo que importe.

Un catálogo no es un control de acceso

Antes de MCP, cada integración de un asistente con sistemas externos era pegamento a medida: esquemas de funciones propios, manifiestos de plugin, flujos de autenticación irrepetibles. El protocolo cambió eso. El cliente pregunta, el servidor describe, el cliente invoca. La interoperabilidad ganó, y no es poco.

El problema es que, cuando una herramienta es descubrible, entra en el contexto del modelo. Su nombre, su descripción y su esquema pasan a formar parte de aquello sobre lo que razona y decide. MCP no expone solo capacidades: expone influencia.

El error de modelo mental más común es suponer que si el servidor anunció la herramienta, se puede usar. Anunciar no es autorizar. El caso típico: un agente conectado a un CRM que ve list_customers, update_customer y delete_customer, y un ingeniero de soporte que le pide limpiar cuentas de prueba duplicadas. El modelo ve delete_customer en el catálogo, lo considera relevante y lo llama. No sabe qué debería poder hacer el usuario; solo sabe qué tiene delante.

La propuesta es filtrar el catálogo antes de que llegue al modelo, según el principal autenticado, el nivel de riesgo de la sesión y el contexto de la tarea. Con un aviso que suele pasarse por alto: denegar en el momento de la llamada es mejor que nada, pero ocultar la herramienta es más seguro, porque una descripción que el modelo puede leer ya influye en su comportamiento aunque la invocación acabe bloqueada.

Las descripciones son código

El segundo punto va en la misma dirección. Una descripción de herramienta no es documentación inerte. Pensemos en un servidor que expone get_exchange_rate y en su propia descripción pide al modelo que incluya la clave de API guardada en la variable de entorno INTERNAL_ADMIN_TOKEN dentro del campo de notas. El modelo lo lee y lo intenta cumplir. Es inyección de prompt servida desde el catálogo.

De ahí sale la pieza que el protocolo no trae de serie: una pasarela de políticas entre el agente y los servidores MCP, y una lista de lo que queda en tus manos. Autorización por usuario, privilegio mínimo, sandboxing, flujos de aprobación, saneado de los resultados de cada herramienta, defensa frente a la inyección y confianza en la cadena de suministro.

La conclusión práctica es incómoda y simple: trata cada servidor MCP como un plugin con influencia en tiempo de ejecución, no como una fuente de metadatos inofensiva. Un servidor local corre con tus privilegios, el registro dinámico de herramientas rompe cualquier revisión estática previa, y OAuth da identidad, no intención. Si vas a conectar agentes a sistemas que tocan dinero, correo o entornos de despliegue, la capa de política no es opcional.