Qué expone realmente un server MCP.
Un server MCP se siente como un adaptador simple. En una auditoría se lee como un gateway autenticado hacia tus sistemas. Este es el mapa que trazamos antes de revisar uno.
La versión corta
- Un server MCP no es solo una lista de herramientas; es un puente con credenciales entre un modelo y sistemas reales.
- La superficie de ataque real son cuatro cosas: las herramientas, las credenciales detrás de ellas, el alcance de red y la confianza depositada en las descripciones de las herramientas.
- Las descripciones de herramientas y sus resultados son entrada no confiable: pueden llevar una inyección directo al modelo.
- Hay que auditar cada herramienta como una capacidad, acotar sus credenciales y colocar una política determinista entre el modelo y el tool call.
El Model Context Protocol volvió componible el tooling de agentes, y justamente por eso concentra riesgo. Un solo server MCP puede entregarle a un modelo una docena de herramientas, cada una respaldada por una credencial, cada una capaz de alcanzar un sistema que importa. Cuando auditamos uno, la primera tarea es dejar de ver "una integración" y empezar a ver lo que realmente otorga.
Todo se reduce a cuatro superficies. Si las mapeas, tienes la imagen real; si las omites, estás confiando en un README.
1. La superficie de herramientas
Cada herramienta que registra un server MCP es una capacidad invocable. La pregunta interesante nunca es "¿para qué sirve esta herramienta?" sino "¿cuál es el peor tool call posible?". Una herramienta llamada search_docs que acepta una ruta arbitraria puede leer archivos. Una herramienta run_query con una conexión con permisos de escritura puede modificar datos. Una herramienta create_issue puede convertirse en un canal de notificación hacia el exterior.
Enumeramos cada herramienta, cada parámetro y el efecto máximo de una sola llamada, sin importar cómo "se supone" que el modelo la use. Los agentes no se quedan dentro del uso previsto, y tampoco los atacantes que los dirigen.
2. Las credenciales detrás de las herramientas
Las herramientas no actúan como el modelo. Actúan como el token que tenga el server. Aquí es donde el scope se convierte, en silencio, en lo único que importa. Un server MCP conectado a un personal access token con scope amplio sobre repositorios no le da al agente "acceso a GitHub": le da el acceso de ese token, a todos los repositorios, por tiempo indefinido.
Por cada credencial preguntamos: qué scope tiene, cuál es su vida útil, si se puede acotar por herramienta y si en algún momento queda expuesta de vuelta al modelo en un mensaje de error o en el payload de un resultado. Esto último pesa más de lo que los equipos esperan.
3. El alcance de red
Una herramienta que puede consultar una URL es una vía de egress. Una herramienta que puede alcanzar un hostname interno es un punto de pivote. Los servers MCP suelen correr con la red que tenga el proceso host, que en un runner de CI o en un contenedor de desarrollo puede ser mucha. Mapeamos qué puede alcanzar el server, hacia internet y lateralmente hacia servicios internos, porque eso define adónde pueden ir los datos y adónde puede enviarlos una instrucción inyectada.
4. La confianza depositada en las descripciones y los resultados
Este es el punto sutil, y el que la mayoría de las revisiones pasa por alto. Las descripciones de las herramientas, las pistas de los parámetros y los resultados de las herramientas fluyen de vuelta al contexto del modelo. Eso significa que un server MCP comprometido o malicioso puede inyectar instrucciones a través de la descripción de una herramienta, y que un server benigno puede retransmitir una inyección que vive en los datos que devuelve: una página web, el cuerpo de un issue, una fila de una tabla.
Los resultados de las herramientas son entrada no confiable. Trata cada byte que vuelve de una herramienta como tratarías el cuerpo de una petición que llega desde internet abierto.
Si aceptas ese encuadre, el problema del prompt injection y el problema de MCP son el mismo problema con distinta ropa: entrada no confiable que llega a una acción privilegiada. Y eso apunta a la misma solución.
Qué controles aplicar
No basta con auditar una vez y dar el tema por cerrado; los servers MCP y sus herramientas cambian. Por eso los controles tienen que vivir en el límite de confianza, de forma determinista:
- Lista de herramientas permitidas por entorno. Un entorno de agente recibe las herramientas específicas que necesita, no todas las que el server exponga.
- Credenciales acotadas a la herramienta. Tokens estrechos, vida útil corta, y nunca reflejar un secreto en un resultado que el modelo pueda leer.
- Alcance de red restringido. Declarar hacia dónde puede hacer egress cada herramienta y qué hosts internos puede tocar.
- Verificación a posteriori. Registrar qué herramientas se llamaron, con qué argumentos, y comparar contra la política que debía estar vigente.
La conclusión
Un server MCP es una de las piezas donde más rinde hacer las cosas bien, porque se ubica exactamente donde los modelos tocan los sistemas. Audítalo como un gateway con credenciales, acota cada herramienta al mínimo privilegio, trata todos los resultados como entrada no confiable y conserva evidencia verificable de lo que se llamó. Con eso, MCP se convierte en lo que debería ser: una superficie controlada, no un bypass silencioso.
Oktsec gobierna los hosts MCP como entornos de agentes de primera clase: herramientas acotadas, política firmada, evidencia verificada. Ver entornos soportados →