La mayoría de demos con MCP todavía esquiva la pregunta más incómoda: quién es realmente el usuario detrás de cada tool call y cómo lo demuestras antes de tocar sistemas sensibles. AWS decidió bajar esa discusión a tierra con una guía bastante más útil que una nota de marketing.

En la semana del 2 de junio de 2026, AWS publicó un walkthrough para montar authorization code flow OAuth con Amazon Bedrock AgentCore Gateway y clientes MCP. Lo importante no es que el gateway “soporte auth”. Lo importante es que cada request del asistente puede llegar acompañado por un token válido del usuario real, emitido por el proveedor de identidad de la organización.

Arquitectura editorial con cliente MCP, proveedor de identidad, gateway y tools protegidas por tokens de usuario

La mejora no es cosmética: cambia el contrato de confianza

La guía de AWS explica el patrón con bastante claridad. En este montaje:

el Gateway actúa como resource server MCP;
el usuario se autentica contra un IdP como Cognito, Okta o Entra ID;
el cliente agentic se conecta al endpoint MCP del gateway;
y el gateway solo deja pasar el tráfico cuando el token del usuario es válido.

Eso mueve el modelo de “el agente tiene acceso” a uno mejor: el agente actúa en nombre de una identidad comprobable.

El detalle fino está en el challenge y en la metadata protegida

La parte más interesante del flujo aparece cuando el request llega sin token. AWS documenta que el gateway responde con 401 y un header www-authenticate que apunta al endpoint de Protected Resource Metadata del recurso.

Ese detalle parece pequeño, pero es justo el tipo de cosa que separa una integración seria de un parche.

En vez de inventar una redirección casera o pasar secretos sueltos, el cliente puede descubrir de forma estándar:

dónde autenticarse,
qué recurso protege el gateway,
y cómo completar el flujo antes de volver a llamar tools.

Por qué esto sí importa para builders de verdad

Si tu agente solo resume docs públicas, este tema puede sonar pesado. Pero cambia mucho cuando el agente toca:

datos internos;
tickets con permisos distintos por rol;
catálogos empresariales;
o acciones que no deberían ejecutarse con una identidad genérica compartida.

Ahí el problema ya no es “conectar una tool”. El problema es probar quién pidió la tool y con qué alcance.

Escena editorial con challenge OAuth, metadata protegida y una llamada MCP que solo avanza tras validar identidad

La señal de fondo es otra: MCP está dejando la adolescencia

Leído junto con la expansión más reciente de AgentCore Gateway, el mensaje de AWS es consistente. Primero amplían MCP con dynamic listing, sesiones stateful y delegated auth. Luego publican una guía específica para el tramo más sensible: la autenticación de entrada.

Eso me parece una buena secuencia. Significa que AWS ya no está vendiendo solo “más tools para agentes”. Está intentando resolver la parte que normalmente mata la adopción en empresas: seguridad, identidad y gobernanza.

Tres errores que esta guía ayuda a evitar

usar una identidad técnica compartida para todo;
asumir que el agente puede descubrir tools sin demostrar quién las pide;
dejar OAuth como problema de “después” cuando el sistema ya toca herramientas sensibles.

Por qué esta historia tiene buena intención de búsqueda

Aquí la demanda es pequeña pero muy valiosa:

agentcore gateway oauth
mcp oauth code flow
aws mcp authentication
protected resource metadata mcp

Es tráfico de equipos que ya están implementando, no de curiosidad general.

Si te interesa la capa más amplia de catálogo, prompts y recursos, esta nota conversa muy bien con nuestra cobertura sobre el MCP extendido en AgentCore Gateway. Aquella explica cómo AWS ordena muchas capacidades detrás de una entrada común. Esta pone el foco en la parte que suele romper el rollout: cómo hacer que el request del agente lleve identidad verificable y no solo entusiasmo. Y si todavía estás montando la base antes de abrir tools reales, arranca por el curso gratis.

Mi lectura práctica es simple: si tu MCP sigue funcionando como si todos los requests fueran anónimos o equivalentes, ya vas tarde. AWS no resolvió toda la seguridad de agentes, pero sí dejó una guía bastante concreta para dejar atrás ese nivel de inmadurez.