Introducción

El Model Context Protocol, o MCP, define una forma estructurada para que una aplicación de IA se conecte a capacidades y datos externos. Los componentes centrales son la aplicación host, un cliente MCP y uno o varios servidores MCP. El host es el producto con el que interactúa el usuario, como un IDE o una aplicación de asistente. Normalmente crea una conexión de cliente independiente para cada servidor, de modo que el estado del protocolo, las capacidades y los fallos permanezcan asociados al servidor correcto.

Un servidor MCP expone capacidades mediante operaciones del protocolo. Las herramientas son operaciones ejecutables que pueden consultar un servicio, modificar un registro, enviar un mensaje o producir otro efecto secundario. Los recursos representan datos que un cliente puede recuperar, mientras que los prompts proporcionan plantillas de prompts reutilizables o patrones de interacción. Estas categorías son útiles desde el punto de vista arquitectónico, pero ninguna debe considerarse de confianza simplemente por haber llegado a través de MCP. La seguridad en producción depende de quién controla cada componente, qué datos atraviesan cada conexión y qué nivel de autoridad puede ejercer una operación.

Flujo de solicitudes y funciones de los componentes

Una interacción típica comienza cuando el host establece una sesión con un servidor MCP mediante un transporte compatible. El cliente y el servidor inicializan su sesión de protocolo y comunican las capacidades compatibles. A continuación, el host puede descubrir las herramientas, los recursos o los prompts disponibles y decidir cómo deben aparecer esas capacidades en la experiencia del usuario o en el contexto del modelo. El transporte exacto puede variar entre despliegues locales y remotos, pero las preguntas sobre la confianza siguen siendo las mismas.

Cuando un modelo propone una llamada a una herramienta, el host o el cliente debe aplicar la política de interacción y autorización del producto antes de reenviar la solicitud. El servidor vuelve a validar la solicitud y ejecuta la operación utilizando sus propias credenciales y permisos de ejecución. El resultado vuelve a través del servidor y el cliente hasta el host, donde puede mostrarse al usuario o añadirse al contexto del modelo. Esta validación repetida es intencionada: una política del lado del cliente reduce las solicitudes inseguras, mientras que la validación del lado del servidor protege al servidor cuando otro cliente o un mensaje malformado llega hasta él.

La lectura de un recurso sigue una ruta relacionada, pero presenta un perfil de riesgo diferente. El servidor resuelve el recurso solicitado y devuelve contenido o metadatos. Que sea de solo lectura no significa que sea inofensivo: un recurso puede contener información confidencial, instrucciones maliciosas, datos personales o contenido obsoleto. El host debe conservar la procedencia y aplicar controles de acceso antes de presentar o utilizar el contenido.

Límites de confianza en el desarrollo

El primer límite de confianza se encuentra entre el usuario y la aplicación anfitriona. La aplicación anfitriona recibe solicitudes en lenguaje natural, resultados de herramientas, contenido de recursos y, posiblemente, instrucciones procedentes de sistemas externos. Una aplicación anfitriona en producción no debe asumir que todas las instrucciones incluidas en el contenido recuperado representan la intención del usuario. Necesita reglas claras para la confirmación, especialmente cuando una acción modifica datos, contacta con un tercero, gasta dinero o expone secretos.

El segundo límite de confianza se encuentra entre el cliente MCP de la aplicación anfitriona y el servidor. Un servidor puede ser un proceso local instalado desde un paquete, un servicio interno gestionado por separado o un servicio remoto operado por otro equipo. Estas opciones de implementación cambian el modelo de autenticación, aislamiento y actualización. Un proceso local aún puede leer archivos, heredar variables de entorno, acceder a destinos de red o ejecutar dependencias vulnerables. Un servidor remoto aún puede recibir argumentos sensibles y devolver contenido que influya en el modelo.

El tercer límite de confianza se encuentra entre el servidor MCP y sus sistemas posteriores. El servidor puede llamar a una base de datos, una API en la nube, un sistema de archivos, un sistema de gestión de tickets o un comando de shell. La autenticación de MCP no autoriza automáticamente esas acciones posteriores. El servidor debe utilizar identidades de servicio con permisos estrictamente limitados, controles explícitos de destino, tiempos de espera, límites de velocidad y autorización específica para cada operación. Un servidor que puede emitir solicitudes administrativas sin restricciones es un componente de alto impacto, aunque su interfaz MCP exponga solo unas pocas herramientas.

Identidad y autorización en producción

La autenticación responde a quién se está conectando; la autorización responde a qué puede hacer esa identidad. En una implementación de producción, identifique por separado, siempre que sea posible, el contexto de la aplicación anfitriona o del usuario y el servidor MCP. Evite utilizar una única credencial compartida para todos los clientes y servidores. Las identidades separadas mejoran la revocación, la investigación de incidentes, la limitación de velocidad y la aplicación del principio de mínimo privilegio. Las implementaciones remotas también necesitan un transporte seguro y un método definido para gestionar las credenciales; las credenciales no deben colocarse en los argumentos de las herramientas ni devolverse en los resultados de las herramientas.

La negociación de capacidades es útil para la compatibilidad, pero no constituye una decisión de autorización. Que un servidor anuncie que admite herramientas no significa que un usuario concreto pueda invocarlas todas. La autorización debe evaluarse para la operación solicitada, el destino, el tenant y la clasificación de los datos. Por ejemplo, un usuario puede tener permiso para leer un recurso de un proyecto, pero no para eliminar el proyecto, aunque ambas capacidades estén expuestas por el mismo servidor.

Los esquemas de las herramientas ayudan a restringir las entradas, pero un esquema no es una política de seguridad completa. El servidor debe validar los tipos, rangos, longitudes, identificadores y relaciones entre los campos. Debe rechazar destinos inesperados, rutas de archivos inseguras, referencias de tenant no válidas y solicitudes que excedan el alcance de la persona que llama. Para acciones de alto impacto, la aplicación anfitriona puede exigir la aprobación explícita del usuario y mostrar el destino, el efecto previsto y los parámetros importantes antes de la ejecución. La aprobación debe estar vinculada a la acción específica, en lugar de tratarse como un permiso permanente.

Controles operativos y gestión de fallos

La operación en producción requiere visibilidad a lo largo de toda la ruta de la solicitud. Registre qué identidad inició una solicitud, qué servidor la gestionó, qué herramienta o recurso se seleccionó, cuál fue el resultado de la autorización y cuál fue el resultado posterior. Redacte los secretos y los datos personales innecesarios. Correlacione los registros del cliente, del servidor y de los sistemas posteriores mediante un identificador de solicitud, teniendo en cuenta que los propios registros se convierten en activos sensibles que requieren controles de acceso y reglas de conservación.

Diseñe teniendo en cuenta los fallos parciales. Un servidor puede no estar disponible, una API posterior puede agotar el tiempo de espera, una respuesta puede superar los límites de tamaño o una herramienta puede devolver un error después de crear un efecto secundario. La aplicación anfitriona debe comunicar claramente la incertidumbre y no debe reintentar automáticamente operaciones no idempotentes sin una política definida. Los servidores deben utilizar tiempos de espera acotados, concurrencia controlada, límites de tamaño de respuesta y una gestión de errores predecible. Los disyuntores o los límites de velocidad pueden ser adecuados para dependencias costosas o frágiles.

Considere las actualizaciones y la configuración como parte del modelo de confianza. Fije o revise las versiones de los servidores, verifique el origen y la integridad de los artefactos de implementación, gestione los secretos fuera del código fuente y limite el entorno heredado por los procesos locales. Pruebe el comportamiento de las herramientas con entradas malformadas, destinos no autorizados, resultados demasiado grandes, inyección de prompts en los recursos y fallos de los sistemas posteriores. La revisión de seguridad debe examinar los permisos efectivos del entorno de ejecución, no solo los nombres y descripciones expuestos por el servidor MCP.

Errores comunes y revisión práctica

Un error frecuente es confiar en las descripciones de las herramientas como si fueran un contrato de seguridad. Las descripciones son útiles para el descubrimiento, pero un servidor comprometido o con un mantenimiento deficiente puede describir una operación peligrosa con un lenguaje inofensivo. Revise la implementación, los permisos de identidad, los destinos de red, los flujos de datos y el comportamiento de aprobación. La misma precaución se aplica a las plantillas de prompts y a los metadatos de los recursos: pueden influir en el comportamiento del modelo, pero no establecen autoridad.

Otro error es tratar una configuración de desarrollo local como un modelo de confianza para producción. Los desarrolladores suelen ejecutar un servidor con amplio acceso al sistema de archivos, credenciales personales, acceso saliente a la red sin restricciones y registros detallados. En producción, esos valores predeterminados deben sustituirse por una identidad de ejecución dedicada, un directorio de trabajo restringido, un conjunto mínimo de variables de entorno, reglas de salida explícitas y un tratamiento controlado de los datos. Pruebe el despliegue utilizando los permisos que producción realmente otorgará.

Durante una revisión, siga una operación de lectura representativa y una operación de escritura representativa, desde la solicitud del usuario hasta el efecto posterior. En cada paso, identifique la identidad, la validación de entradas, la clasificación de datos, el requisito de aprobación, el tiempo de espera, el evento de auditoría y el comportamiento ante fallos. Si algún paso no puede explicarse con precisión, el límite aún no está definido operativamente. Este método produce tareas concretas de corrección en lugar de basarse en una afirmación general de que se confía en el servidor MCP.

Resumen

MCP separa la experiencia del host de las capacidades proporcionadas por el servidor, pero no elimina los límites de seguridad entre ellos. El host gestiona la interacción del usuario y las sesiones del cliente; el servidor valida las solicitudes e implementa herramientas, recursos y prompts; los sistemas posteriores siguen siendo autoridades independientes, con sus propios permisos y modos de fallo.

En producción, céntrese en una identidad explícita, el principio de mínimo privilegio, la validación en el servidor, la aprobación del usuario para acciones con consecuencias, el tratamiento cuidadoso del contenido recuperado, una ejecución acotada y registros de auditoría útiles. La negociación de capacidades favorece la interoperabilidad, mientras que la autorización decide qué puede suceder realmente. El objetivo práctico no es confiar o desconfiar de MCP como una unidad única, sino documentar cada límite y aplicar controles adecuados a los datos y la autoridad que lo atraviesan.