Trate un servidor MCP como código de terceros que actúa con sus credenciales y revíselo antes de que el agente pueda invocarlo. Las comprobaciones siguientes se basan en la especificación de autorización de MCP (revisión 2025-06-18) y en las mejores prácticas de seguridad de MCP (revisión 2025-11-25). Las revisiones difieren entre sí, así que consulte la especificación vigente antes de dar por válido cualquier requisito.
La autorización es opcional, así que compruebe que existe
Los servidores con transporte HTTP deben seguir la especificación de autorización. Los servidores con STDIO no deben hacerlo y, en su lugar, toman las credenciales del entorno. Si se trata de un servidor STDIO local, enumere las variables de entorno que la configuración de su cliente pasa al proceso y pregúntese si cada una es necesaria.
Si es un servidor HTTP, envíe una petición sin autenticar:
curl -i https://mcp.example.com/mcpDebería recibir un 401 Unauthorized con una cabecera WWW-Authenticate que indique la URL de los metadatos del recurso. Descárguela y compruebe que el documento contiene authorization_servers con al menos una entrada. Si el servidor responde con datos, deténgase ahí.
A continuación, confirme los puntos que la especificación marca como obligatorios:
- El cliente envía
Authorization: Bearer <access-token>en cada petición HTTP, y el token nunca aparece en la query string de la URI. - Los endpoints del servidor de autorización usan HTTPS, y las URI de redirección son localhost o HTTPS.
- El servidor de autorización compara las URI de redirección de forma exacta con los valores registrados previamente.
- Los clientes implementan PKCE.
Los clientes también deberían verificar el parámetro state, y los servidores de autorización deberían emitir access tokens de corta duración.
Audiencia y alcance del token
El cliente debe enviar el parámetro resource (RFC 8707) tanto en la solicitud de autorización como en la de token, y el servidor debe validar que cada token se emitió específicamente para él. De lo contrario, los tokens emitidos para otros servicios funcionan contra este.
El token passthrough es peor: el servidor acepta un token que no se emitió para él y lo reenvía sin modificar a los servicios posteriores. Controles como el rate limiting y la monitorización pueden depender de la audiencia del token, y los logs de los servicios posteriores pueden atribuir las peticiones a la identidad equivocada, lo que dificulta la investigación.
Para probar el vínculo con la audiencia, use un cliente registrado para solicitar un token para otro recurso al token_endpoint indicado en los metadatos del servidor de autorización. Reproduzca ese token contra el servidor MCP:
curl -i -H "Authorization: Bearer $OTHER_TOKEN" https://mcp.example.com/mcpDebería obtener un 401. Un token válido pero sin los permisos necesarios debería recibir un 403. Si el servidor de autorización no emite un token de ese tipo, pregunte al proveedor cómo comprueba la audiencia el servidor MCP.
Pregunte también dónde almacena el servidor los tokens. En los clientes públicos hay que rotar los refresh tokens, y los tokens almacenados en caché o registrados en logs en el servidor son un objetivo de robo.
Servidores proxy y consentimiento
Si el servidor MCP actúa de intermediario ante una API de terceros con un único client ID estático, lea la sección sobre el confused deputy de las mejores prácticas. El ataque requiere un client ID estático, registro dinámico de clientes, una cookie de consentimiento del servidor de autorización de terceros y la ausencia de consentimiento por cliente en el proxy. Lo último le corresponde corregirlo a usted: el proxy debería mantener un registro de valores de client_id aprobados por usuario y mostrar el nombre del cliente, los scopes y la URI de redirección en su propia página de consentimiento, que debe impedir su inclusión en iframes mediante frame-ancestors o X-Frame-Options: DENY.
Defina una lista de herramientas permitidas y redúzcala
Pida al servidor su lista de herramientas y compárela con lo que necesita la tarea. Todo lo que sobre es funcionalidad excesiva en los términos de OWASP LLM06:2025. Elimínelo o impida que el agente lo invoque.
Guarde la lista como línea base y compárela con un diff tras cada actualización del servidor, de modo que una herramienta añadida en una actualización se revise antes de que el agente pueda invocarla. Después, compruebe cada herramienta restante:
- ¿Es abierta, como "ejecutar un comando de shell" o "obtener una URL"? Sustitúyala por una herramienta acotada. El ejemplo de OWASP es una herramienta de escritura de archivos en lugar de acceso a la shell.
- ¿Qué identidad usa en los servicios posteriores? Una herramienta que lee datos debería conectarse solo con
SELECT, no conUPDATE,INSERTniDELETE. - ¿Actúa en nombre de un único usuario? Entonces debería autenticarse mediante OAuth con el scope mínimo, no mediante una cuenta genérica con privilegios.
Aplique los límites en el sistema posterior. OWASP lo llama mediación completa: no confíe en que el modelo decida si una acción está permitida.
Aprobación humana para acciones de escritura
La alucinación y la prompt injection son desencadenantes habituales de acciones dañinas, así que las acciones de alto impacto necesitan una persona en el circuito. OWASP describe un asistente de correo que resume los mensajes entrantes. Un correo con una inyección lo engaña para que rastree la bandeja de entrada en busca de información sensible y se la reenvíe al atacante.
Una extensión de solo lectura, un scope de OAuth de solo lectura o la revisión manual de cada correo redactado antes de enviarlo habrían cortado ese ataque. Combine estas medidas en capas siempre que pueda.
Todo lo que elimine, envíe o publique debe estar en la lista de aprobación. Sitúe la aprobación en la extensión o en el sistema posterior. El registro de logs y el rate limiting no previenen la agencia excesiva, pero facilitan detectar acciones no deseadas.
Si el cliente se ejecuta en el servidor
Durante el descubrimiento de OAuth, el cliente descarga URL que le proporciona el servidor, entre ellas resource_metadata, authorization_servers y token_endpoint. Un servidor malicioso puede apuntarlas a direcciones internas o al endpoint de metadatos de la nube en 169.254.169.254.
Exija HTTPS en producción, bloquee los rangos privados y reservados, y valide los destinos de redirección o desactive las redirecciones automáticas. No escriba a mano la validación de IP, porque los trucos con octal, hexadecimal e IPv6 mapeado a IPv4 derrotan a los analizadores personalizados. Valore un proxy de salida como Smokescreen.
Después, pruébelo. Monte un servidor de prueba hostil que devuelva un 401 cuya cabecera WWW-Authenticate lleve una URL resource_metadata que apunte a http://169.254.169.254/, y repita la prueba con una URL que redirija a una dirección interna. El cliente debería rechazar ambas, y un listener en el destino interno no debería ver ninguna petición.
Por dónde empezar
- Enumere todos los servidores MCP que usan sus agentes, con su transporte y su operador. Elimine los que no pueda justificar.
- Ejecute
curl -icontra cada servidor HTTP y confirme el401con una cabeceraWWW-Authenticate. Después, reproduzca un token emitido para otro recurso. - En los servidores proxy con client ID estático, revise el flujo de consentimiento: registro por cliente, contenido de la página de consentimiento y protección frente a iframes.
- Establezca la línea base de la lista de herramientas de cada servidor, redúzcala a lo que requiere la tarea, asigne a cada herramienta la identidad con menos privilegios y exija aprobación humana para las herramientas de escritura y borrado.
- En los clientes que se ejecutan en el servidor, realice la prueba de SSRF con un servidor de prueba hostil.
- Repita los pasos 2 a 5 cada vez que un servidor se actualice, añada una herramienta o cambie sus scopes.
Si necesita una revisión externa, consulte nuestro servicio de consultoría. Nuestro servicio de pruebas de penetración puede ejecutar las comprobaciones de token y de consentimiento sobre su entorno.
