La respuesta corta
Conectar un agente de IA a un servidor MCP no significa que todas las personas que usan el agente deban poder ejecutar todas sus herramientas. El inicio de sesión responde quién llama. La autorización debe responder, en cada petición, qué herramienta puede usar esa identidad, qué acción puede realizar, sobre qué recurso y con qué límites.
AWS publicó el 17 de septiembre de 2026 un patrón de autorización por capas para herramientas MCP que combina identidad, grupos, permisos por herramienta y registro de acciones. La especificación MCP 2026-07-28 también reforzó la autorización y facilita que pasarelas y controles intermedios reconozcan el método y la herramienta solicitados. El principio coincide con la arquitectura zero trust de NIST: proteger recursos concretos y evaluar el acceso sin conceder confianza implícita por estar dentro de una red o haber iniciado sesión una vez.
Autenticación no es autorización
Un token válido demuestra que el proveedor de identidad reconoce al usuario y que el token cumple condiciones técnicas como emisor, audiencia y caducidad. No demuestra que esa persona pueda borrar un registro, cambiar un precio o aprobar un pago. AWS separa explícitamente la validación del token de las puertas que comprueban grupo, ubicación y herramienta; NIST también trata autenticación y autorización como funciones distintas antes de acceder a un recurso empresarial.
Esta diferencia importa porque una petición en lenguaje natural puede terminar en una llamada con efectos reales. El agente puede interpretar «pon al día este expediente» como una lectura, una modificación o varias acciones encadenadas. La política no debe depender de cómo redacte el modelo la intención. Debe aplicarse en la pasarela o en el servidor, antes de que la herramienta alcance los datos o ejecute lógica de negocio.
- Identidad: quién realiza la petición y qué sesión está utilizando.
- Recurso: qué servidor o API debe aceptar ese token.
- Herramienta: qué función concreta intenta invocar el agente.
- Acción: leer, crear, modificar, borrar, enviar o aprobar.
- Alcance: qué cliente, proyecto, territorio o conjunto de datos puede afectar.
Restringe el token al recurso correcto
El primer límite técnico consiste en evitar que un token pensado para un servicio se reutilice en otro. RFC 8707 permite indicar el recurso protegido al solicitar autorización para que el servidor emita un token con la audiencia adecuada. El patrón de AWS aplica esa idea al vincular el token con la aplicación de recurso que representa la pasarela MCP y validar firma, emisor, audiencia y caducidad antes de revisar permisos más detallados.
La documentación de autorización de MCP Apps exige que los servidores protegidos publiquen metadatos de recurso y validen que los tokens fueron emitidos específicamente para ellos. En un inventario empresarial conviene registrar, para cada conexión, el proveedor de identidad, la audiencia esperada, los ámbitos solicitados y la fecha de expiración de secretos o certificados. Si una conexión no puede explicar a qué recurso pertenece su token, todavía no está preparada para producción.
- Un servidor MCP o API identificable como recurso protegido.
- Una audiencia de token concreta, no un token genérico para varios destinos.
- Validación de firma, emisor, audiencia y expiración en el servidor.
- Credenciales separadas entre desarrollo, prueba y producción.
- Rotación y retirada documentadas para secretos, certificados y conexiones.
Crea una matriz de roles, herramientas y acciones
Después de validar el token, la empresa necesita una matriz que traduzca funciones de trabajo en permisos ejecutables. Microsoft recomienda usar grupos para gestionar y minimizar el acceso a aplicaciones; AWS muestra cómo trasladar la pertenencia a grupos del token a políticas de lector, autor o administrador. La idea no depende de Entra ID ni de AWS: el servidor debe recibir una identidad comprobada y resolverla contra una política mantenida fuera del prompt.
Empieza con pocos roles y separa las acciones irreversibles. Un usuario que consulta pedidos no necesita modificar importes. Quien prepara una comunicación puede guardar un borrador sin enviarlo. La persona que aprueba puede no necesitar editar el contenido. Esta separación reduce el impacto de un error del agente y hace visible cuándo un proceso necesita dos responsabilidades distintas.
- Consulta: permite buscar y leer campos autorizados.
- Preparación: crea borradores o propuestas sin efecto externo.
- Edición: modifica campos delimitados y conserva la versión anterior.
- Ejecución: envía, publica, paga o cambia un estado operativo.
- Administración: cambia políticas y conexiones; no debe ser el rol cotidiano.
Autoriza también los parámetros y los datos
Permitir una herramienta completa puede seguir siendo demasiado amplio. Una función de consulta puede aceptar identificadores de distintos clientes; una función de actualización puede cambiar campos inocuos o críticos. El ejemplo de AWS añade comprobaciones basadas en atributos y recomienda evaluar la llamada antes de que llegue a la lógica de negocio. NIST describe políticas que combinan identidad, recurso, acción y atributos del contexto para aplicar mínimo privilegio por petición.
La política debe recibir argumentos estructurados. Conviene validar identificadores, territorio, propietario, tipo de registro y campos modificables sin pedir al modelo que decida si están permitidos. Si la herramienta admite texto libre, el servidor debe transformarlo o rechazarlo antes de actuar. Los permisos de datos se aplican en la capa que controla los datos, incluso cuando el agente ya pasó una comprobación anterior.
- Limitar cada usuario a los clientes, proyectos o centros que gestiona.
- Definir una lista de campos que cada rol puede leer o modificar.
- Bloquear importes, destinatarios o estados fuera de rangos autorizados.
- Exigir aprobación humana para acciones de alto impacto.
- Denegar por defecto cuando falte un atributo o la política no coincida.
Registra permisos concedidos y denegados
Una auditoría útil no es una transcripción completa de la conversación. Debe permitir reconstruir quién llamó, qué herramienta solicitó, qué política se aplicó, qué recurso intentó afectar y cuál fue el resultado. AWS incorpora un registro inmutable para las mutaciones; NIST pide recopilar información sobre recursos y comunicaciones para revisar continuamente la postura de seguridad.
Los rechazos también son evidencia. Varias denegaciones pueden señalar un intento indebido, una política mal diseñada o una interfaz que invita a pedir acciones imposibles. El registro no debe almacenar más datos personales o contenido sensible del necesario. Para depurar, suele bastar con identificadores, versión de la política, campos afectados, decisión y referencia al caso protegido.
- Identidad del usuario y del cliente que originó la llamada.
- Servidor, herramienta, acción y versión de la política.
- Recurso o ámbito de datos afectado, con minimización de contenido.
- Resultado permitido o denegado y motivo de la decisión.
- Aprobación humana y respuesta final de la herramienta cuando proceda.
Prueba primero un flujo de bajo riesgo
El primer piloto no necesita todas las puertas del patrón de referencia. Necesita demostrar que la organización controla el acceso de extremo a extremo. Escoge una herramienta de consulta y otra que prepare un borrador reversible. Define dos roles, crea casos permitidos y denegados y verifica que la acción no llega al sistema de destino cuando falla una regla.
Después añade una única acción de escritura con aprobación. Prueba tokens caducados, audiencia incorrecta, usuario sin grupo, herramienta no permitida, parámetro fuera de ámbito y repetición de la llamada. La salida del piloto debe ser una matriz comprobada, no solo una demostración en la que el agente acertó una vez. No fijes una tasa universal de éxito: el umbral depende de las consecuencias de cada acción.
- Días 1 y 2: inventario de identidades, servidores, herramientas y datos.
- Días 3 y 4: roles mínimos y matriz de acciones permitidas.
- Días 5 y 6: validación de tokens, recursos y parámetros.
- Días 7 y 8: casos negativos y registro de denegaciones.
- Días 9 y 10: una escritura reversible con aprobación y retirada ensayada.
Checklist antes de conectar una herramienta MCP
MCP reduce trabajo de integración, pero no sustituye la política de acceso de la empresa. La conexión debe heredar identidades fiables y aplicar permisos cerca de la herramienta y de los datos. Si el control solo existe en las instrucciones del agente, una variación del prompt o del flujo puede saltárselo.
Antes de habilitar una acción real, tecnología, seguridad y el propietario del proceso deberían revisar juntos esta lista. AUTOINTELLIA puede ayudar a convertir el inventario de herramientas y permisos en un piloto medible, reversible y alineado con las responsabilidades del equipo.
- Cada token está restringido al recurso que debe aceptarlo.
- Los grupos o atributos se traducen a políticas mantenidas fuera del prompt.
- Lectura, escritura, borrado, envío y aprobación tienen permisos separados.
- Los parámetros y el ámbito de datos se validan antes de ejecutar.
- Las acciones sensibles requieren aprobación o un control determinista adicional.
- Los casos permitidos y denegados se prueban y quedan registrados.
- Existe un procedimiento para revocar conexiones, credenciales y permisos.
