Capítulo 12 — Endurecimiento del protocolo y defensas
Duodécima entrega del recorrido capítulo por capítulo de LLM Primer IV: Designing AI Cognition with MCP. En el que cada amenaza del capítulo anterior recibe una defensa, ninguna defensa es bala de plata, y la composición es lo único que produce una postura que realmente se pueda desplegar.
Por qué existe este capítulo
El protocolo no se vuelve seguro por desplegarse. Se vuelve seguro al desplegarse dentro de una pila que compensa las asunciones que el protocolo desnudo hace. El Capítulo 11 catalogó las amenazas; éste recorre las defensas con profundidad de ingeniería. La atestación criptográfica de capacidades cierra las clases de descubrimiento y de escalado de capacidades. La disciplina de scopes OAuth 2.1 con tokens delegados por el usuario cierra las clases de deputy y passthrough. Las vidas de sesión acotadas cierran la clase de hijack de sesión. El sandboxing contiene los compromisos que la prevención no detiene. La aprobación human-in-the-loop atrapa las operaciones destructivas que el resto de la pila tendría que automatizar para resultar útil. Cada defensa deja riesgo residual; la composición es lo que hace los residuales lo bastante pequeños como para defenderlos en la práctica.
12.1 AttestMCP: atestación criptográfica de capacidades
La primera defensa aborda un problema que atraviesa casi todas las amenazas: el host no tiene forma de verificar que el servidor con el que habla es lo que dice ser. AttestMCP — también llamado MCPSec o manifests de capacidad firmados — añade una capa de atestación criptográfica sobre la estructura de mensajes del protocolo. Un publicador tiene una clave de firma de larga vida registrada en un directorio o transparency log. El manifest de capacidades completo se hashea y se firma en el momento de release. El host verifica la firma en initialize contra la clave del publicador que tiene en ficha, y admite el servidor, lo pone en cuarentena o rechaza la conexión.
Los beneficios son reales. Los typosquats no pueden producir una firma válida del publicador legítimo. El escalado de capacidades a través de notificaciones list_changed se vuelve detectable porque un manifest nuevo requiere firma nueva. La política de grano fino — "confía en servidores publicados por GitHub para repositorios pero no para correo" — se vuelve aplicable porque la identidad del publicador es ahora verificable en vez de simplemente afirmada. Los costes también son reales: los publicadores deben correr infraestructura de firma, los transparency logs necesitan un operador de confianza, y la capa de política del host debe entender la revocación. El encuadre honesto es que AttestMCP es ingeniería sustancial, no una casilla a marcar. Y tiene un hueco que conviene nombrar: el manifest firma lo que el servidor dice sobre sí mismo, no lo que hace en tiempo de ejecución. Una declaración firmada de una herramienta benigna puede aun así enviar una implementación exfiltradora. La atestación es necesaria pero insuficiente, razón por la cual existe el resto del capítulo.
12.2 Scopes OAuth 2.1 y vidas de sesión acotadas
El segundo grupo aprieta el modelo de credenciales y de sesión. Los flujos de OAuth 2.1 son maduros; la ingeniería está en usarlos bien. La primera disciplina es la de scopes estrechos — pide sólo lo que la superficie de herramientas declarada necesita. Cuanto más estrecho el scope, menor el radio de explosión. La disciplina es más difícil de lo que suena porque los servicios aguas arriba a menudo definen scopes de manera gruesa y el camino estrecho es tedioso; los scopes amplios funcionan al primer intento y se sienten como progreso. El coste de los scopes estrechos lo paga el ingeniero; el coste de los amplios lo paga el usuario cuando algo va mal.
La defensa contra Confused Deputy que la disciplina de scope sola no da es la de tokens delegados por el usuario. Donde el upstream lo soporte, cada usuario completa su propio flujo OAuth, y el servidor actúa con el token del usuario en vez de con su propia identidad de servicio. El diputado desaparece porque el servidor ya no actúa bajo su propia autoridad. Token passthrough tiene un arreglo distinto: no pases tokens. El servidor guarda sus propias credenciales, establecidas en el momento de registro, y la frontera entre host y servidor nunca lleva un token. Las vidas de sesión acotadas abordan el hijack: minutos para operaciones de alto riesgo, horas para las rutinarias, con identidad durable de flujo de trabajo encima para que una tarea de varias horas pueda renovar sesiones de transporte sin re-prompt al usuario cada quince minutos. La vinculación de capacidades por sesión y la re-confirmación de capacidades en la renovación de sesión completan la disciplina — ambas son trabajo de gestión de estado que el host debe hacer explícitamente, y muchas implementaciones no lo han hecho.
12.3 Sandboxing y aislamiento en tiempo de ejecución
El tercer grupo reconoce que no toda amenaza se puede prevenir y que una postura defendible debe contener el daño cuando la prevención falla. El sandboxing de procesos para servidores locales — seccomp en Linux, App Sandbox en macOS, AppContainer en Windows, gVisor para aislamiento más fuerte — niega filesystem, red y acceso a procesos por defecto y sólo concede los accesos específicos que el servidor necesita. Un servidor comprometido intentando leer un fichero de contraseñas o exfiltrar hacia un endpoint del atacante se encuentra con la operación rechazada en la capa del SO, no porque el código del servidor se contuviera sino porque el sandbox lo hizo. La política de red para servidores remotos — TLS mutuo, endpoints en allowlist, filtrado de salida — estrecha la superficie que un servidor remoto comprometido puede alcanzar. El aislamiento de contenido dentro del host trata el contenido devuelto con la sospecha adecuada antes de que aterrice en el contexto del modelo: marcadores de no confiable, sanitización HTML, rechazo a seguir URLs embebidas. El sandboxing de llamadas a herramientas mediante políticas conscientes de capacidad permite al host examinar los argumentos de la llamada y decidir si permitir, denegar o escalar a aprobación del usuario. Un riesgo específico que conviene nombrar es la exfiltración por canal lateral a través de herramientas legítimas — un modelo malicioso codificando credenciales en una consulta de búsqueda — que la capa de política atrapa inspeccionando argumentos en vez de endpoints. El aislamiento de cadena de suministro cierra el bucle: el hash del binario se verifica al instalar y actualizar contra un valor firmado en el transparency log, así un binario manipulado no puede correr aunque el manifest pase las comprobaciones.
12.4 Puertas de aprobación human-in-the-loop
El cuarto grupo reconoce que algunas operaciones nunca deberían automatizarse. Las llamadas destructivas, irreversibles o de alto impacto — enviar dinero, borrar ficheros, modificar producción — merecen una decisión humana explícita en el momento en que ocurren. El mecanismo es la puerta HITL, y la ingeniería está en hacerla efectiva sin volver inusable el sistema. Categoriza por reversibilidad: las operaciones de sólo lectura proceden automáticamente; las que cambian estado se cierran. Preséntala de manera significativa: un modal que dice "¿Permitir ejecución de herramienta?" es un sello de goma; una puerta útil muestra la herramienta, los argumentos completos, la consecuencia en lenguaje llano y la procedencia. Evita la fatiga de aprobación con aprobación contextual en lote, donde un usuario que inicia "envía facturas a los clientes del último trimestre" aprueba el lote una vez en vez de cada correo veinte veces. Encamina las operaciones de alto riesgo fuera de banda — token de hardware, segundo dispositivo, autenticación step-up tomada del sector financiero. Mantén las operaciones visibles, auditables y deshacibles. Las llamadas dirigidas por sampling pasan por las mismas puertas que las iniciadas por el agente; el canal lateral de la inferencia iniciada por el servidor no puede terminar en un efecto secundario sin que el usuario se entere.
Lo que prepara el Capítulo 12
La mitad de seguridad del cuadro de ingeniería está ahora completa. La otra mitad — frameworks, patrones de despliegue, características de rendimiento y las pruebas que confirman que el sistema funciona en producción — es lo que los capítulos restantes asumen. El Capítulo 13 abre ese arco recorriendo los frameworks e integraciones cloud que aterrizaron a lo largo de 2025 y 2026: Strands con Amazon Bedrock, los patrones de capa de estado de AWS, Microsoft Agent Framework, LangChain y Semantic Kernel. Los frameworks importan porque nadie construye MCP de producción desde el protocolo crudo, y las elecciones entre ellos dan forma a la postura de ingeniería y seguridad de maneras que la capa de protocolo sola no determina.
Próximamente — Capítulo 13: Frameworks e integración con la nube. Strands con Bedrock, la capa de estado de AWS, el Agent Framework de Microsoft, LangChain, Semantic Kernel y los tres patrones de integración de producción a los que los equipos llegan de forma independiente.
