Gestionar infraestructura con agentes de IA a través de MCP

Opfield tiene un servidor MCP junto a su API REST. Cualquier cliente MCP, como un agente de programación en tu editor o una aplicación de chat, puede conectarse y trabajar con los mismos recursos que una persona ve en la interfaz: rutas, contenedores, bases de datos gestionadas, Pages, alertas y nodos. En este artículo explicamos cómo se mantiene seguro ese acceso y cómo es una sesión típica.

Las mismas reglas que para una persona

Los agentes no tienen un modelo de permisos aparte. Un cliente MCP se conecta a https://<your-opfield>/api/mcp e inicia sesión con OAuth en nombre de un usuario. En la pantalla de consentimiento, el usuario elige los scopes que recibe el cliente, y nunca pueden ir más allá de lo que el propio usuario puede hacer. El acceso limitado a carpetas, nodos o recursos concretos funciona igual: un agente con acceso a la carpeta de una aplicación ve esa carpeta y nada más. El agente puede llamar a get_my_access para saber qué se le ha concedido y dónde puede crear recursos.

Los agentes pueden hacer con los recursos casi todo lo que hace una persona. Algunas cosas se quedan en el navegador a propósito: la suplantación de usuarios, el consentimiento OAuth, la creación de tokens de API o autorizaciones, y el inicio de sesión y las sesiones del propio usuario. Un agente no puede darse más permisos.

El endpoint MCP solo acepta tokens OAuth emitidos para él; los tokens de la API REST no funcionan allí. Además, el usuario necesita el permiso de MCP, así que un administrador decide quién puede conectar agentes.

Todo queda en el registro de auditoría

Cada acción de un agente pasa por las mismas comprobaciones que un clic en la interfaz y se guarda en el mismo registro de auditoría, con el usuario y el token de origen. Para ver qué cambió un agente durante la noche, basta con abrir el registro de auditoría.

Protecciones contra errores

Los permisos deciden qué puede hacer un agente. Pero algunos errores ocurren dentro de esos permisos, así que Opfield añade protecciones:

• Protección de la consola. Los agentes pueden ejecutar comandos como root en la consola de un nodo, lo que les permite repararlo. Docker, containerd y Podman están ocultos allí, y un comando de Docker se rechaza indicando la herramienta de Opfield que hay que usar. Es una protección contra errores, no una barrera de seguridad: evita que un agente cambie un contenedor gestionado a espaldas de Opfield.
• Sin SSH a los nodos. Los agentes no pueden ejecutar comandos por SSH en hosts que son nodos de Opfield. Para eso está la consola del nodo, con su protección.
• Los cambios fuera de Opfield se ven. Si aun así alguien detiene, cambia o elimina a mano un contenedor gestionado, salta la alerta integrada «Container changed outside Opfield».
• Reintentos seguros. Las operaciones de creación aceptan una clave de idempotencia, así que un agente que reintenta tras un tiempo de espera no crea un duplicado.

Herramientas de Docker en lugar de un shell

La mayor parte del trabajo de un agente con las cargas de trabajo pasa por herramientas específicas y no por comandos de shell: listar contenedores de todos los nodos Docker, leer logs y métricas, reiniciar, actualizar una imagen, cambiar la configuración, gestionar despliegues con slots y vuelta atrás, proyectos Compose, volúmenes, redes y fuentes de Git con sus builds. Como son operaciones de Opfield, las rutas, los Secure Links y la disponibilidad siguen siendo coherentes tras un cambio, y cada paso queda auditado.

Los agentes también pueden leer la documentación y las skills de Opfield a través de MCP antes de cambiar nada.

Ejemplo: un servicio caído

Un usuario escribe a un agente: «La API de facturación devuelve 502 desde esta mañana. Averigua por qué y arréglalo». Una sesión típica:

1. find_resource encuentra la ruta y el contenedor que hay detrás; get_route muestra el upstream.
2. get_docker_container muestra que el contenedor se reinicia una y otra vez y que su fuente de Git desplegó un build nuevo a las 07:40.
3. get_docker_container_logs muestra que el proceso termina al arrancar porque falta una nueva variable de entorno obligatoria.
4. El agente lo explica y ofrece dos opciones: volver al build anterior o añadir la variable.
5. El usuario elige volver atrás. El agente llama a manage_docker_source con rollback y vuelve a comprobar los logs y la ruta: el contenedor funciona y la ruta responde 200. La vuelta atrás aparece en el registro de auditoría con el nombre del usuario.

Nadie necesitó acceso por shell al servidor, y el agente no hizo nada fuera de los permisos del propio usuario.

Cómo empezar

Añade el servidor MCP en tu cliente con la dirección de tu Opfield, inicia sesión y elige los scopes. Empieza con scopes de solo lectura, mira en el registro de auditoría lo que hace el agente y amplía el acceso a medida que ganes confianza. Si prefieres no configurar un cliente, el asistente integrado en Opfield usa las mismas herramientas y las mismas reglas.