Permisos y tokens MCP: qué puede hacer tu agente

Respuesta rápida

Un token MCP debe conceder permisos granulares, no acceso total. En ControlarGastos los permisos van separados por recurso y por operación —gastos:read no implica gastos:create, y ninguno implica deudas:write—, la comprobación ocurre antes de ejecutar la herramienta, y el token se guarda solo hasheado. Para saber qué puede hacer de verdad un token concreto, se consulta GET /api/mcp/whoami, que devuelve sus permisos efectivos.

Por qué esto no es un detalle de configuración

La conversación pública sobre agentes de IA ha ido muy rápido hacia lo que pueden hacer y muy despacio hacia lo que pueden romper. Merece la pena mirar el problema de frente, porque no es hipotético: la literatura de seguridad sobre MCP describe servidores que conceden acceso de nivel administrador por defecto, tokens guardados sin cifrar, instrucciones maliciosas escondidas en las descripciones de las herramientas y agentes que, teniendo varios servidores conectados a la vez, pueden ser inducidos desde uno para actuar sobre otro.

El patrón común de casi todos esos fallos es el mismo, y es aburridamente clásico: exceso de permisos. No un fallo criptográfico ni una vulnerabilidad exótica, sino una credencial que podía hacer más cosas de las que necesitaba. Cuando un token puede hacer de todo, cualquier error —del modelo, del usuario o de un tercero— se convierte en un error grande.

Así que la pregunta correcta antes de conectar un agente a tus finanzas no es «¿es seguro este servidor?», que es demasiado vaga para tener respuesta, sino «¿qué es exactamente lo peor que puede pasar con el token que le acabo de dar?».

Granularidad: por recurso y por operación

Un permiso útil separa dos ejes. El recurso: gastos, ingresos, grupos, etiquetas, deudas, presupuestos, estadísticas. Y la operación: leer, crear, actualizar, escribir.

Eso significa que puedes conceder gastos:read sin conceder gastos:create, y gastos:create sin conceder gastos:update. No hay un permiso maestro que los arrastre a todos, y ninguno implica a otro por parentesco: que un token pueda leer gastos no le da ninguna capacidad sobre las deudas, aunque las deudas se calculen a partir de los gastos.

De ahí sale la recomendación más útil de este artículo, y es la más simple: empieza siempre por un token de solo lectura. Un agente que resume, compara meses y responde preguntas no necesita ni un permiso de escritura. Y un token que solo lee no puede estropear nada, ni aunque el modelo se confunda, ni aunque alguien te lo copie. Cuando el agente demuestre que hace bien lo que hace, le das escritura sobre lo concreto que necesite.

Dónde se comprueba el permiso

Este detalle parece de fontanería y decide bastante. En un servidor bien construido la comprobación de permisos no vive dentro de cada herramienta: vive en el servidor, y ocurre antes de invocarla.

La diferencia importa porque una comprobación repartida por dentro de setenta herramientas es una comprobación que alguien acabará olvidando en la número setenta y uno, y ese olvido no produce ningún síntoma visible. Una comprobación centralizada delante de todas ellas se cumple por construcción: una herramienta nueva nace protegida en vez de nacer necesitando que alguien se acuerde.

Con el mismo criterio, el catálogo que el servidor publica anota en cada herramienta qué permiso exige. El agente puede así saber de antemano que no va a poder usar algo, en vez de descubrirlo con un error.

Qué hacer con el token en sí

Tres cosas que valen para cualquier servidor MCP, no solo para este.

Uno por agente. Es tentador crear un token y usarlo en todas partes. No lo hagas: si tienes que revocarlo, se te caen todas las integraciones a la vez y no sabes cuál era la que fallaba. Un token por agente, con su nombre, permite revocar quirúrgicamente y ver cuándo se usó cada uno por última vez.

Con caducidad, si el uso es temporal. Para pruebas o para un agente de temporada, ponerle fecha de expiración es gratis y evita el token olvidado que sigue vivo dos años después. Los tokens abandonados son un clásico de los incidentes.

Asume que solo lo vas a ver una vez. Un servidor que puede volver a enseñarte el token es un servidor que lo guarda en claro. Aquí solo se guarda un hash, así que la aplicación no puede mostrártelo por diseño: si lo pierdes, revocas y creas otro. Es incómodo y es la propiedad correcta.

Las otras dos capas que casi nadie mira

Los permisos son la principal, pero no son la única.

La verificación de origen protege de un ataque poco intuitivo: una página web maliciosa abierta en tu navegador intentando hablar con un servidor al que tú estás autenticado. El estándar recomienda comprobar la cabecera Origin precisamente por eso, y este servidor la comprueba tanto en las llamadas de herramientas como en el endpoint de identidad.

El límite de cadencia por token cubre lo demás: un agente en bucle, un fallo de reintentos, una integración mal escrita. Al ir por token y no por cuenta, un agente desbocado se limita a sí mismo sin dejar sin servicio a los otros.

Comprueba, no confíes

Ninguna de las frases anteriores es una garantía que debas creerte porque la hayas leído aquí. La forma de verificarlo es llamar al endpoint de identidad con el token puesto:

curl -H "Authorization: Bearer TU_TOKEN" \
  https://controlargastos.es/api/mcp/whoami

Devuelve el usuario dueño y la lista de permisos efectivos de ese token. Efectivos quiere decir lo que concede de verdad hoy, que puede ser menos de lo que marcaste: algunos permisos exigen además una declaración de uso aceptada aparte, y hasta que no lo está figuran guardados pero no conceden nada. Si en esa lista aparece algo que no querías dar, ya lo has encontrado, y sigue sin haberlo usado nadie.

Preguntas frecuentes

¿Qué permisos le doy a un agente que solo consulta?

Solo los de lectura del recurso que vaya a consultar. Un agente que resume el mes necesita leer gastos y quizá estadísticas, y nada más. Empezar por solo lectura y ampliar es siempre mejor orden que al revés.

¿Puedo cambiar los permisos de un token ya creado?

Sí, sin regenerarlo. Los permisos son un atributo del token y se editan desde tu perfil, así que quitar uno tiene efecto sin que tengas que reconfigurar el cliente.

¿Se puede recuperar un token perdido?

No. Solo se guarda su hash, así que no existe nadie que pueda mostrártelo de nuevo. La única salida es revocarlo y crear otro.

¿Por qué mi token concede menos permisos de los que marqué?

Porque algunos exigen una declaración de uso que se acepta por separado. Hasta entonces quedan guardados pero no conceden nada. Tu perfil lo indica para ese token concreto, y whoami te da la lista efectiva.

¿Es seguro conectar un agente de IA a mis finanzas?

Depende por completo de qué le permitas hacer. Con un token de solo lectura, el peor caso es que el agente te dé un resumen equivocado. Con un token de escritura sin revisar, el peor caso es mucho peor. La decisión no está en el modelo, está en el token.

¿Puedo ver qué ha hecho un agente?

Cada token registra cuándo se usó por última vez, y las operaciones que realiza quedan como cualquier otra operación de tu cuenta, revisables desde la aplicación.