La nueva especificación MCP traslada responsabilidades de seguridad a desarrolladores. Descubre riesgos y mitigaciones para producción.
La nueva especificación del Model Context Protocol (MCP) de Anthropic, lanzada en junio de 2026, transfiere las responsabilidades de seguridad directamente a los desarrolladores. Antes, el protocolo se encargaba de ello. Ahora, eres tú.
Este cambio no es reciente. Los equipos que despliegan Claude con MCP en producción, Simple Booking en el sector hotelero, X con sus servidores MCP para agentes IA, ya se hacen la pregunta: ¿dónde exactamente están las grietas?
El cambio de responsabilidad: de dónde viene el problema
La nueva especificación MCP es enterprise-ready, es cierto. Pero esa palabra esconde una realidad: Anthropic ha trasladado deliberadamente parte de los controles de seguridad hacia la capa del desarrollador para ganar flexibilidad.
Concretamente, significa tres cosas:
1. Autenticación menos implícita
Antes, MCP incluía mecanismos de seguridad por defecto. Ahora, debes construir tu cadena de autenticación. Una agencia de e-commerce Shopify que conecta Claude a una base de clientes debe gestionar cómo un agente Claude accede a datos sensibles: nombres, emails, números de teléfono. Sin magia aquí.
2. Los permisos granulares se vuelven tu problema
MCP ya no dice "esta herramienta puede leer pero no escribir". Eres tú quien lo dice. Un agente podría potencialmente ejecutar una acción para la que no está autorizado si no has establecido los límites. Simple Booking conoce este dilema: sus conectores MCP integran un CRS (Central Reservation System), eso afecta directamente las reservaciones de clientes. Un permiso mal configurado = una reservación modificada por error.
3. Las inyecciones de prompts se vuelven más críticas
Claude es inteligente, pero si un agente MCP acepta una instrucción del exterior sin validación, "llama a la herramienta X con el parámetro Y", acabas de crear una vía de entrada para un atacante. Los adversarios no buscan hackear el protocolo. Buscan manipular tu agente.
Las cuatro trampas concretas que encuentran
Trampa 1: credenciales expuestas en variables de entorno
Lo clásico. Tu servidor MCP necesita una clave API para comunicarse con una base de datos. La pones en .env. Bien hasta aquí. Excepto que tu contenedor Docker o tu función AWS Lambda expone estas variables en logs si algo falla.
Con MCP, cada error de conexión al servidor remonta a Claude. Claude lo registra. Y si Claude está en modo debug o si los logs no están cifrados, adiós a tu clave.
Mitigación: usa un gestor de secretos (Vault, AWS Secrets Manager). Inyecta las credenciales en tiempo de ejecución, nunca de forma hardcodeada.
Trampa 2: confianza ciega en el servidor MCP
Despliegas un servidor MCP que expone 15 herramientas. Claude está conectado. Un desarrollador junior añade una nueva herramienta que elimina registros de clientes. Sin revisión de acceso, Claude puede llamarla.
Peor: si este servidor está en tu red interna y alguien compromete otra máquina en la red, pueden pivotar para enviar comandos MCP falsificados.
Mitigación: cada herramienta MCP debe tener una lista explícita de quién puede llamarla. ¿Claude? Sí, pero solo si responde a X criterios. Audita las herramientas regularmente.
Trampa 3: los timeouts infinitos que bloquean
Un servidor MCP responde lentamente o no responde. Claude espera. Mientras tanto, una solicitud del usuario se estanca, la sesión permanece abierta, la memoria se dispara. No es una falla de seguridad directa, pero crea vectores de DoS.
Peor si es intencional: alguien envía una solicitud que fuerza a MCP a realizar una operación muy larga (un escaneo de base de datos gigantesco, un cálculo costoso).
Mitigación: timeout estricto en cada llamada MCP. 5s, 10s máximo. Sin infinito.
Trampa 4: sin logging o logging insuficiente
Si Claude llama a una herramienta MCP y no registras la acción, la marca de tiempo, los parámetros, el resultado, no tienes trazabilidad. Una agencia hotelera que descubre 500 reservaciones canceladas no tendrá ninguna pista para rastrear qué pasó.
Las defensas que debes implementar
1. Autenticación fuerte entre claude y tu servidor MCP
MCP usa JSON-RPC en una conexión stdio o HTTP. Si es HTTP, usa HTTPS + un token Bearer válido. Mejor: mTLS con certificados de cliente.
Test: tu servidor MCP debe rechazar cualquier solicitud sin autenticación válida. Sin excepciones.
2. Autorización por rol (rbac) o por atributos (abac)
Define explícitamente quién puede llamar a qué herramienta.
| Rol del Agente | Herramientas autorizadas | Parámetros limitados |
|---|---|---|
| ReadOnlyAnalyst | GetBookings, GetReviews | Sin parámetros sensibles |
| ReservationManager | CreateBooking, ModifyBooking | Modificaciones < 3 días antes de llegada |
| Admin | Todas | Sin límite |
Implementa esto en tu servidor MCP. Antes de ejecutar una herramienta, verifica el rol de Claude (o más precisamente, el contexto de la sesión que lo usa).
3. Validación y sanitización estricta
Cada parámetro recibido por MCP debe ser validado:
- Tipo correcto (cadena, número, etc.)
- Longitud limitada (sin 10 MB de texto en un campo)
- Formato validado (una fecha es realmente una fecha, un email es realmente un email)
- Sin caracteres escapados que podrían hacer una inyección SQL
// Ejemplo: endpoint que crea una reservación
// MALO
app.post('/MCP/create-booking', (req, res) -> {
const booking = req.body; // Peligro directo
db.insertBooking(booking);
});
// BIEN
app.post('/MCP/create-booking', (req, res) -> {
const schema = z.object({
clientId: z.string().uuid(),
checkIn: z.string().date(),
nights: z.number().min(1).max(365),
roomType: z.enum(['single', 'double', 'suite'])
});
const validated = schema.parse(req.body); // Lanza si no es válido
db.insertBooking(validated);
});
4. Logging exhaustivo con contexto
Cada llamada MCP debe registrarse con:
- Marca de tiempo exacta
- Identidad del agente (o del contexto que lo usa)
- Herramienta llamada + parámetros completos
- Resultado (éxito, error, excepción)
- Duración de la ejecución
- Dirección IP de origen (si es relevante)
Almacena estos logs en un sistema inmutable (CloudWatch, Splunk, o un simple archivo append-only cifrado).
5. Monitoreo y alertas en tiempo real
Detecta anomalías:
- Demasiadas llamadas a una herramienta en poco tiempo -> intento de DoS
- Una herramienta llamada con parámetros anormales -> ataque de fuzz
- Errores repetidos -> reconocimiento o escaneo de vulnerabilidades
Configura una alerta si Claude llama 100 veces a "GetUserData" en 30s.
El caso de escuela: X y sus servidores MCP
X (antes Twitter) lanzó servidores MCP para que Claude, Cursor, Grok Build y otras herramientas de IA puedan acceder a X directamente. Es la misma lógica que Simple Booking y las reservaciones hoteleras.
La diferencia: los datos en X son públicos por defecto. Un agente puede recuperar tweets sin daño. Pero si tuvieras un servidor MCP de X que expusiera DMs privados o analytics internos, el escenario cambiaría completamente.
Anthropic y X han asumido que los desarrolladores que integran estos servidores sabrán poner barreras. Spoiler: no siempre es el caso.
Preguntas frecuentes
¿Debemos cifrar la comunicación MCP incluso en localhost?
Sí si datos sensibles transitan. Si es solo cálculo inofensivo (convertir temperatura Celsius a Fahrenheit), no. Pero desde el momento en que hay cliente, cuenta, pago: cifra.
¿Cuál es la diferencia entre MCP y una API REST clásica desde el punto de vista de seguridad?
Fundamentalmente: ninguna. MCP es solo una convención JSON-RPC. Los mismos principios de seguridad se aplican. La diferencia es que muchos desarrolladores piensan que porque es "para IA", es menos crítico. Error.
¿Cómo pruebo la seguridad de mi servidor MCP?
Haz fuzzing: envía parámetros aleatorios, strings gigantescos, nulls, caracteres raros. Usa herramientas como Burp Suite para interceptar llamadas MCP. Intenta inyección SQL en cada parámetro. Mide los timeouts. Busca bypasses de rol.
¿Hay una certificación o norma para MCP seguro?
Aún no. MCP es demasiado joven. Anthropic publica recomendaciones pero nada oficial. En su lugar, aplica estándares de seguridad de API clásicos: OWASP Top 10, funciona.
¿Cómo gestiono MCP si el agente claude necesita derechos de administrador?
Escenario pesadilla: necesitas darle a Claude la capacidad de eliminar datos. Opción 1: dale una herramienta separada "DeleteWithConfirmation" que solicita aprobación humana (le dices al sistema "aprueba al agente para esta acción"). Opción 2: herramientas granulares con roles muy limitados. Opción 3: no lo hagas y usa un humano para operaciones destructivas.
¿Es suficiente la autenticación entre claude y MCP, o también necesito asegurar claude -> anthropic?
Las dos. Debes confiar en el tubo entre Claude y tu servidor. Pero también debes confiar en Anthropic para no registrar/exponer tus datos. Anthropic tiene garantías de confidencialidad para planes Enterprise. Verifica tu contrato.
Conclusión
La nueva especificación MCP de Anthropic es más flexible pero menos segura por defecto. La seguridad ya no está incorporada. Depende de ti.
Los tres reflejos a tener:
- Autenticación fuerte entre Claude y MCP, HTTPS + tokens, mTLS si es posible.
- Autorización granular, cada herramienta tiene una lista explícita de quién puede llamarla y cómo.
- Observabilidad completa, cada llamada se registra, es auditable, alertable.
Si despliegas MCP en producción sin estos tres pilares, estás jugando a la ruleta rusa. Y spoiler: la bala terminará en la recámara.
¿Necesitas ayuda para asegurar tu implementación de MCP? Hablemos de tu arquitectura en fstck.co, tenemos casos reales en hotelería, e-commerce y fintech.
