Salvaguardas MCP: permisos seguros para agentes de IA

Un token MCP es la contraseña de tu cuenta con una API conectada. Dáselo a un agente y tendrás un usuario que nunca se cansa, lee cualquier página a la que lo mandes y hace exactamente lo que dijo la última instrucción de su contexto. Casi siempre eso es lo que quieres. Esta página va del resto de las veces.

Todo lo que sigue se comprobó contra el servidor en producción en la fecha de arriba: la lista de herramientas sale de tools/list en https://mcp.eqvps.com/mcp, los límites de la propia API. Si eres nuevo, empieza por conectar un cliente MCP y tokens de API, y luego vuelve.

Modelo de amenazas: lo que de verdad sale mal

Tres cosas, en el orden en que las vemos:

1. El agente entiende mal. «Limpia la máquina de pruebas» se convierte en reinstalar el servidor equivocado. Sin malicia: solo un modelo que rellena un hueco en la instrucción.
2. Inyección de prompt. El agente lee un texto que no escribiste tú (un README, una respuesta de soporte, una página web) y ese texto le dice que haga algo. Si el agente tiene un token con todos los derechos, la instrucción inyectada también los tiene.
3. El token se filtra. Acaba en un historial de shell, un repositorio público, una configuración MCP compartida o una línea de log.

El servidor MCP comprueba que el token es válido y que el servidor pertenece a esa cuenta (o le fue delegado). No sabe qué querías decir. Cada salvaguarda de abajo responde a una sola pregunta: ¿cuánto daño es posible si la instrucción está mal?

Todas las herramientas MCP, por nivel de riesgo

Un token de cliente ve 45 herramientas (servidor MCP 1.6.0). Un token de revendedor (rk_…) ve un conjunto aparte de 30 herramientas de revendedor y ninguna de estas, así que el endpoint tiene 75 en total. Tu cliente recibe solo su propio conjunto desde tools/list.

Esta página ordena las herramientas por riesgo. Los parámetros y ejemplos de llamadas de cada una están en la referencia de parámetros; todas las herramientas en una línea, incluidas las 30 de revendedor, en la lista completa.

Todavía no publicamos anotaciones de herramientas MCP (readOnlyHint, destructiveHint), así que tu cliente no puede clasificarlas solo. Configura las aprobaciones a mano según los niveles de abajo.

Nivel 0 — públicas, sin token (5)

Nivel 1 — lectura de la cuenta, sin efectos secundarios (15)

Nivel 2 — cambian el estado, no gastan nada (17)

Nivel 3 — gastan dinero, destruyen datos o conceden acceso (8)

Registro de cambios del conjunto de herramientas

La versión en marcha es pública: curl -s https://mcp.eqvps.com/healthz. Cuando cambie, esta tabla cambiará con ella.

El saldo es el tope de gasto

EQVPS es prepago. Sin tarjeta guardada, sin línea de crédito y sin descubierto: lo máximo que un agente puede gastar es lo que haya en el saldo. Gastan tres herramientas: order_vps, change_plan y create_sandbox. Las renovaciones de tus servidores actuales salen del mismo saldo.

El agente puede crear peticiones de dinero, pero no pagarlas. topup_balance y pay_invoice devuelven un enlace de pago cripto, y un enlace no hace nada sin una billetera detrás. Tampoco hay endpoint de retiro: el dinero del saldo puede comprar servicios en tu cuenta, no salir de ella. Los reembolsos de una cancelación inmediata también vuelven al saldo.

Una advertencia, y va en serio. Si dejas el saldo muy bajo para frenar al agente, empiezan a fallar tus propias renovaciones y los servidores entran en periodo de gracia. Nuestra regla práctica: un ciclo de renovación de lo que ya tienes en marcha, más el presupuesto de la tarea actual del agente. La guía de presupuesto para agentes explica cómo calcularlo. Y si le das al agente su propia billetera con fondos, esa billetera se convierte en un segundo tope que también tendrás que vigilar.

Mínimo privilegio: (todavía) no hay token de solo lectura

Respuesta directa: cualquier token de cliente tiene los mismos derechos que la cuenta en el panel. El nombre y la duración de un token se configuran; los scopes, no.

Lo más acotado que existe hoy es la delegación. Le das al agente su propia cuenta, con saldo cero, y le delegas un servidor:

delegate_service  { "service_id": "EQ-XXXX", "email": "agent@yourdomain.com", "expires_days": 30 }

Lo mismo por REST:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/services/EQ-XXXX/delegations" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"email":"agent@yourdomain.com","expires_days":30}'

La invitación debe aceptarse con la sesión iniciada en ese email (accept_delegation), y expires_days va de 1 a 365. Paso a paso con capturas: delegar acceso y el acceso en la documentación.

Fíjate en las dos últimas filas de la izquierda. Un delegado no puede gastar tu dinero, pero sí borrar ese servidor. Activa las copias de seguridad en cualquier servidor que un agente pueda reinstalar.

Higiene de tokens

Un token por agente, con nombre. Créalo en Panel → Ajustes → Tokens de API para agentes, o así:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/auth/tokens" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"backup-agent","expires_in_days":90}'

El token se muestra una sola vez. Duración de 1 a 1825 días, 365 si no indicas nada. Para agentes elegiríamos 90.

Guárdalo en un archivo que solo tú puedas leer: no en el repositorio, no en el prompt, no en una variable de shell que vas copiando:

mkdir -p ~/.config/eqvps && chmod 700 ~/.config/eqvps
( umask 077; read -rsp 'EQVPS token: ' T; echo; printf 'EQVPS_TOKEN=%s\n' "$T" > ~/.config/eqvps/agent.env )
ls -l ~/.config/eqvps/agent.env   # esperado: -rw-------

Luego cárgalo en el servicio del agente con EnvironmentFile= (systemd) o set -a; . ~/.config/eqvps/agent.env; set +a.

Rótalo antes de que caduque. La herramienta refresh_token, o POST /auth/tokens/{id}/refresh, emite un token nuevo con el mismo nombre y revoca el anterior al momento. Si tu cliente MCP tiene el token fijo en su configuración, actualízala justo después o la siguiente sesión recibirá un 401.

Revisa quién usa qué: GET /auth/tokens lista cada token con su nombre, caducidad y last_used_at. Un token que no reconoces, o uno usado después de apagar al agente, es tu señal.

Si se filtra un token

En este orden:

1. Revócalo. Panel → Ajustes → Tokens de API para agentes → Revocar, o curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. Deja de funcionar en la siguiente petición.
2. Busca tokens nuevos que no hayas creado tú y revócalos también.
3. Revisa la superficie de daño: el historial del servicio de cada servidor, tus facturas y saldo, y list_delegations por si hay accesos que no concediste.
4. Cambia las contraseñas root de todos los servidores que ese token podía ver. get_vps_status con reveal: true entrega la contraseña root, así que un token filtrado es una contraseña root filtrada. Revisa ~/.ssh/authorized_keys de paso.
5. Cierra la puerta de la contraseña. Si tu cuenta nunca tuvo contraseña, quien tenía el token pudo fijar una con set_password. Entra con un código por email y cámbiala.

Prevenir el paso 5 no cuesta nada: fija tú una contraseña de cuenta ahora, y set_password devolverá 409 a cualquiera que venga después.

Aprobación humana

Lo que impone el servidor:

• reinstall_vps, reset_password y cancel_service con type: immediate exigen confirm igual al hostname exacto (DELETE también vale para reinstalar y restablecer).
• change_plan exige confirm: true.
• La cancelación por defecto es end_of_period: el servidor sigue hasta el final del periodo pagado y undo_cancel la revierte.
• Límites por cuenta: reinstalación 4/min, restablecer contraseña 6/min, encendido 20/min, pedidos 20/min. Suficiente para que un bucle no lo haga cincuenta veces, no para frenar una sola llamada errónea.

Ten claro qué es confirm. Evita que un agente actúe ante un «límpialo». No frena a un atacante, porque el hostname está a una llamada de get_vps_status. La aprobación real vive en tu cliente MCP. La mayoría de los clientes pueden preguntar antes de cada llamada: deja pasar los niveles 0 y 1 y haz que el nivel 3 pregunte siempre. En clientes con permisos por herramienta, como el settings.json de Claude Code (servidor registrado como eqvps):

{
  "permissions": {
    "ask": ["mcp__eqvps__order_vps", "mcp__eqvps__change_plan", "mcp__eqvps__create_sandbox", "mcp__eqvps__reset_password", "mcp__eqvps__delegate_service"],
    "deny": ["mcp__eqvps__reinstall_vps", "mcp__eqvps__cancel_service", "mcp__eqvps__kill_sandbox"]
  }
}

Añade también una línea a las instrucciones del agente. Por sí sola no es un control de seguridad, pero recorta los malentendidos (déjala en inglés, los modelos la entienden igual de bien):

Never call reinstall_vps, reset_password, cancel_service (type=immediate), change_plan,
order_vps, create_sandbox, kill_sandbox or delegate_service unless the human has typed
the target server's hostname in this conversation for that specific action.

Si el agente inicia sesión con un código por email en lugar de guardar un token de larga duración, consulta el inicio de sesión del agente por MCP.

Auditoría: qué puedes ver después

• Lista de tokens (GET /auth/tokens, o Ajustes → Tokens de API para agentes): nombre, creación, caducidad, last_used_at. Por eso importa nombrar los tokens por agente.
• Historial del servicio (panel, página del servidor): acciones de encendido, reinstalaciones, restablecimientos de contraseña, cambios de plan, pagos, cada uno con hora y autor: tú, soporte o automático. No dice qué token o delegado actuó, solo que vino de tu lado.
• Facturas y saldo: cada cargo y cada reembolso.
• list_delegations: quién tiene acceso a qué y hasta cuándo.

Ese hueco en el historial del servicio es el límite honesto de la auditoría del lado del servidor hoy. Si necesitas saber qué agente hizo qué, registra cada llamada a herramientas con sus argumentos (sin secretos) del lado del agente.

La configuración que usaríamos

Para un agente que gestiona un servidor de producción:

1. Una cuenta aparte para el agente, saldo cero, el servidor delegado con expires_days: 90.
2. Tu token de propietario se queda contigo, fuera de cualquier configuración del agente.
3. Copias de seguridad en ese servidor, porque un delegado puede reinstalar.
4. Las herramientas de nivel 3 en «ask» o «deny» en el cliente.
5. El token del agente en un archivo 600, renovado antes de que caduque.

Para un agente que tiene que pedir servidores o lanzar sandboxes, la delegación no basta, porque necesita saldo. Ahí el saldo es tu tope: recárgalo por tarea, ponle nombre al token y mira last_used_at una vez por semana. Si un token de solo lectura cambiaría tu forma de desplegar agentes, cuéntanoslo en soporte: ese tipo de comentarios decide qué construimos después.