Cómo acotar el acceso de un agente de IA a tu espacio de trabajo: alcances MCP, mínimo privilegio y registro de auditoría

Por qué los permisos de un agente no son los de un usuario

Una persona lee la pantalla antes de actuar. Un agente lee la descripción de una herramienta y actúa en milisegundos, cientos de veces por hora, sobre texto que puede venir de una página web, un correo o un ticket escrito por alguien de fuera de la empresa. La inyección de prompts es el ejemplo habitual, pero los errores corrientes son más frecuentes: un agente al que se le pide "limpiar las incidencias antiguas" y entiende "limpiar" como "borrar".

De ahí se siguen dos consecuencias. Primera, el radio de daño de una acción equivocada solo lo limita lo que el token puede hacer, así que el token debe ser pequeño. Segunda, no puedes revisar cada acción de antemano, así que necesitas un registro lo bastante bueno para revisarla después.

Los permisos de usuario responden a "¿qué puede ver y cambiar esta persona?". Los permisos de agente responden a "¿qué puede hacer este programa en nombre de esta persona, para esta tarea, esta semana?". La segunda pregunta tiene una respuesta más estrecha.

Qué te da la especificación de autorización de MCP

La especificación de autorización del Model Context Protocol (la revisión 2025-06-18, la vigente a octubre de 2026) trata al servidor MCP como servidor de recursos OAuth 2.1 y al cliente MCP como cliente OAuth 2.1. Las partes que importan para acotar:

La especificación deja deliberadamente los nombres y la granularidad de los alcances a cada servidor. Te da el mecanismo (consentimiento, audiencia, 403) y te deja la política. El resto de este artículo es la política.

La receta: lecturas primero, ampliar por escritura, nunca superar a la persona

Cinco reglas, en el orden en que las aplicamos.

1. Empieza solo con alcances de lectura, en las áreas que toca la tarea. Un agente que redacta el estado semanal necesita leer incidencias, objetivos y el feed. No necesita leer clientes, nóminas ni contratación. Elige los tres o cuatro alcances de lectura y para.
2. Añade un alcance de escritura solo cuando una tarea con nombre lo necesite, y solo ese. "Comentar la incidencia que implementó" necesita escritura de incidencias. No necesita escritura de proyectos, de páginas ni la capacidad de publicar en el feed del equipo. Si un alcance de escritura implica su lectura, bien; lo contrario nunca es cierto.
3. Trata las acciones destructivas y las que salen al exterior como concesiones separadas. Borrar, publicar, enviar correos y notificaciones son las acciones que no puedes deshacer. Mantenlas tras sus propios alcances y, a ser posible, tras una confirmación que la persona vea.
4. Un token nunca debe superar a la persona que lo emitió. Si un token de agente pudiera leer algo que su dueño no puede, los alcances se han convertido en una vía de escalada. Resuelve los permisos del dueño en cada llamada, no al emitir, para que revocar el acceso del dueño revoque el del agente.
5. Audita cada llamada y lee la auditoría. Nombre de la herramienta, resultado, tipo e id de lo tocado. No el contenido: un registro de auditoría lleno de datos de clientes es una segunda brecha esperando a ocurrir.

El modo de fallo que hay que evitar es la pantalla de consentimiento "conectar todo", donde el host del agente pide todos los alcances de golpe y la persona aprueba porque la lista es larga. Las listas cortas se leen.

Ejemplo real: los 49 alcances de Atrix AI

El servidor MCP de Atrix es el que administramos, así que es el ejemplo honesto. A octubre de 2026 tiene 85 herramientas tras 49 alcances concedibles, listados en la documentación para desarrolladores. Las decisiones de diseño encajan con las reglas de arriba:

• Pares de lectura y escritura por área: work.read, work.write, crm.read, crm.write, pages.read, pages.write, etc. Un alcance de escritura implica su lectura; nada más se implica.
• Alcances con nombre para las acciones que no se deshacen o que salen fuera: destructive, publish, email.send, feed.post. Nunca los implica un alcance de escritura. feed.post está separado de feed.write porque publicar notifica a los teléfonos de la gente sin opción de desactivarlo.
• Nueve alcances exigen además el permiso correspondiente en la cuenta que está detrás del token: valores de tratos, registros laborales, acuerdos, contratación, integraciones, facturación, facturas y cambio de productos. El permiso se comprueba en cada llamada, así que un token nunca puede hacer más que su creador, y revocar el acceso de alguien anula de inmediato el alcance de sus tokens.
• La nómina no es concedible en absoluto. Ningún alcance llega a un salario y ninguna herramienta selecciona un registro de compensación. Algunos datos no deberían estar a un clic de consentimiento de un agente, y la forma de garantizarlo es dejarlos fuera de la lista de alcances.
• Límites y auditoría: 120 llamadas y 30 escrituras por minuto y token; cada llamada se registra con herramienta, resultado, tipo e id del sujeto, nunca el contenido.

Lo que cuesta: un compañero que conecta Claude o Cursor ve un selector de alcances y tiene que pensar treinta segundos. El servidor de Linear, en comparación, ofrece una URL separada de solo lectura, una forma más simple de expresar "solo lecturas". Ambos enfoques funcionan; el nuestro pone la decisión en la persona, el suyo en la URL.

Step-up: ampliar cuando la tarea lo pida, no antes

La alternativa a conceder alcances de escritura por adelantado es la autorización step-up: el agente trabaja con lecturas, recibe un 403 en su primera escritura y el host pide a la persona que apruebe el alcance extra para esa sesión. La entrada del glosario sobre autorización step-up describe el patrón; la especificación lo permite mediante el 403 y una nueva ronda de consentimiento.

En la práctica funciona así. El agente redacta el informe de estado (solo lecturas). Apruebas el borrador. Pide feed.post para publicarlo. Se lo concedes a ese token, o publicas el borrador tú. El alcance de escritura existe exactamente el tiempo que la tarea lo necesita.

El step-up es más lento que una concesión amplia el primer día y más rápido a partir del segundo, porque el conjunto de alcances que un agente se ha ganado deja de crecer cuando sus tareas se estabilizan.

Una lista de comprobación para pegar en tu política de seguridad

• Los agentes se autentican con OAuth 2.1 mediante el flujo de consentimiento del host; sin claves de larga duración en archivos de configuración salvo en CI.
• Cada token de agente lista sus alcances, su dueño, su fecha de creación y su último uso.
• La concesión por defecto es de solo lectura para como máximo cuatro áreas.
• Los alcances de escritura se conceden por tarea y se revisan cada mes.
• Las acciones destructivas, de publicación, de correo y de notificación requieren su propio alcance y una confirmación humana.
• Los permisos del dueño se resuelven en cada llamada; revocar al dueño revoca al agente.
• Hay límites de tasa por token.
• El registro de auditoría guarda herramienta, resultado, tipo e id del sujeto, y se revisa cada semana.
• Algunos datos (la nómina, como mínimo) no son alcanzables por ningún alcance.

Preguntas frecuentes

¿Qué son los alcances MCP?

Alcances OAuth 2.1 que un servidor MCP define para limitar lo que un token puede hacer, elegidos por la persona en la pantalla de consentimiento. La especificación MCP exige que los servidores respondan 403 cuando una llamada supera los alcances del token. Los nombres y la granularidad dependen de cada servidor; consulta la entrada del glosario sobre alcances.

¿Debe un agente de IA tener los mismos permisos que su usuario?

No. Los permisos del usuario son el techo, no el valor por defecto. Empieza con alcances de lectura en las áreas que toca la tarea y añade escrituras de una en una. El token debería resolver los permisos del usuario en cada llamada para no superarlos nunca.

¿Es aceptable una clave de API en un archivo de configuración para un agente?

En CI, donde no hay navegador, sí, con los alcances más estrechos y un calendario de rotación. En el portátil de una persona, prefiere el flujo OAuth: el token está acotado, es de corta vida, se renueva y se revoca, y la especificación exige PKCE y vinculación de audiencia.

¿Cómo sé qué hizo realmente un agente?

Por el registro de auditoría del servidor. Pide nombre de herramienta, resultado y tipo e id de lo tocado, con marcas de tiempo. Si el servidor solo registra contenidos o solo errores, no puedes reconstruir una sesión.

¿Qué no debería ser nunca concedible a un agente?

Cualquier cosa cuya exposición no pudieras deshacer y cuyo uso por un agente no tenga un propósito rutinario. Para nosotros es la nómina. Tu lista puede añadir datos de salud, datos bancarios o secretos del código. La protección es estructural: sin alcance, sin herramienta.

¿Qué es la autorización step-up en MCP?

Ejecutar un agente con alcances estrechos y ampliarlos solo cuando una llamada concreta devuelve 403, mediante una nueva ronda de consentimiento para el alcance extra. Mantiene las concesiones ligadas a tareas y no a una suposición inicial.

Siguiente paso

Abre la pantalla de consentimiento del host de agentes que uses y cuenta los alcances que pide por defecto. Si la respuesta es "todos", eso es lo primero que hay que cambiar. La página MCP de Atrix lista los 49 alcances y qué desbloquea cada uno, y la documentación para desarrolladores muestra los alcances que requiere cada herramienta.