Los servidores MCP permiten que los modelos de IA actúen dentro de tus sistemas, y eso convierte el envenenamiento de herramientas, la inyección de prompts y los tokens filtrados en riesgos reales. Conoce las siete amenazas que importan, una checklist de 20 puntos para el acceso, el endurecimiento y el flujo de datos, y una rutina de auditoría para una tarde.
Un servidor MCP es una puerta a tus sistemas que un modelo de IA abre por su cuenta. Cuando un cliente, como un asistente de chat o un editor de código, se conecta, el modelo puede leer archivos, consultar bases de datos, llamar a APIs internas y enviar mensajes, normalmente con los permisos de quien instaló el servidor. Por eso las buenas prácticas de seguridad en MCP deben formar parte del primer sprint, no de la revisión posterior a un incidente. Este artículo recorre los riesgos que de verdad aparecen en producción, presenta una checklist de 20 puntos que puedes pegar en un ticket y explica una auditoría que tu equipo puede terminar en una tarde.
Versión corta, por si tienes prisa: trata cada descripción de herramienta como una entrada no confiable, da a cada servidor el conjunto mínimo de permisos que funcione, mantén los secretos fuera del alcance del modelo y registra cada llamada a una herramienta para poder reconstruir lo que pasó.
La seguridad clásica de las APIs supone que un desarrollador escribió el código que llama a tu endpoint. MCP rompe esa suposición. El Model Context Protocol permite que un modelo de lenguaje elija herramientas en tiempo de ejecución, a partir del texto que lee. El texto se puede falsificar, y el modelo no puede distinguir de forma fiable una instrucción legítima de una plantada. Por eso la seguridad de los servidores MCP es un problema distinto al de blindar una API REST.
En una integración normal, una persona revisa el camino del código antes de publicarlo. Con MCP, quien llama es un sistema probabilístico que lee nombres, descripciones y resultados de herramientas como parte de su prompt. Una frase escondida en la descripción de una herramienta pesa casi lo mismo que una frase en tu propio prompt de sistema. Este solo hecho explica la mayoría de los incidentes con MCP.
También cambia quién cuenta como atacante. No necesitas acceso al servidor. Cualquiera que pueda poner texto delante del modelo puede intentar dirigirlo: el autor de una página web, un cliente que abre un ticket de soporte, un desconocido que abre una incidencia en un repositorio público. La buena seguridad de agentes de IA empieza por reconocer que el canal de entrada está abierto al mundo.
Dibuja cuatro límites antes de escribir una sola línea de configuración:
| Límite | Qué lo cruza | En quién confías |
|---|---|---|
| Usuario a cliente | Prompts y aprobaciones | El usuario con sesión iniciada |
| Cliente a servidor | Llamadas a herramientas y resultados | Solo servidores que hayas revisado |
| Servidor a backend | Consultas, archivos, llamadas a APIs | Una identidad de servicio con alcance limitado |
| Servidor a internet | Páginas consultadas, webhooks | Nadie |
El transporte también importa. Un servidor local lanzado por stdio es un proceso en la máquina del usuario que se ejecuta con sus permisos, así que un paquete malicioso equivale, en la práctica, a ejecución de código arbitrario. Un servidor remoto por HTTP añade exposición de red, autenticación y gestión de sesiones. Cada transporte necesita su propio modelo de amenazas, y un servidor que ofrece ambos requiere dos revisiones.
💡 Consejo: La configuración más arriesgada es un agente que puede leer datos privados, leer contenido no confiable y enviar datos hacia fuera. Los investigadores de seguridad llaman a esta combinación la "trifecta letal". Quita al menos una de sus patas y la mayoría de las vías de fuga se cierran.
No todas las amenazas merecen la misma atención. Estas siete aparecen una y otra vez en la investigación pública sobre MCP y en los informes de incidentes, y cada una se relaciona con elementos de la checklist más adelante.
| # | Riesgo | Qué ocurre | Impacto típico |
|---|---|---|---|
| 1 | Inyección de prompts | El modelo sigue instrucciones ocultas en una página, un ticket o un archivo | Fuga de datos, acciones no deseadas |
| 2 | Envenenamiento de herramientas | Instrucciones maliciosas dentro de las descripciones de las herramientas | Robo silencioso de datos |
| 3 | Rug pull | Un servidor cambia sus herramientas después de que las aprobaste | Lo aprobado no es lo mismo que lo actual |
| 4 | Credenciales filtradas | Los tokens acaban en configuraciones, registros o en el contexto del modelo | Toma de control de cuentas |
| 5 | Permisos excesivos | Un servidor funciona con alcance de administrador | Un solo error se convierte en una brecha |
| 6 | Paso de tokens (token passthrough) | Un servidor reenvía tokens que no se emitieron para él | Acceso más allá de lo previsto |
| 7 | Cadena de suministro | Paquetes de servidor parecidos a los legítimos o con puertas traseras | Código que se ejecuta en tu equipo |
La inyección de prompts es el riesgo principal porque no necesita código de explotación. En 2025, unos investigadores demostraron que una integración con GitHub podía ser manipulada, mediante una incidencia maliciosa en un repositorio público, para leer repositorios privados y devolver su contenido. El modelo hizo exactamente lo que se le pidió. Solo que la petición vino de un atacante.
Defensas que funcionan:
El envenenamiento de herramientas esconde instrucciones dentro de la descripción o el esquema de una herramienta. Tú ves una herramienta inofensiva que "suma dos números". El modelo ve un párrafo extra que le indica leer un archivo de credenciales y pasar su contenido como parámetro. El rug pull es la versión lenta: el servidor se comporta bien durante la revisión y, después de que lo apruebes, cambia en silencio sus definiciones de herramientas.
La solución es poco vistosa, pero eficaz. Calcula un hash de todo el manifiesto de herramientas (nombres, descripciones y esquemas) en el momento de la aprobación, compáralo en cada conexión y niégate a ejecutar cuando el hash cambie. Muestra a los usuarios la descripción completa, no un resumen recortado.
La cadena de suministro merece su propia línea. En 2025 se informó de que un servidor de correo con nombre parecido publicado en npm copiaba los mensajes salientes a una dirección externa tras una actualización rutinaria. La defensa son el fijado de versiones y una lista de permitidos (elementos 9 y 10 de la checklist).
Los secretos se filtran de formas poco llamativas: un token pegado en un archivo de configuración que termina en un commit, una variable de entorno que aparece en un registro de depuración, una contraseña de base de datos devuelta dentro de un resultado de herramienta que ahora queda en el contexto del modelo durante toda la sesión. Una vez que un secreto entra en el contexto, cualquier inyección posterior puede pedirle al modelo que lo repita.
Guarda los secretos en una bóveda o en el almacén de credenciales de tu sistema operativo, entrégaselos al proceso del servidor al arrancar y nunca los devuelvas en la salida. Prefiere tokens de vida corta que caduquen en minutos, porque un token robado que caduca a la hora de comer es un problema pequeño.
Un servidor que "solo necesita leer tickets" a menudo sale con un token de administrador, porque era el camino más rápido para hacer una demo. Entonces, una sola instrucción inyectada puede cerrar tickets, exportar listas de clientes o cambiar ajustes. Los permisos determinan el radio de daño, y tú eliges su tamaño el primer día.
Aplica el mínimo privilegio al verbo más estrecho: leer, no escribir; un proyecto, no todo el espacio de trabajo; una tabla, no la base de datos. Cuando un proveedor solo ofrece un token de todo o nada, pon delante un proxy ligero que exponga únicamente las llamadas que aceptas.
Pega esto en tu gestor de tareas y evalúa cada servidor con ello. Todo lo que hoy no puedas marcar se convierte en un ticket con responsable y fecha.
💡 Consejo: Los elementos 5, 11 y 17 son los más baratos de implementar y cierran las vías más peligrosas: acciones no aprobadas, cambios silenciosos en las herramientas y datos que salen de la red. Si tu semana es corta, empieza por ahí.
Una auditoría responde a una pregunta: ¿qué puede hacer ahora mismo el modelo y quién lo aprobó? Reserva una tarde, invita a un ingeniero y a un revisor de seguridad, y trabaja en tres pasadas. Antes de la primera, redacta un modelo de amenazas de una página con cuatro respuestas: a qué datos puede llegar el agente, qué contenido no confiable lee, adónde puede enviar datos y qué acciones son irreversibles.
No puedes proteger lo que no puedes listar. Recoge los servidores de los archivos de configuración de los clientes, los ajustes del IDE, los repositorios compartidos del equipo, los pipelines de CI y cualquier configuración "temporal" que nunca se eliminó. Registra esto para cada uno:
| Campo | Ejemplo |
|---|---|
| Nombre y origen | Paquete de un proveedor, repositorio interno o proyecto de la comunidad |
| Transporte | stdio local o HTTP remoto |
| Identidad usada | Cuenta de servicio, token personal o ninguna |
| Alcances concedidos | Leer tickets, escribir archivos, administrador |
| Datos a los que puede llegar | Registros de clientes, código fuente, web pública |
| Responsable | Una persona concreta, no un alias de equipo |
Prepárate para sorpresas. Los equipos suelen encontrar servidores que nadie recuerda haber instalado y que funcionan con un token personal de administrador.
Extrae treinta días de llamadas a herramientas y busca patrones que no deberían existir: llamadas a horas raras, resultados inusualmente grandes, herramientas invocadas justo después de que el agente leyera una página externa y argumentos que contienen rutas o URLs que el usuario nunca mencionó. Para clasificar a gran escala, un modelo como Claude Sonnet 5 puede agrupar miles de llamadas en una lista corta de anomalías, siempre que elimines antes los secretos y los datos personales.
Asigna a cada hallazgo una gravedad y un plazo. Mantén la escala pequeña para que la gente la use de verdad:
| Gravedad | Hallazgo de ejemplo | Plazo de corrección |
|---|---|---|
| Crítica | Token de administrador en un archivo de configuración compartido | 24 horas |
| Alta | Sin paso de aprobación para el correo saliente | 1 semana |
| Media | Versión de servidor sin fijar | 30 días |
| Baja | Falta el responsable de un servidor de pruebas | Próxima revisión |
Repite la auditoría después de cada cambio importante y al menos una vez al trimestre. Una lista de servidores que estaba limpia en enero rara vez lo está en junio.
La prevención acaba fallando, así que planifica el día en que ocurra. El objetivo es detectarlo en minutos y contenerlo en una hora.
Registra lo suficiente para reconstruir una sesión sin guardar secretos. Captura usuario, cliente, servidor, nombre de la herramienta, un hash de los argumentos, tamaño del resultado, latencia y la decisión de aprobación. Configura alertas primero para tres señales: una ráfaga de llamadas a una misma herramienta, cualquier llamada a una herramienta que nunca se había usado y resultados grandes poco después de que el agente consultara contenido externo.
Cada servidor necesita un interruptor de apagado que una sola persona pueda accionar sin un despliegue. Revoca sus tokens, elimínalo de la lista de permitidos y rota cualquier secreto que haya tocado. Después, restaura el último hash de manifiesto conocido como bueno. Practícalo una vez al trimestre para que el primer intento real no sea también el primer ensayo.
💡 Un techo en la plataforma también ayuda. PicassoIA, por ejemplo, limita cada cuenta a 5 predicciones simultáneas en todas las conexiones, así que un agente desbocado no puede saturar la cola. Pregunta a tus propios proveedores cuáles son sus techos.
Un clasificador de seguridad no sustituye a los permisos ni a las aprobaciones, pero añade un filtro útil. Llama Guard 4 12B lee texto o imágenes y devuelve un veredicto de seguro o no seguro con la categoría de daño correspondiente, que abarca áreas como la violencia, el odio y las instrucciones peligrosas. No es un detector específico de inyección de prompts, así que úsalo como una capa junto a los controles anteriores, por ejemplo para revisar lo que envían los usuarios y lo que tu agente está a punto de devolver.
| Parámetro | Valor sugerido | Por qué |
|---|---|---|
| Temperature | 0 | Misma entrada, mismo veredicto |
| Max Completion Tokens | 64 a 128 | Un veredicto es corto |
| System Prompt | Política más un formato de salida estricto | Fácil de procesar en código |
| Top P | 1 (por defecto) | Déjalo como está cuando la temperatura es 0 |
| Image Input | Capturas a revisar | Opcional |
El trabajo de seguridad es sobre todo invisible, y eso lo hace difícil de explicar. Las buenas imágenes ayudan: una foto de cabecera para un runbook, una ilustración de escenario para una diapositiva de formación, un pasillo de centro de datos para la wiki interna. PicassoIA convierte un prompt de texto en imágenes fotorrealistas y videos cortos, sin software de diseño ni licencias de fotos de archivo que controlar.
Pruébalo con el tema que acabas de leer. Describe una escena como "a security engineer reviewing a printed checklist in a quiet server room, soft window light, 35mm lens", ejecútala y luego ajusta el ángulo, la iluminación y el objetivo hasta que encaje en tu documento. Abre PicassoIA, explora la lista completa de modelos y experimenta hoy mismo con tus propios prompts.
Elige tu idioma
