Seguridad MCP: 12 controles antes de conectar la IA a sus sistemas

Conectar un asistente de IA a su CRM, base de datos o ERP es útil precisamente porque puede actuar sobre sistemas reales. Ese es también el riesgo. Un servidor MCP es una nueva puerta de entrada a su negocio, y lo controla un modelo de lenguaje que puede ser engañado.

La mayoría de los problemas que vemos no son exóticos. Son errores conocidos en un lugar nuevo. Claves de administrador compartidas. Herramientas que pueden hacer demasiado. Ausencia de registros. Nadie revisando lo que dicen las descripciones de las herramientas. Cada uno es barato de prevenir y caro de subsanar.

Qué cubre esta lista de verificación

MCP (Model Context Protocol) es un estándar abierto presentado por Anthropic. Permite que asistentes de IA como Claude, y otros clientes compatibles, se conecten a herramientas y datos mediante pequeños programas llamados servidores MCP. La compatibilidad varía según el cliente de IA, así que consulte la documentación actual de cada cliente antes de planificar un despliegue.

Use la lista de verificación siguiente cuando construya un nuevo servidor MCP, compre uno o revise uno que ya esté en funcionamiento. Cada punto incluye una breve explicación. Trate cualquier "no" como un hallazgo con un responsable y una fecha.

La lista de verificación de seguridad para servidores MCP

1. Autentique a cada usuario. Sin acceso anónimo y sin cuentas compartidas. Para servidores remotos, use OAuth cuando el cliente lo admita, para que cada persona inicie sesión con su propia identidad. Consulte la especificación actual de MCP y la documentación de su cliente para conocer los flujos admitidos.
2. Autorice por usuario y por herramienta. Saber quién es alguien no significa que pueda hacerlo todo. Transmita la identidad del usuario a los sistemas posteriores siempre que sea posible, para que los permisos existentes sigan aplicándose. Si no, aplique comprobaciones de rol en el servidor.
3. Aplique el mínimo privilegio. Las cuentas de servicio y los tokens de API reciben los permisos más restringidos que funcionen. Una herramienta que lee pedidos no debería tener un token capaz de eliminar clientes.
4. Use solo lectura por defecto. Entregue primero las herramientas de lectura. Añada las herramientas de escritura de una en una, solo cuando haya una necesidad clara y un paso de aprobación.
5. Mantenga las herramientas acotadas. "Obtener el estado del pedido por número de pedido" es más seguro que "ejecutar cualquier llamada a la API". Las herramientas acotadas son más fáciles de validar, probar y explicar.
6. Valide cada entrada. Use esquemas estrictos con tipos, longitudes, formatos y valores permitidos. Rechace todo lo demás. Nunca pase texto generado por el modelo directamente a SQL, comandos de shell o rutas de archivos.
7. Trate las respuestas de las herramientas como no fiables. Correos, tickets, documentos y páginas web pueden contener instrucciones dirigidas al modelo. Esto es la inyección de prompts. No permita que la respuesta de una herramienta active silenciosamente herramientas de escritura. Limite qué herramientas pueden ejecutarse en la misma sesión y elimine o marque el contenido sospechoso cuando sea factible.
8. Gestione bien los secretos. Guarde las credenciales en un gestor de secretos o en una configuración de entorno cifrada. Nunca las ponga en el código, en las descripciones de las herramientas, en los prompts ni en los registros. Use credenciales distintas para cada entorno y rótelas.
9. Establezca límites de uso y cuotas. Limite las llamadas por usuario y por herramienta. Limite el tamaño de los resultados y fije tiempos máximos. Esto protege los sistemas posteriores y contiene un bucle descontrolado de un agente.
10. Mantenga registros de auditoría. Registre quién llamó a qué herramienta, con qué entradas, qué ocurrió y cuándo. Mantenga los datos personales fuera de los registros siempre que pueda. Haga que los registros se puedan buscar y fije un plazo de conservación.
11. Exija aprobación humana para las escrituras. Toda acción que modifique registros, envíe mensajes o mueva dinero muestra primero una vista previa. Una persona designada la aprueba y la aprobación queda registrada. Nuestra guía sobre agentes de IA con aprobación humana muestra patrones prácticos.
12. Versione y revise las descripciones de las herramientas. El modelo lee los nombres y las descripciones de las herramientas para decidir a cuál llamar. Una descripción modificada cambia el comportamiento. Manténgalas en control de versiones, revise los cambios como si fueran código y tenga cuidado con los servidores de terceros cuyas descripciones pueden cambiar sin previo aviso.

Cómo realizar la revisión, paso a paso

1. Enumere cada herramienta con sus entradas, salidas, sistema posterior y los permisos que tiene.
2. Redacte un breve modelo de amenazas. Para cada herramienta, pregúntese qué ocurre si el modelo la llama con la peor entrada plausible.
3. Recorra la lista de verificación y registre cada carencia como un hallazgo con una gravedad.
4. Pruebe la inyección de prompts. Plante instrucciones en los datos que devuelve el servidor y confirme que no provocan acciones no deseadas.
5. Pruebe los permisos con dos usuarios que deberían ver datos distintos.
6. Corrija por orden de prioridad, empezando por todo lo que permita escrituras no autorizadas o exposición de datos.
7. Repita en cada versión que añada una herramienta o cambie una descripción.

Herramientas que utilizamos

• SDK de MCP para Python y TypeScript, con esquemas de entrada estrictos.
• Python con FastAPI para la validación, el middleware de autenticación y las capas de integración.
• Su proveedor de identidad para OAuth y la información de roles.
• Un gestor de secretos y su plataforma actual de registros y monitorización.

La especificación de MCP y las funciones de los clientes evolucionan. Consulte la especificación actual y la documentación de cada proveedor en lugar de basarse en guías antiguas.

Qué necesita para empezar

• Acceso al código, la configuración y los ajustes de despliegue del servidor.
• Una lista de los sistemas conectados y de las credenciales que usa cada herramienta.
• Alguien que pueda explicar quién usa el servidor y para qué.
• Un entorno de preproducción para las pruebas de inyección y de permisos.

Alcance y plazos habituales

Como estimación, revisar un servidor pequeño con unas pocas herramientas suele llevar días y no semanas. Construir un nuevo servidor de solo lectura con estos controles desde el principio suele llevar de una a tres semanas, según los sistemas implicados.

Los hallazgos más frecuentes

Cuando revisamos servidores existentes, unos pocos problemas aparecen una y otra vez.

• Un único token compartido para todos. El servidor funciona, pero en la práctica cada usuario tiene derechos de administrador en el sistema posterior.
• Una herramienta que "lo hace todo". Una herramienta genérica de API o SQL pensada para pruebas que nunca se retiró.
• Secretos en el lugar equivocado. Claves en un archivo de configuración subido al repositorio, o volcadas en los registros.
• Ningún registro de las acciones. Nadie sabe decir quién modificó un registro a través del asistente el martes pasado.
• Servidores de terceros sin revisar. Un servidor de la comunidad instalado por un ingeniero y que ahora usa todo el equipo.

Ninguno de ellos requiere reescribir nada. Cada uno es una corrección concreta, y corregirlos pronto es mucho más barato que responder a un incidente.

Riesgos y cómo los gestionamos

El mayor riesgo es tratar el servidor MCP como un script rápido en lugar de como software de producción. Le aplicamos la misma disciplina que a cualquier API: revisión de código, pruebas, despliegues por fases y monitorización. El segundo riesgo es la fatiga de aprobación, cuando la gente hace clic en aprobar sin leer. Mantenga pocas herramientas de escritura, vistas previas breves y claras, y revise los registros de aprobación con regularidad.

Cuándo no conviene construirlo

Si el conector oficial de un proveedor cubre sus necesidades y su modelo de seguridad supera su revisión, utilícelo. Si los datos están muy regulados y no pueden salir de su entorno, considere primero un despliegue privado. Nuestra guía sobre RAG privado para datos regulados explica las opciones. Y si nadie se hará cargo del servidor tras el lanzamiento, no lo conecte a sistemas con capacidad de escritura.

Para desarrollos concretos, consulte conectar su CRM a Claude con MCP y un servidor MCP para analítica de bases de datos.

Cómo puede ayudar UnlockLive

UnlockLive IT es una agencia de software con sede en Toronto y su propio equipo de ingeniería. Desarrollamos estas integraciones para empresas de Estados Unidos, Canadá, el Reino Unido y Australia. Nuestro servicio de desarrollo de servidores MCP abarca el alcance, el modelo de amenazas, la construcción, el despliegue y el mantenimiento continuo. Nuestro equipo de ciberseguridad realiza revisiones de seguridad de MCP y entrega un modelo de amenazas por escrito con correcciones priorizadas.

Si desea una segunda opinión sobre el alcance o el riesgo, reserve una llamada gratuita de 30 minutos. Traiga una o dos preguntas que su equipo se plantee cada semana y le diremos con honestidad si un servidor MCP es la herramienta adecuada.