Inyección de comandos y validación de entradas: proteger herramientas que ejecutan acciones

Introducción

Una herramienta puede parecer una función sencilla y terminar ejecutando un proceso, consultando una base de datos o modificando un recurso externo. Si la entrada se concatena en un comando o se interpreta sin controles, aparece un riesgo de inyección. La causa está en el diseño y la implementación de la herramienta, no en MCP como protocolo.

Validar el significado, no solo el formato

Define esquemas estrictos: tipos, longitudes, formatos y campos permitidos. Rechaza valores inesperados con errores claros. Pero una entrada que cumple el esquema puede seguir estando fuera de autorización: comprueba también que el usuario puede operar sobre ese recurso y que la herramienta permite esa acción en su contexto.

Cuando necesites invocar un proceso, utiliza APIs estructuradas o ejecución con argumentos separados en vez de concatenar datos en una cadena de shell. Evita intérpretes cuando no sean necesarios. Usa rutas permitidas, directorios de trabajo controlados y un entorno aislado con permisos mínimos.

Para operaciones con efectos, limita la acción a una tarea concreta; no conviertas instrucciones libres del modelo en comandos arbitrarios. Aplica límites de tiempo, salida y recursos. El servicio que recibe la petición debe validar su propia autorización: la validación del cliente o una confirmación de interfaz no bastan.

Pruebas y errores seguros

Prueba límites, campos ausentes, tipos incorrectos y entradas inesperadas con datos de prueba no dañinos. Comprueba que una operación rechazada no deja efectos parciales. Mantén mensajes de error útiles para diagnosticar, sin devolver secretos, rutas internas o detalles que no sean necesarios.

Conclusión

La defensa combina validación semántica, autorización, APIs seguras, aislamiento y pruebas negativas. La salida más segura suele ser una operación estrecha y predefinida, no un intérprete general conectado al modelo.