Google anunció el 16 de junio de 2026 nuevos claims de metadata de sesión para Sign in with Google: auth_time y amr. A primera vista parece una mejora de identidad genérica. Para quien construye agentes que pueden tocar datos, enviar mensajes, cambiar configuración o aprobar operaciones, es una pieza bastante práctica.

El problema no es solo saber quién inició sesión. El problema es saber cuándo se autenticó realmente y con qué fuerza antes de dejar que un agente ejecute una acción sensible en nombre de esa persona.

Flujo editorial donde una acción de agente pasa por verificación de sesión fresca, MFA y política antes de ejecutarse

Qué cambia

Google explica que los nuevos claims llegan en el ID Token para apps verificadas:

auth_time: marca cuándo el usuario autenticó su sesión con Google, no solo cuándo tu app recibió un token.
amr: indica métodos de autenticación usados, como contraseña, MFA, llave de hardware, llave de software, teléfono o SMS.

Eso permite políticas más finas. Por ejemplo: “este agente puede leer un reporte con sesión normal, pero para borrar datos, cambiar permisos o enviar dinero necesito que el usuario haya autenticado hace poco y con MFA”.

Por qué importa para agentes

Los agentes agrandan el impacto de una sesión vieja. En una app tradicional, una sesión abierta puede permitir clicks manuales. En un producto agentic, una sesión abierta puede permitir que el agente ejecute una secuencia completa: buscar contexto, decidir, llamar tools y dejar cambios listos.

Ahí auth_time y amr ayudan a crear una frontera más defendible:

acciones de bajo riesgo pueden seguir el flujo normal;
acciones de riesgo medio piden sesión fresca;
acciones críticas exigen MFA o llave de seguridad;
todo queda auditable con la fuerza de autenticación usada.

Tablero editorial con políticas de step-up, auditoría y permisos por tipo de acción del agente

La intención de búsqueda

La demanda se infiere por señales actuales, no por volumen inventado: anuncio oficial de Google, documentación OIDC actualizada el 15 de junio, crecimiento de agentes con tools reales y búsquedas probables como Sign in with Google auth_time, amr claim Google, step up authentication agents y OIDC claims for AI agents.

Ese lector ya está en una etapa más madura. No busca “qué es login con Google”. Busca cómo impedir que un agente use una sesión vieja para hacer algo caro.

El error común

El error sería tratar estos claims como permiso absoluto. amr no reemplaza autorización de negocio. auth_time no prueba intención para cada acción. Solo te dan señales mejores para decidir cuándo exigir un paso extra.

Para un sistema con agentes, yo lo implementaría así:

define una matriz de acciones: leer, proponer, editar, ejecutar, publicar;
marca cuáles requieren sesión fresca;
marca cuáles requieren MFA o llave fuerte;
registra el claim usado junto con la acción del agente;
permite revisión humana cuando falte señal suficiente.

También mantendría el principio básico de OIDC: validar correctamente el ID Token, usar sub como identificador estable y no mezclar autenticación con autorización fina.

Mi lectura

Esta no es la noticia más ruidosa de IA de la semana, pero sí es de las que separan demos de productos reales. Si un agente puede actuar, tu app necesita saber cuándo pedir una prueba fresca de presencia humana.

Si todavía estás diseñando el contrato base de tools y permisos, empieza por el curso gratis. Y si ya estás conectando agentes a sistemas internos, esta pieza conversa bien con Google Cloud y el registro de identidad para agentes: una historia controla al agente como actor; esta controla mejor la sesión humana que lo autoriza.

La conclusión práctica: los agentes no necesitan menos autenticación porque “la IA ayuda”; necesitan señales más precisas porque la ayuda puede ejecutar mucho más rápido que un usuario cansado.