Parte 06 - Evaluación de seguridad MCP
- Parte
- 06
- Estado
- Revisado
- Edición
- v2 / 01.09.2026
- Tiempo estimado de lectura
- 3 min
Edición del 1 de septiembre de 2026
Las fuentes conservan sus fechas de consulta. El laboratorio identifica la simulación determinística y la integración con modelo por separado.
El catálogo cambia durante la noche
En el caso ficticio de PhiloCorp, el inventario aprobado describe una tool de solo lectura. Al día siguiente el nombre es el mismo, pero la descripción y el schema ya no coinciden con el hash revisado. El servidor sigue siendo de PhiloCorp; la confianza, en cambio, acaba de perder su ancla.
Como consultor externo, reconstruís la relación completa entre cliente, servidor, identidad y efecto. No alcanza con que una tool exista en un catálogo ni con que el modelo la seleccione correctamente. Cada solicitud debe sostener la autorización y la procedencia que correspondan a su transporte. Los registros de denegación pasan al Attack Intelligence Brief: muestran qué control evaluó la llamada y dónde se detuvo, sin confundir una respuesta del modelo con una decisión del servidor.
| Tema | Qué vas a comprobar |
|---|---|
| Protocolo MCP e inventario autorizado | Identidad, scopes, manifiestos y denegaciones seguras |
| Integridad de tools | Procedencia y cambios de manifiesto |
| Límites de permisos y aislamiento | Mínimo privilegio y rechazo fuera de scope |
| Encadenamiento seguro de tools | Políticas de efecto, aprobación y deny logs |
| Servidores MCP no confiables | Autorización y procedencia de interfaz |
| Laboratorio de integridad y autorización | Práctica con marcadores de prueba |
Qué versión estamos evaluando
El corte de esta parte es MCP 2026-07-28: las solicitudes son autocontenidas y el protocolo base es stateless. Eso no impide que la aplicación conserve objetos o tareas. La autorización MCP es opcional y depende del transporte; registrá la versión negociada antes de aplicar un test.
| Transporte o versión | Frontera que revisás |
|---|---|
| HTTP protegido con autorización MCP | Token en cada solicitud, audiencia propia del servidor, scopes y descubrimiento de autorización. |
| stdio | Identidad y permisos del proceso, origen del servidor y credenciales mínimas del entorno; no usa el flujo OAuth de MCP. |
| Otros transportes | Mecanismo de identidad y seguridad documentado por la implementación. |
| MCP 2025-11-25 o anterior con sesión | Si usa Mcp-Session-Id, revisá generación, ciclo de vida y vinculación con el sujeto autenticado. |
Un handle de estado identifica un objeto, no prueba la identidad de quien lo presenta. En un servidor autenticado, verificá autorización en cada acceso. En uno sin autenticación, un handle puede funcionar como capacidad al portador: requiere entropía, vida útil acotada y límites de exposición. No lo confundas con aislamiento por usuario.
La especificación MCP 2026-07-28 y sus apartados de autorización y tools sustentan estos contratos. Los ejemplos JSON de esta parte son contratos y datos de laboratorio salvo que se indique expresamente que son mensajes del protocolo.
Condiciones de detención: secretos, recursos fuera del laboratorio, cambio de estado, salida de red no aprobada o cambio de manifiesto no autorizado.
{"tool":"philocorp_demo_read","resource":"philocorp-demo://status/06","effect":"read_only","marker":"PHILO_TEST_06_MCP_AUTHZ"}Al cerrar MCP, el Brief debería unir identidad de servidor, contenido revisado y decisión de acceso. La Parte 07 sigue el contenido que viaja por esas herramientas hasta el corpus de PhiloCorp.
Una decisión antes de seguir
El nombre y esquema de una tool no cambiaron, pero su descripción sí. ¿El hash anterior sigue validando el catálogo?
Anotá qué afirmarías y qué observación falta. Contrastá tu respuesta.
El expediente avanza. El origen de herramientas lleva a otra fuente de instrucciones: los documentos recuperados.
Para practicar: Damn Vulnerable MCP Server.