MCP y OAuth2: ¿Quién autorizó la acción del agente en su servidor MCP?

Por qué el acceso a herramientas complica la identidad

El Protocolo de Contexto de Modelo (MCP) es ahora un componente estándar para la IA agente. Permite a un modelo encontrar y utilizar herramientas, recursos y servicios externos de una sola manera. No es necesario establecer una integración personalizada entre un LLM y cada API con la que interactúa; la aplicación se conecta a un servidor MCP y descubre qué ofrece ese servidor. Buscar en una base de datos, abrir un problema en GitHub, consultar Salesforce, enviar un correo electrónico o extraer registros de un sistema empresarial se reducen todos a la misma operación: una llamada a una herramienta.

Una vez que una IA puede actuar y no solo responder, la identidad y la autorización se complican rápidamente. ¿Quién es la IA y quién es el humano detrás de ella? ¿Quién autorizó la acción y qué puede hacer exactamente la IA? ¿Para qué recurso estaba destinada la autorización? ¿Puede la IA transferir esa autoridad a otro servicio? Y la pregunta más importante: ¿puede OAuth2, un protocolo basado principalmente en el acceso de software a recursos protegidos, representar adecuadamente a un agente autónomo que actúa en nombre de una persona?

La respuesta es complicada. La expresión “en nombre de” apunta hacia el protocolo de intercambio de tokens de OAuth2. La especificación actual de MCP no lo menciona, aunque es fácil ver dónde podría encajar, y eso no resolvería las otras deficiencias mencionadas.

Cómo funciona MCP en la práctica

MCP define un protocolo estándar entre un cliente de IA y un servidor MCP. Una representación simplificada se ve así.

La aplicación de IA es el cliente MCP, y el servidor MCP le expone sus capacidades. El modelo puede descubrir esas capacidades y decidir cuándo utilizarlas. El cambio notable es que el LLM ya no se limita a generar texto; participa en un protocolo.

Imagínese un asistente conectado a un servidor MCP para un sistema de seguimiento de problemas empresariales. Primero, el cliente pregunta al servidor qué herramientas dispone.

{
  "method": "tools/list",
  "params": {}
}

El servidor responde con su lista de herramientas.

{
  "tools": [
    {
      "name": "search_issues",
      "description": "Search project issues",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": {
            "type": "string"
          }
        }
      }
    },
    {
      "name": "create_issue",
      "description": "Create a new project issue",
      "inputSchema": {
        "type": "object",
        "properties": {
          "title": {
            "type": "string"
          },
          "description": {
            "type": "string"
          }
        }
      }
    }
  ]
}

Ahora el modelo sabe que dispone de dos capacidades. Supongamos que el usuario le pide que encuentre los errores de autenticación sin solucionar y cree un informe resumiendo el más importante. El agente podría comenzar con una búsqueda.

{
  "method": "tools/call",
  "params": {
    "name": "search_issues",
    "arguments": {
      "query": "authentication bugs status:open"
    }
  }
}

El servidor devuelve problemas de coincidencia.

{
  "content": [
    {
      "type": "text",
      "text": "Found 17 open authentication issues."
    }
  ]
}

El modelo lee los resultados, elige el que es más importante y realiza una segunda solicitud.

{
  "method": "tools/call",
  "params": {
    "name": "create_issue",
    "arguments": {
      "title": "Critical authentication issue",
      "description": "Summary of the highest-priority authentication defect..."
    }
  }
}

El servidor confirma la creación.

{
  "content": [
    {
      "type": "text",
      "text": "Issue AUTH-4821 created successfully."
    }
  ]
}

Aquí el problema de seguridad se vuelve evidente. El agente ha pasado de leer información a realizar una acción visible fuera del sistema.

MCP no resuelve el problema de la identidad

Un concepto erróneo común es pensar que MCP soluciona el problema de la identidad. No lo hace. MCP define cómo interactúan los clientes y los servidores, mientras que la autenticación y la autorización son cuestiones separadas.

En los transportes basados en HTTP, la sección de autorización de la especificación actual (la revisión del 2026-07-28) se basa en OAuth 2.1. La sección lleva por título “autorización”, probablemente porque ese es el enfoque principal de OAuth2, aunque también abarca mecanismos de autenticación. Los servidores MCP funcionan como recursos protegidos por OAuth2 y los clientes MCP actúan como clientes OAuth2. La especificación también incluye Metadatos de Recursos Protegidos, Metadatos de Servidores de Autorización, Indicadores de Recursos, así como procesos de registro y descubrimiento de clientes. Reúne estas especificaciones en un solo documento:

• el borrador de OAuth 2.1 del IETF (draft-ietf-oauth-v2-1-13)
• Uso de tokens portadores en OAuth 2.0 (RFC 6750)
• Metadatos del servidor de autorización en OAuth 2.0 (RFC 8414)
• Registro dinámico de clientes en OAuth 2.0 (RFC 7591)
• Indicadores de recursos para OAuth 2.0 (RFC 8707)
• Metadatos de recursos protegidos en OAuth 2.0 (RFC 9728)
• Identificación del emisor del servidor de autorización (RFC 9207)
• Documentos de metadatos de ID de cliente en OAuth (un borrador del IETF)
• OpenID Connect Discovery 1.0 y OpenID Connect Dynamic Client Registration 1.0

El protocolo sigue endureciéndose. En la revisión de julio de 2026, los clientes deben verificar el parámetro iss para evitar ataques de confusión con servidores de autorización; las credenciales del cliente están vinculadas al emisor que las creó, y el registro dinámico de clientes está siendo reemplazado por documentos de metadatos de ID de cliente. Aún queda por responder si OAuth2 es suficiente para los agentes.

OAuth precede a los agentes

OAuth 2.0 se estandarizó en 2012 para responder a una pregunta bastante simple: ¿cómo puede un cliente obtener acceso limitado a un recurso protegido sin conocer la contraseña del propietario del recurso?

El modelo funcionó muy bien y se convirtió en la base para el acceso delegado a APIs en toda la red. Sin embargo, la IA autónoma trae consigo un tipo diferente de cliente. Antes, un cliente OAuth2 se refería a una aplicación. Un agente puede ser autónomo, de ejecución prolongada y con múltiples pasos, capaz de seleccionar herramientas dinámicamente, llamar a varias APIs, delegar tareas, actuar en nombre de una persona y tomar decisiones que esa persona nunca había especificado. Eso representa un problema de autorización muy distinto.

No se trata de que OAuth sea inseguro

Nadie debería exagerar las críticas. RFC 6749 sí incluía consideraciones de seguridad, y desde entonces OAuth2 ha desarrollado una arquitectura de seguridad bastante sólida. El punto es que OAuth2 fue diseñado deliberadamente como un marco, no como un protocolo prescriptivo completo para todas las implementaciones modernas. Los implementadores tuvieron la libertad de tomar muchas decisiones en materia de seguridad, y con el tiempo la industria se dio cuenta de que algunas combinaciones de esas decisiones eran peligrosas. Esa es la razón de las adiciones posteriores: autenticación y descubrimiento de clientes, metadatos de recursos protegidos e indicadores de recursos, TLS mutuo, DPoP y otros tokens con restricciones para el remitente, vinculación de tokens, PKCE y orientaciones sobre actualizaciones. La acumulación de mejoras fue tan significativa que el IETF emitió RFC 9700, un documento de Mejores Prácticas Actuales para la seguridad de OAuth 2.0, que se basa en RFCs 6749, 6750 y 6819 y elimina los modos de operación menos seguros.

Por lo tanto, OAuth2 no falló. Evolucionó. Sin embargo, esa evolución es en sí misma una señal del problema subyacente: la abstracción original necesitó repetidamente mecanismos adicionales a medida que los entornos de seguridad se volvían más complejos.

¿Qué representa el token?

Volvamos al ejemplo anterior. El usuario solicita que se cree un elemento, la IA decide llamar a una herramienta MCP, y el servidor recibe un token de acceso OAuth2. ¿Qué representa ese token? Podría ser el usuario humano, la aplicación IA, el cliente MCP, el servidor MCP actuando en nombre del humano, o alguna combinación de aplicación y usuario. Estos no son equivalentes, y bajo flujos OAuth2 ligeramente diferentes pero perfectamente legítimos, cualquiera de ellos puede ocurrir.

Es aún más importante cuando el servidor MCP llama a otra API.

Varios dominios de autorización ahora se superponen. Antes de actuar, el servidor podría tener que determinar la identidad del usuario, el agente que realiza la tarea, el cliente MCP que inició la solicitud, qué ha aprobado el usuario, las herramientas que puede utilizar el agente, las APIs posteriores a su alcance, y si esta acción está dentro de los límites de la autorización original. Eso es mucho más que la simple estructura que se muestra a continuación.

El delegado confundido

Uno de los riesgos de seguridad más graves de MCP es el suplantador confundido. Supongamos que el servidor MCP recibe un token destinado a él mismo y luego llama a una API descendente. Una implementación descuidada podría simplemente reenviar ese token, y ese es el comportamiento que las directrices de seguridad actuales de MCP están diseñadas para evitar. Según la especificación, un servidor debe verificar que se le haya emitido un token y nunca debe entregar el token del cliente a otro servicio. Cuando necesite una API ascendente, debe obtener un token diferente emitido para ese recurso descendente. El principio es este:

y no este:

El primer modelo crea límites de confianza separados. Agregar una pasarela MCP complica aún más las cosas, pero la regla sigue siendo la misma: nunca pasar tokens hacia abajo.

El lugar de OAuth2 en MCP

A un nivel simplificado, el flujo se ve así.

El servidor MCP es el recurso protegido. El cliente obtiene un token de acceso, lo presenta con cada operación MCP y el servidor lo valida. Eso es el OAuth2 convencional. La especificación lo refuerza con indicadores de recurso (el parámetro resource), de modo que la solicitud de autorización indica el servidor MCP específico para el cual está destinado el token. Eso es algo positivo, pero no resuelve mágicamente todos los problemas de autorización de agentes.

Qué agrega OIDC

OAuth2 responde a qué puede acceder un cliente según su autorización. OIDC añade una capa de identidad que indica quién es el sujeto autenticado, lo cual es útil para los agentes. Un proveedor de identidad puede autenticar a un usuario, por ejemplo:

Alice

OIDC puede proporcionar afirmaciones de identidad sobre ese usuario, OAuth2 puede ofrecer autorización delegada, y el cliente MCP puede obtener entonces un token de acceso que representa una autorización concedida al cliente para un recurso específico. Conceptualmente se ve así.

No obstante, sigue existiendo una brecha conceptual. Autenticar al usuario no autoriza cada una de las decisiones del agente. Un usuario podría permitir que una aplicación lea su correo electrónico, lo cual no es lo mismo que permitir que un agente de IA envíe cualquier correo que decida enviar por su cuenta. Eso es un problema de políticas.

Los problemas con los alcances

A menudo los alcances se presentan como la solución. Un permiso de tipo calendar-read se ve así.

scope=calendar.read

y una beca de envío como esta.

scope=email.send

Pero los sistemas agentes revelan cuán generales son los alcances. Tomemos, por ejemplo, el permiso simple para enviar correos electrónicos.

email.send

¿Permite que la IA envíe correos a cualquier persona? ¿Enviar mensajes ilimitados? ¿Enviar documentos financieros o datos corporativos confidenciales? ¿Suplantar al usuario? ¿Enviar sin solicitar confirmación? El alcance no lo indica. La decisión real podría requerir más contexto, en esta línea.

Subject
Agent
Tool
Action
Resource
Target
Context
Risk
Time
Policy

Eso se parece menos a los alcances tradicionales de OAuth2 y más a una autorización basada en políticas. En términos antiguos, es la diferencia entre decisiones de autorización a gran escala y a escala fina.

El agente como nuevo sujeto de seguridad

Este podría ser el cambio conceptual más importante. Las aplicaciones tradicionales suelen tener una identidad bastante estable. Un agente de IA puede ser montado dinámicamente, a partir de varias partes al mismo tiempo.

Entonces, ¿quién es el sujeto de seguridad? Posiblemente todos ellos. El sistema de autorización podría necesitar expresar algo más que “Alice puede acceder a Salesforce”. Podría ser necesario indicar que Alice autorizó a este agente en particular, que funciona a través de esta aplicación en particular, a realizar ciertas clases de acciones contra este tenant de Salesforce, sujeto a ciertas políticas. Esa es una afirmación mucho más completa.

También es similar a cualquier sistema que almacena en caché muchos tokens de acceso provenientes de un gran grupo de usuarios, tanto humanos como de aplicaciones, para acceder a numerosos recursos. La pregunta es si se puede confiar en que el agente proteja esos tokens y elija el correcto cuando sea necesario actuar en nombre de un usuario determinado.

¿Está roto OAuth2 para los agentes?

Esa conclusión no está justificada. Una afirmación más precisa es que OAuth2 resuelve parte del problema de autorización de los agentes, pero el problema completo es más amplio que OAuth2. Es muy eficaz para el acceso delegado, que establece de la siguiente manera.

Un ecosistema de agentes necesita más respuestas que eso: qué agente actúa en nombre de qué persona, con qué herramienta, con qué finalidad, en qué recurso, bajo qué autoridad y política, por cuánto tiempo, dentro de qué límites de transacción y con qué aprobación humana. Tener un token de acceso no elimina ninguna de esas preguntas.

Nuevas propuestas

Están surgiendo varias direcciones posibles.

GNAP

El candidato más evidente basado en estándares es GNAP, el Protocolo de Negociación y Autorización de Subvenciones. Fue creado para superar las limitaciones de la autorización y delegación al estilo OAuth2, ofreciendo una forma de delegar la autorización a software y transferirle los resultados correspondientes, abarcando tanto el acceso a APIs como la información sobre los sujetos. Su diseño contempla una delegación más avanzada que la que ofrece OAuth2. GNAP es actualmente un Estándar Propuesto por el IETF según la RFC 9635, y la RFC 9767 trata sobre las conexiones entre servidores de recursos. Aunque responde a la pregunta de si alguien ha propuesto algo más allá de OAuth2, no constituye un reemplazo específico para MCP y OAuth2 sigue siendo el dominante.

Protocolos de seguridad específicos para MCP

Los investigadores también proponen protocolos basados en MCP y en la IA agente. El Secure Model Context Protocol (SMCP) ampliaría MCP con gestión unificada de identidades, autenticación mutua, propagación de contextos de seguridad, aplicación de políticas detalladas y registro de auditorías. Otra propuesta, MCPSec, sugiere la certificación de capacidades y la autenticación de mensajes para contrarrestar amenazas específicas de MCP. Estos esfuerzos reconocen que la autenticación no es el único problema: un ecosistema de agentes podría necesitar determinar no solo quién es una persona, sino también qué capacidades afirma tener y si esas afirmaciones pueden verificarse criptográficamente. Esto conduce hacia una seguridad basada en capacidades.

Autorización basada en capacidades

Esto podría resultar más importante que reemplazar a OAuth. En lugar de otorgarle a un agente el alcance email.send, el sistema podría entregarle una capacidad definida de forma más restrictiva.

Capability:
    Principal: Agent-472
    Subject: Alice
    Action: send-email
    Resource: alice@example.com
    Destination: bob@example.com
    Maximum: 1 message
    Expiration: 10 minutes

El agente posee un artefacto de autorización verificable criptográficamente y no puede reutilizar esa autoridad para nada más. Eso está mucho más cerca de lo que necesitan los sistemas agentes, ya que el agente no solo está autenticado, sino que también se le ha otorgado una autoridad específica.

OAuth2 más algo más

Probablemente la arquitectura final no declarará que OAuth2 está obsoleto. Se parecerá más a esto.

OAuth2 sigue emitiendo tokens de acceso, OIDC establece la identidad humana, MCP proporciona el protocolo de herramientas, un sistema de capacidades o políticas limita lo que el agente puede hacer realmente, y un punto de aplicación de políticas realiza la llamada final.

La pieza que falta: la intención

La intención es algo para lo cual la autorización tradicional no estaba diseñada para manejarlo. Supongamos que un usuario pide a un agente que encuentre un vuelo a Manila por menos de 1,000 dólares y lo reserve. En el proceso, el agente podría buscar aerolíneas, comparar tarifas, consultar el calendario, ver los detalles del pasaporte, reservar un asiento y realizar el pago. El usuario nunca aprobó cada una de esas solicitudes API por separado; en su lugar, aprobó una intención, lo cual difiere significativamente de la autorización web convencional, ya que el agente convierte una instrucción general en una cadena de acciones automáticas. El sistema de seguridad podría necesitar analizar lo siguiente.

Por esta razón, la afirmación de que OAuth2 no funciona para los agentes tiene algo de verdad, siempre y cuando se entienda correctamente la crítica. OAuth2 puede autorizar cada llamada, pero no proporciona de forma inherente una forma completa de determinar si esas llamadas se ajustan a la intención de la persona y a la autoridad delegada al agente.

MCP como caso de prueba

MCP está obligando a la comunidad de identidad y seguridad a enfrentar un problema que se ha ido acumulando durante años. OAuth2 fue diseñado teniendo en cuenta esta cadena de procesos.

La IA agente introduce algo diferente.

La cadena se vuelve dinámica: los participantes pueden cambiar, el agente toma decisiones, las herramientas se descubren en tiempo real, y el servicio final puede que ni siquiera conozca al usuario original. Sin embargo, el sistema sigue teniendo que responder quién autorizó la acción, lo cual es una pregunta mucho más difícil.

OAuth2 no desaparecerá

Es tentador decir que OAuth2 existe desde antes que la IA y, por lo tanto, no puede funcionar con ella. Eso es demasiado simplista. OAuth2 ha sobrevivido a enormes cambios en Internet porque es un marco de delegación realmente útil, y la especificación de MCP se basa explícitamente en OAuth 2.1 sin abandonarlo. El futuro más probable es uno evolutivo:

• OAuth2 como base
• OIDC para la identidad
• MCP para la interacción estándar con herramientas
• DPoP y mecanismos relacionados para un vínculo más fuerte entre tokens
• Indicadores de recursos para asociar tokens con los recursos a los que están destinados
• Sistemas de capacidades para limitar lo que pueden hacer los agentes
• Motores de políticas para evaluar el contexto
• Protocolos más recientes como GNAP para semánticas de delegación más avanzadas

El cambio en una idea

La IA agente no plantea principalmente un nuevo problema de autenticación. El nuevo problema es la autorización y la delegación. La autenticación pregunta quién eres, mientras que OAuth2 pregunta a qué puedes acceder. La autorización en entornos de agentes debe determinar qué autoridad se ha delegado a este agente, en nombre de quién, contra qué recursos y bajo qué restricciones, y si esa acción específica está dentro de esos límites. Es una pregunta más compleja, y probablemente requiera un modelo de seguridad más avanzado.

El futuro probablemente no sea OAuth2 frente a algo nuevo. Lo más probable es que sea una combinación de OAuth2, OIDC, MCP, capacidades, políticas, un enlace criptográfico más sólido y una delegación consciente del agente. MCP simplemente hace que los límites de la arquitectura de identidad existente sean imposibles de ignorar, lo cual podría convertirse en una de sus contribuciones más importantes al ecosistema de IA.