)
Última actualización: 2 de noviembre, 2026
¿Cuáles son las buenas prácticas de seguridad en MCP? Las buenas prácticas de seguridad en MCP (MCP security best practices) son los controles que impiden que servidores y clientes del Model Context Protocol se vuelvan contra ti. En 2026 abarcan mínimo privilegio, definiciones de herramientas fijadas, sandboxing, OAuth con validación de audiencia, aprobación humana para acciones de riesgo y registro completo. Lo difícil es aplicarlas en tiempo de ejecución.
TL;DR: puntos clave
- El 55 % de 100 CISO encuestados ya usa servidores MCP u otras integraciones de agentes en producción. Al 46 % le preocupa que los agentes excedan sus permisos (Andreessen Horowitz, 2026).
- En un benchmark de 1.348 casos de tool poisoning sobre 45 servidores MCP reales, el modelo más expuesto alcanzó una tasa de éxito del ataque del 72,8 % (MCPTox, 2025).
- Ningún modelo rechazó más del 3 % de las instrucciones envenenadas, así que el alineamiento no basta como control (MCPTox, 2025).
- OWASP enumera 9 riesgos clave y 12 áreas de control, y su guía actual pide hacer el hash de la definición completa de cada herramienta (OWASP, 2026).
- La especificación MCP obliga a los clientes a enviar el parámetro
resourcede la RFC 8707 y prohíbe el token passthrough (especificación MCP, 2026).
De un vistazo: la checklist de seguridad MCP para 2026
Respuesta rápida
¿Qué buenas prácticas de seguridad en MCP importan más?
Empieza por cuatro controles: credenciales de mínimo privilegio por servidor, definiciones de herramientas revisadas y fijadas, servidores locales en sandbox y tokens OAuth ligados a la audiencia correcta. Después añade aprobación humana para acciones destructivas y registro centralizado. Cada fila indica si el responsable es el servidor, el cliente o ambos.
| Control | Servidores MCP | Clientes y hosts MCP | Compartido |
|---|---|---|---|
| Mínimo privilegio | Scopes estrechos, permisos por herramienta | Pedir solo los scopes básicos | Tokens de vida corta, sin credenciales compartidas |
| Integridad de herramientas | Versionar y documentar cada cambio | Mostrar la definición completa, calcular su hash y fijarla | Nueva aprobación ante cualquier cambio |
| Sandboxing | Publicar un contenedor o perfil restringido | Lanzar servidores locales con acceso mínimo | Red y ficheros denegados por defecto |
| Autorización | Validar la audiencia, nunca reenviar tokens | Enviar resource, usar PKCE con S256 | HTTPS siempre salvo loopback |
| Aprobación humana | Marcar con honestidad las herramientas destructivas | Confirmar llamadas de riesgo con todos los parámetros | Las anotaciones son pistas, no pruebas |
| Validación de entradas y salidas | JSON Schema estricto, sanear entradas | Tratar la salida de las herramientas como no fiable | Bloquear SSRF con listas de permitidos |
| Cadena de suministro | Firmar versiones, escanear dependencias | Instalar solo desde un registro aprobado | Inventario con responsables |
| Registro | Registrar cada llamada con contexto de usuario | Alertar ante herramientas nuevas o inusuales | Ocultar secretos, enviar a un SIEM |
Cómo comparamos
El 2 de noviembre de 2026 revisamos la cheat sheet de OWASP y dos páginas de la especificación MCP 2026-07-28. También la guía de OWASP GenAI, la de la NSA, Trail of Bits y MCPTox. La tabla es nuestra síntesis.
Qué cubren las buenas prácticas de seguridad en MCP en 2026
Las buenas prácticas de seguridad en MCP protegen tres piezas. Son el servidor que expone herramientas, el cliente que deja al modelo llamarlas y la frontera de confianza entre servidores. Importan porque es el modelo, no el desarrollador, quien decide qué herramienta llamar y con qué argumentos.
Según OWASP (2026), ese diseño mezcla prompt injection, ataques a la cadena de suministro y confused deputy. Su cheat sheet agrupa nueve riesgos clave, del tool poisoning y los rug pulls a las fugas de sandbox.
La guía ha cambiado este año. Según la versión 2026-07-28, MCP es stateless y no tiene sesiones de protocolo. El consejo sobre secuestro de sesión pasa a ser "state handle hijacking": un ID de carrito o de flujo no sirve como autenticación. Si diseñaste tus controles con la especificación de 2025, revísalos.
Quien construye servidores se ocupa de validación y scopes. Los equipos de cliente, del consentimiento y el sandboxing. Los de plataforma, del registro, el gateway y los logs. Si necesitas antes lo básico, empieza por nuestra guía de seguridad MCP y vuelve a esta checklist.
)
Mínimo privilegio y credenciales
Da a cada servidor MCP solo los permisos que necesitan sus herramientas, con credenciales propias y de vida corta. No compartas tokens entre servidores. Pide scopes OAuth estrechos y añade privilegios solo cuando una herramienta los necesite. Así limitas el daño si se filtra un token o si engañan al modelo.
Las MCP Security Best Practices (2026) aconsejan un modelo de scopes progresivo. Empieza con un scope mínimo para lecturas de bajo riesgo y eleva privilegios con desafíos WWW-Authenticate cuando se llame a una herramienta privilegiada. Los scopes comodín como * son un error habitual.
OWASP (2026) aconseja guardar los tokens OAuth en el almacén seguro del sistema, como macOS Keychain, y nunca en texto plano en la configuración de MCP.
| Haz esto | Evita esto |
|---|---|
| Una credencial por servidor, limitada a sus herramientas | Una única API key compartida por todos los servidores |
mail.readonly si la herramienta solo lee | mail.full_access "por si acaso" |
| Tokens de vida corta con rotación | Tokens de larga duración en mcp.json |
| Elevación de scopes para herramientas privilegiadas | Pedir todo el catálogo de scopes al inicio |
| Secretos en el llavero del sistema o en un vault | Secretos en el código fuente o en los logs |
Definiciones de herramientas y cadena de suministro: fijación, poisoning y rug pulls
Trata cada definición de herramienta como entrada no fiable. Muestra la definición completa antes de aprobarla, calcula su hash, fíjala y revísala cuando cambie. Instala servidores solo desde un registro verificado. Así frenas el tool poisoning, oculto en los metadatos, y los rug pulls, cuando una herramienta cambia tras aprobarla.
Según Trail of Bits (2025), un servidor MCP puede atacar antes de que se llame a ninguna herramienta, y lo llamó "line jumping". Al conectarse, el cliente añade las descripciones al contexto del modelo, y una descripción envenenada puede dirigir otras herramientas. MCPTox (2025) lo midió en 20 configuraciones de modelo. La tasa media de éxito fue del 36,5 %, y los modelos más capaces solían ser los más expuestos.
OWASP (2026) aconseja ahora el hash de la definición completa, con inputSchema, outputSchema y anotaciones. Cambiar readOnlyHint puede alterar la aprobación sin cambios visibles en el texto. La fijación detecta cambios en los metadatos, no en el código del servidor.
La guía de OWASP GenAI (2025) aconseja descubrir servidores solo desde un registro, fijar versiones con checksums y desplegar por fases. Vigila también el typosquatting. Nuestra guía sobre registros y listas de permitidos MCP explica ese flujo de aprobación.
Sandboxing y aislamiento entre servidores
Ejecuta los servidores MCP locales en un sandbox con acceso mínimo a ficheros, red y credenciales. Trata cada servidor como un dominio de seguridad propio, para que uno no pueda leer datos de otro ni manipular sus herramientas. El transporte stdio evita abrir un puerto, pero no limita el proceso.
Las MCP Security Best Practices (2026) advierten de que los servidores locales tienen los privilegios del cliente. La instalación en un clic debe mostrar el comando exacto y pedir aprobación. Según la NSA (2026), conviene aislar cada herramienta con seccomp, AppArmor, SELinux o AppContainers de Windows.
| Despliegue | Riesgo principal | Controles básicos |
|---|---|---|
| Servidor local por stdio | Código con los privilegios del usuario | Contenedor o sandbox, directorios permitidos, sin red |
| Servidor local por Streamable HTTP | Otros procesos locales o el DNS rebinding llegan a él | Escuchar solo en localhost, exigir token, validar Origin y Host |
| Servidor remoto por Streamable HTTP | Robo de tokens, SSRF | TLS, OAuth 2.1 con audiencia, límites de uso |
| Varios servidores en un host | Shadowing entre servidores | Separar los sensibles, vigilar flujos, usar un gateway |
Entre servidores, OWASP (2026) aconseja bloquear descripciones que citen herramientas de otro servidor. También pide vigilar credenciales que crucen de uno a otro y usar un proxy o gateway MCP.
Autorización, tokens y transporte
En servidores remotos, sigue el perfil OAuth 2.1 de MCP. El cliente envía el parámetro resource y usa PKCE con S256. El servidor acepta solo tokens emitidos para él y nunca reenvía el token del cliente a una API externa. Sirve todos los endpoints de autorización por HTTPS y valida las redirect URI de forma exacta.
Según las MCP Authorization Security Considerations (2026), el cliente debe detenerse si los metadatos del servidor de autorización no incluyen code_challenge_methods_supported. Los servidores de autorización deberían emitir access tokens de vida corta y deben rotar los refresh tokens de los clientes públicos. El token passthrough está prohibido porque rompe la trazabilidad.
Contra el confused deputy, un proxy MCP con client ID estático debe pedir consentimiento por cliente. La guía añade redirect URI exactas y valores state de un solo uso que caduquen pronto, por ejemplo en 10 minutos.
Un servidor malicioso puede apuntar las URL de descubrimiento OAuth a direcciones internas como 169.254.169.254. Bloquea rangos de IP privados, exige HTTPS, rechaza javascript: y no abras URL a través de una shell. Para flujos y ejemplos, consulta nuestra guía de autenticación MCP.
Aprobación humana, registro y control de salidas
Exige aprobación humana explícita para llamadas destructivas, financieras o que compartan datos, y muestra todos los parámetros, no un resumen. Registra cada llamada con su contexto de usuario. Trata toda respuesta de una herramienta como dato no fiable que puede traer instrucciones inyectadas, aunque venga de un servidor aprobado.
OWASP (2026) recuerda que el host debe obtener el consentimiento explícito del usuario antes de invocar herramientas. También advierte de que las anotaciones son pistas no fiables. Trail of Bits (2025) señala que, si el usuario aprueba comandos que no entiende, el "human-in-the-loop" se vuelve un sello de goma.
Por eso aplica la autorización en código de confianza, al margen de lo que concluya el modelo. OWASP (2026) indica que detectar patrones ayuda a alertar, pero no demuestra que el texto sea seguro.
Registra cada invocación con parámetros, usuario y hora, oculta los secretos y envía los logs a tu SIEM. Nuestra guía sobre prompt injection en MCP muestra cómo actúa en la práctica una salida de herramienta manipulada.
Seguridad y gobernanza: aplicar las buenas prácticas de seguridad en MCP en tiempo de ejecución
El riesgo está entre la política escrita y la llamada que se ejecuta a las 2 de la madrugada. El prompt injection, la fuga de datos y el mal uso de herramientas ocurren en ejecución, así que importan los controles aplicados en cada petición.
Andreessen Horowitz encuestó a 100 CISO de empresas con más de 1.000 empleados. Según Andreessen Horowitz (2026), el 55 % tiene servidores MCP u otras integraciones de agentes en producción. Al 47 % le preocupa que los empleados filtren datos sensibles a la IA, y el 46 % teme que los agentes excedan sus permisos. MCPTox (2025) demostró tasas de rechazo inferiores al 3 % frente al tool poisoning, así que no puedes contar con que el modelo diga que no.
| Punto de la checklist | Dónde se aplica |
|---|---|
| Lista de servidores permitidos y registro | Gateway delante de cada servidor MCP |
| Definiciones fijadas y alertas de cambio | Gateway o cliente, en cada conexión |
| Detección de prompt injection en salidas | Inspección en ejecución antes del modelo |
| Fuga de datos y secretos | Inspección en ejecución de argumentos y respuestas |
| Inventario de agentes y servidores | Gestión de postura |
| Prueba de que los controles funcionan | Red teaming antes y después de cada versión |
NeuralTrust lo aborda como una Runtime Security Mesh. La Agent Gateway (TrustGate) es una AI gateway con un catálogo de casi 200 servidores MCP preconfigurados y ofrece un único punto de control para el tráfico MCP. Agent Runtime Security (TrustGuard) cubre la protección en tiempo de ejecución. Agent Posture Management (TrustLens) ayuda con el inventario y la postura, y AI Red Teaming (TrustTest) comprueba que los controles aguantan. NeuralTrust se despliega como SaaS, en modo híbrido o en local.
¿Cuál deberías elegir?
No puedes desplegarlo todo la primera semana, así que elige según tu rol. Quien construye servidores empieza por scopes, validación y anotaciones honestas. Quien usa muchos servidores de terceros, por un registro, la fijación de definiciones y un gateway. Los sectores regulados priorizan los logs.
| Si eres | Empieza por | Después añade |
|---|---|---|
| Desarrollador de un servidor MCP | Esquemas estrictos, scopes estrechos, validación de audiencia | Versiones firmadas, anotaciones honestas |
| Equipo que usa servidores de terceros en el IDE | Servidores locales en sandbox, revisión completa de definiciones | Fijación con alertas de cambio, registro aprobado |
| Equipo de plataforma con agentes a escala | Gateway central, lista de permitidos, credenciales por servidor | Detección de inyecciones en ejecución, logs en el SIEM |
| Equipo de seguridad en un sector regulado | Aprobación humana para acciones sensibles, auditoría completa | Red teaming, revisiones de postura de cada agente |
| Equipo que publica un servidor MCP remoto | OAuth 2.1 con PKCE y resource, HTTPS | Límites de uso, controles de SSRF y de salida |
Conclusión
Las buenas prácticas de seguridad en MCP en 2026 se resumen en una lista corta: mínimo privilegio, definiciones fijadas, sandboxing, OAuth ligado a la audiencia, aprobación humana y registro. OWASP, la especificación MCP y la NSA coinciden en lo esencial. Lo que separa a los equipos es la aplicación real. El tool poisoning tiene éxito a menudo en las pruebas y los modelos casi nunca se niegan. Coloca la checklist donde pase cada llamada y ponla a prueba con regularidad.
Asegura tus servidores MCP en producción con NeuralTrust
Convierte esta checklist en políticas aplicadas en cada llamada MCP, con un gateway, controles en ejecución y red teaming.
)
Lecturas relacionadas
Preguntas frecuentes sobre buenas prácticas de seguridad en MCP
1. ¿Qué son las buenas prácticas de seguridad en MCP?
Son los controles que evitan el mal uso de servidores y clientes del Model Context Protocol. Incluyen credenciales de mínimo privilegio, definiciones fijadas, servidores locales en sandbox y OAuth 2.1 con validación de audiencia. También aprobación humana, validación de entradas, un registro verificado y logs completos. OWASP y la especificación MCP publican las versiones de referencia.
2. ¿MCP es seguro por defecto?
No. El protocolo ofrece piezas, pero muchas protecciones son opcionales o dependen de quien lo implementa. OWASP recuerda que la autorización es opcional, y los servidores locales tienen los privilegios del cliente salvo que uses un sandbox. La seguridad depende de cómo configures servidores, clientes y controles intermedios.
3. ¿Qué es el tool poisoning en MCP?
El tool poisoning es una prompt injection indirecta que esconde instrucciones maliciosas en la descripción, los parámetros o el esquema de una herramienta. El modelo lee esos metadatos al conectarse, así que el ataque funciona aunque nunca se llame a esa herramienta. Trail of Bits lo llama line jumping.
4. ¿Qué es un ataque rug pull en MCP?
Un rug pull ocurre cuando un servidor cambia la definición de una herramienta después de que la aprobaras. La defensa es calcular el hash de la definición completa, con esquemas y anotaciones, fijarla y exigir otra revisión cuando cambie. No detecta cambios ocultos en el código.
5. ¿Los servidores MCP locales deben usar stdio o HTTP?
Las MCP Security Best Practices recomiendan stdio para servidores locales, porque limita el acceso al cliente MCP. Aun así, stdio no aísla el proceso. Si usas HTTP en local, la especificación del transporte pide escuchar solo en localhost y validar la cabecera Origin, y las buenas prácticas añaden un token o IPC restringido, como sockets de dominio unix.
6. ¿Existen buenas prácticas oficiales de Anthropic para la seguridad en MCP?
Anthropic presentó MCP en noviembre de 2024, y la guía oficial está hoy en la documentación de modelcontextprotocol.io. Las páginas clave son Security Best Practices y Authorization Security Considerations, versionadas con la especificación. La cheat sheet de OWASP y la guía de la NSA de mayo de 2026 las completan.
7. ¿Necesito un gateway MCP para seguir estas buenas prácticas?
No es imprescindible, pero ayuda a escala. OWASP sugiere un proxy o gateway MCP para aislar servidores. Un gateway te da un único lugar para listas de permitidos, credenciales, registro y controles en ejecución, en vez de configurar cada cliente por separado. Las instalaciones pequeñas pueden apoyarse en el cliente.
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde dirige la estrategia de búsqueda de la compañía en SEO, AEO, GEO y optimización para LLM. Está especializado en búsqueda impulsada por IA, estrategia de contenidos y SEM. Conecta con él en LinkedIn.
NeuralTrust es la plataforma líder para proteger y escalar agentes de IA. Nombrada pionera en el Gartner Emerging Market Quadrant for AI Application Security 2026, reconocida en cuatro informes Gartner Hype Cycle en 2026 y destacada en la Gartner Market Guide for Guardian Agents 2026, la Gartner Market Guide for AI Gateways 2025 y el KuppingerCole Leadership Compass for Generative AI Defense 2025. Con sede en Barcelona y oficinas en Londres y Nueva York. Certificada ISO 27001.
Fuentes
Consultadas el 2 de noviembre de 2026.
- OWASP Cheat Sheet Series, "MCP Security Cheat Sheet", consultado el 2 de noviembre de 2026.
- Model Context Protocol, "Security Best Practices" (versión de la especificación 2026-07-28), 2026.
- Model Context Protocol, "Authorization Security Considerations" (versión de la especificación 2026-07-28), 2026.
- OWASP GenAI Security Project, "A Practical Guide for Securely Using Third-Party MCP Servers" v1.0, 23 de octubre de 2025.
- NSA Artificial Intelligence Security Center, "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation", 20 de mayo de 2026.
- Trail of Bits, "Jumping the line: How MCP servers can attack you before you ever use them", 21 de abril de 2025.
- Wang et al., "MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers", arXiv, 19 de agosto de 2025 (revisado en septiembre de 2026).
- Andreessen Horowitz, "The New Security Agenda", 28 de octubre de 2026.