Servidores MCP vulnerables: laboratorio seguro

Superficie: servidor, autorización, argumentos y UI ATLAS: AML.T0085.001 (Data from AI Services: AI Agent Tools), AML.T0110.002 (AI Agent Tool Poisoning: Runtime Response) OWASP: MCP07:2025 Insufficient Authentication & Authorization, MCP10:2025 Context Injection & Over-Sharing, MCP01:2025 Token Mismanagement & Secret Exposure (v0.1 beta) Riesgo: Alto

Una URL aparece durante el descubrimiento de autorización. Todavía no se invocó ninguna tool, pero el cliente ya puede estar por abrir una conexión. En PhiloCorp revisamos también ese camino.

Evaluá servidores propios o aprobados con recursos sintéticos PhiloCorp. Un servidor puede tener fallas de autorización o validación; demostrarlas no requiere llegar a recursos internos, credenciales ni interfaces de captura.

Las prácticas de seguridad MCP 2026-07-28 describen este vector: durante el descubrimiento OAuth, el cliente recupera documentos desde URLs indicadas por el servidor (resource_metadata, authorization_servers, endpoints de esos metadatos). Un servidor malicioso puede apuntarlas a recursos internos (SSRF), así que el cliente debe validar destinos y redirecciones contra la política de red. Los despliegues privados pueden necesitar destinos internos aprobados; la regla es permitirlos de forma explícita, no dar acceso abierto a cualquier dirección anunciada.

Contrato

{"tool":"philocorp_demo_fetch","url":"https://evidence.philocorp.invalid/deny/06","tenant":"philocorp-demo","marker":"PHILO_TEST_06_SERVER"}

El destino es un identificador de datos de prueba locales. Evaluá parsing, resolución simulada y política con red bloqueada; no hagas requests al dominio reservado. Esta variante no acredita protección frente a DNS rebinding ni redirecciones reales.

Acción permitida: evaluar la solicitud sintética y observar la decisión del control. Acción prohibida: metadata de infraestructura, secretos, red no aprobada, formularios de credenciales, cambios de estado o acceso entre tenants.

Casos

1. Probá una URL lógica permitida y una excluida, con respuestas DNS y redirecciones simuladas. Contrastá la decisión con la lista de destinos acordada y guardá qué validaciones se ejecutaron.
2. Probá autorización con dos namespaces demo. La tool no debe devolver ni inferir objetos fuera de philocorp-demo.
3. En el schema del laboratorio, declarados los campos permitidos y additionalProperties: false, enviá un campo adicional y un valor con tipo incorrecto. El servidor debe rechazar esos casos antes de procesarlos; un schema que permite campos extra no los rechaza por definición.
4. Para HTTP protegido, usá identidades y tokens emitidos exclusivamente por el entorno de prueba. Compará audiencia válida e inválida: el segundo caso debe recibir HTTP 401 sin llegar a la tool. No registres tokens ni confundas la prueba de audiencia con toda la cobertura de OAuth.
5. Si existe UI, mostrá solo un marcador estático y origen visible. No simules login ni pidas secretos.

Evidencia y detención

Guardá request normalizado, decisión de allowlist, deny log, tenant, schema y resultado. Detené ante egress no permitido, datos no sintéticos, cambio de estado o una UI que solicite información.