Seguridad MCP: permisos mínimos para que una IA administre un VPS
Publicado el 2026-10-26 por frfrand
Diseñar herramientas MCP seguras con alcances, aprobaciones y auditoría
Una IA puede ayudarte a desplegar una app, pero darle acceso de administrador a todos los VPS para que consulte un log es como repartir la llave maestra del edificio. El problema no es que sea una IA; es el exceso de permisos y alcance.
Vamos a bajarlo a tierra: qué significa, cómo se prueba y qué pasa cuando lo usás con clientes o información real. La mayoría de los problemas no se arregla con un botón mágico, sino con pasos que podés repetir y medir.
Qué es Permisos mínimos para MCP y por qué importa
Una integración MCP segura necesita autenticación, autorización en servidor, acciones con alcance delimitado y auditoría. Los parámetros suministrados por un modelo o texto externo no deben considerarse confiables: el backend debe validar permisos para cada recurso y operación.
Una cosa es que una demo funcione cinco minutos y otra es sostener un servicio todos los días. Para eso necesitás límites, permisos, registros de actividad y procedimientos para resolver fallos sin improvisar.
Ejemplo de implementación o diagnóstico
// Ejemplo conceptual de autorización
function canRestart(user, vps, service) {
return user.companyId === vps.companyId
&& user.permissions.includes('service.restart')
&& service.vpsId === vps.id;
}
// La verificación real debe ocurrir en el backendEs una referencia didáctica, no una plantilla que debas ejecutar a ciegas en producción. Sustituí los valores de ejemplo, elegí identidades con permisos mínimos y asegurate de que ninguna clave sensible termine en un log o repositorio.
Cómo lo pondría a funcionar
- Empezá con permisos de consulta; ampliá sólo cuando una tarea real lo necesite.
- Separá
logs.read,deploy.create,service.restartyvps.deleteen capacidades distintas. - Comprobá que un usuario de Empresa A no puede consultar IDs de Empresa B.
- Registrá cada acción y protegé tokens con expiración y revocación.
- Exigí revisión humana para borrados, cambios de acceso o modificaciones irreversibles.
Después de cada paso, verificá un resultado concreto: una acción autorizada, un estado HTTP, una tarea procesada, un costo registrado o una métrica estable. Si algo no funciona, comprobá cuál fue el primer fallo antes de reintentar en bucle.
Un ejemplo que puede aparecer en un proyecto real
Un freelancer administra los servidores de dos clientes. Un agente que prepara un deploy para el cliente A no debería poder seleccionar arbitrariamente el ID del VPS de B. El servidor debe comprobar propiedad y permisos en cada llamada.
Si esa aplicación tiene varios clientes, separá contextos y recursos. Es especialmente importante cuando un chatbot o un agente puede consultar datos: la facilidad de conectar herramientas no debe saltarse los límites de privacidad y autorización.
El error más común
No confíes en una instrucción del prompt como barrera de seguridad. Un texto malicioso dentro de logs o documentación puede intentar inducir llamadas peligrosas; las reglas deben estar del lado del servidor.
Una configuración con buenos defaults ayuda, pero no elimina la necesidad de pruebas. Para servicios que escriben datos o disparan acciones, contemplá reintentos, duplicados y fallos a mitad de camino.
¿Dónde entra ArduMaker?
ArduMaker organiza Empresas, proyectos y VPS. En flujos MCP aprovechá esa separación con scopes y registros de acciones para no dar al agente más autoridad de la necesaria.
Con ArduMaker podés alojar el backend en un VPS, desplegar desde Git, configurar dominio HTTPS y utilizar herramientas de bases, servicios y MCP según el proyecto. Eso facilita reunir operaciones en un entorno, aunque las reglas de negocio y de seguridad siguen siendo responsabilidad del software.
Qué mediría para saber si mejoró
No mediría sólo «funciona/no funciona». También revisaría consumo de recursos, errores, tiempos de respuesta o gasto de API, según la funcionalidad. Definí una medida de éxito antes del cambio y compará con el mismo escenario después.
Si un dato parece extraño, comprobá la muestra y la ventana temporal. Un promedio puede esconder casos extremos, y una única ejecución exitosa no demuestra que una automatización soporte miles de solicitudes.
Preguntas frecuentes
¿Necesito una infraestructura grande para empezar? No necesariamente. Primero resolvé el problema con una arquitectura simple y medí el punto donde empieza a quedarse corta.
¿Qué pasa si falla el proveedor externo? Necesitas timeouts, política de reintentos y una respuesta útil para el usuario. No asumas que las APIs externas están siempre disponibles.
¿Cómo mantengo el control? Registra eventos importantes, separa permisos y conserva un procedimiento probado para deshacer cambios o recuperar información.
Referencias para seguir
La idea final: automatizar y medir vale la pena cuando también sabes detectar un error, limitar sus efectos y recuperarte.