Un sistema MCP-first necesita una arquitectura de seguridad precisa. No todos los clientes pueden ver todas las herramientas. No todos los agentes pueden invocar todas las herramientas. No todas las acciones pueden ejecutarse de forma autónoma. No toda la información puede llegar al contexto de la IA.
Para ello es necesario separar claramente los distintos tipos de identidad y definir para cada uno el mecanismo de autenticación adecuado.
Las cinco identidades
Human User
Un usuario real del sistema, con una identidad personal y permisos vinculados a su rol. Tipos habituales: administrador, empleado, cliente, director de proyecto, agente de soporte, director general.
El Human User es la identidad base. Todos los contextos delegados hacen referencia en última instancia a él.
MCP Client
La aplicación conectada al servidor MCP. El MCP Client no es un usuario, sino un actor técnico con su propio nivel de confianza.
Ejemplos: Claude Desktop, app de IA interna, app móvil propia, worker de agente propio, cliente de integración externo.
El cliente solo puede ver las herramientas que corresponden a su nivel de confianza y a los scopes configurados.
Agent Identity
El agente o flujo de trabajo concreto que actúa. Un agente no es idéntico al cliente que lo ejecuta, tiene su propia identidad descrita con capacidades restringidas.
Ejemplos: Sales Assistant, Payroll Assistant, Support Agent, DevOps Agent, Reporting Agent, Personal Assistant.
Delegated User Context
El Delegated User Context garantiza que un agente pueda hacer exactamente lo que el usuario en cuyo nombre actúa tiene permitido. El director general puede ver datos salariales, aun así, un agente Sales Assistant no debe recibir esos datos en su contexto.
Service Identity
Para procesos backend a backend sin contexto de usuario directo. Las Service Identities son actores técnicos con scopes estrechos y fijos.
Ejemplos: Import Worker, Scheduled Job, Sync Worker, Monitoring Agent, Billing Worker.
Autenticación para personas
Los usuarios humanos se autentican mediante procedimientos establecidos. La elección del procedimiento depende del requisito de seguridad y el contexto:
- Correo electrónico + contraseña, acceso básico, siempre combinado con 2FA
- Passkeys, alternativa resistente al phishing a las contraseñas, preferida
- TOTP / 2FA, segundo factor para todas las áreas sensibles
- SSO, para entornos empresariales con gestión centralizada de identidades
- OAuth / OpenID Connect, para logins de terceros y accesos delegados
Autenticación para clientes MCP
Los clientes MCP se autentican mediante OAuth 2.1 con Authorization Code Flow y PKCE.
Esto previene ataques de inyección de código y es adecuado para clientes públicos
(sin Client-Secret seguro).
Requisitos adicionales:
- Tokens de acceso de corta duración, minimiza el daño potencial ante filtraciones de tokens
- Rotación de Refresh Token, cada canje de un Refresh Token genera uno nuevo; el anterior queda inmediatamente inválido
- Lista de clientes permitidos, para sistemas sensibles solo se admiten clientes registrados explícitamente; el registro dinámico de clientes está restringido o desactivado
- Validación de Redirect URI, solo se aceptan URIs registradas previamente; las redirecciones abiertas son un vector de ataque frecuente
- Token Binding, donde sea técnicamente posible, el token se vincula al cliente
Un cliente MCP solo ve en el momento del descubrimiento las herramientas que corresponden a sus scopes, no todas las herramientas con rechazo posterior en la invocación.
-
contacts:readLeer y buscar contactos -
projects:readLeer proyectos -
emails:draftCrear borradores de correo electrónico -
calendar:createCrear citas -
reminders:write
Autenticación para servicios internos
La comunicación backend a backend sigue requisitos distintos a los de la autenticación de usuarios o clientes. Aquí se emplean mecanismos técnicos sin paso de autenticación interactivo:
mTLS, autenticación TLS mutua; ambas partes se identifican con certificados- Tokens de servicio firmados, tokens de corta duración, firmados criptográficamente, con scopes estrechamente definidos; sin secretos compartidos de larga duración
- Secret Manager, las credenciales, certificados y claves nunca se almacenan en archivos de configuración, sino que se gestionan y rotan a través de un Secret Manager central
- Zonas de red privadas, los servicios internos se comunican en segmentos de red aislados; sin accesibilidad directa desde la red pública
- Lista de IP permitidas, en sistemas críticos, el acceso se restringe adicionalmente a rangos de IP conocidos
- Rotación de tokens, los tokens de servicio también caducan rápidamente y se renuevan periódicamente