Más allá del secreto: Los riesgos silenciosos de JWT y la identidad de máquina 🤖

En el panorama digital de 2026, el perímetro no solo se ha disuelto; ha sido reemplazado por una vasta y invisible red de interacciones Máquina a Máquina (M2M). A medida que las organizaciones avanzan hacia “Agentic AI” y microservicios de escala hipergrande, la amenaza de seguridad más significativa ya no involucra a un humano escribiendo una contraseña en un cuadro de inicio de sesión. En cambio, involucra a un agente de IA autónomo o un microservicio que presenta un JSON Web Token (JWT) a otro servicio.

Aunque los JWT se han convertido en la “lingua franca” de la autenticación moderna debido a su estado sin sesión y portabilidad, también se han convertido en un vector silencioso para brechas catastróficas. Hoy en día, la proporción de identidad máquina-humano es de un asombroso 82:1. Por cada usuario humano que navega por tu red, hay 82 entidades automatizadas—contenedores, scripts, dispositivos IoT y agentes de IA—que realizan acciones en su nombre.

Este artículo explora las vulnerabilidades profundas en las implementaciones de JWT y los riesgos sistémicos de las identidades de máquina mal gestionadas en una era donde los agentes de IA pueden pensar, planear y ejecutar.

1. La anatomía de la identidad de máquina moderna

Antes de profundizar en los fallos, debemos entender el cambio. La gestión tradicional de identidades se centraba en interacciones Human-to-Machine (H2M), protegidas por Autenticación Multifactor (MFA) y verificaciones biométricas. Sin embargo, las identidades de máquina no tienen pulgares para biometría ni teléfonos para códigos SMS. Dependen de secretos—claves API, certificados y, más comúnmente, JWT.

El auge de la IA Agentic

En 2026, hemos superado los simples “Chatbots” para llegar a la IA Agentic. Estos son sistemas autónomos que usan Modelos de Lenguaje Grande (LLMs) para razonar sobre tareas. Un agente puede decidir:

• Acceder a una base de datos mediante un microservicio
• Procesar datos financieros usando una API de terceros
• Actualizar un registro en CRM según sus hallazgos

Para hacer esto, el agente debe ser “suplantado” o delegado con autoridad. Esta delegación casi siempre se maneja mediante un JWT. Si ese token se compromete, el “agente” se convierte en una amenaza interna autónoma de alta velocidad.

2. La ilusión del JWT: por qué “sin estado” es una espada de doble filo

El principal atractivo de los JWT es que son sin estado. El servidor no necesita almacenar una sesión en una base de datos; toda la información necesaria para autorizar la solicitud está contenida en el propio token.

La brecha de revocación

La mayor fortaleza del JWT también es su fallo fatal: la revocación insuficiente del token. Debido a que el servidor no verifica una tienda central de sesiones, un JWT es válido hasta que expira.

El riesgo: Si se roba el token de un agente de IA, un atacante puede usarlo libremente hasta que se alcance la reclamación exp (expiración).

La realidad en 2026: En microservicios de alta velocidad, incluso una ventana de 5 minutos es suficiente para que un script automatizado exfiltre toda una base de datos.

Sin un mecanismo robusto de lista blanca o lista negra (que reintroduce el “estado” que los desarrolladores trataban de evitar), no hay un “interruptor de apagado” para una identidad de máquina comprometida.

3. Fallos fatales en la implementación de JWT

Incluso en 2026, los desarrolladores siguen cayendo en trampas criptográficas clásicas. CVEs recientes, como CVE-2025-4692, destacan que incluso bibliotecas “blindadas” pueden estar mal configuradas.

La explotación del algoritmo “None”

El encabezado del JWT contiene un campo alg que indica cómo fue firmado el token (por ejemplo, HS256, RS256). La especificación también permite un algoritmo llamado none.

La explotación: Un atacante cambia el encabezado a {"alg": "none"} y elimina la firma. Si la configuración del backend es incorrecta, acepta el token como “ya verificado.”

Variación moderna: Muchos sistemas en 2026 bloquean el none, pero los atacantes usan bypass de sensibilidad a mayúsculas como nOnE o NoNe para pasar filtros rudimentarios.

Confusión de algoritmos (RS256 vs. HS256)

Este quizás sea el fallo más sofisticado y común.

• RS256 usa un par asimétrico (la clave privada firma, la clave pública verifica)
• HS256 usa un secreto compartido simétrico

En un ataque de Confusión de Algoritmos, un atacante cambia el algoritmo del token de RS256 a HS256. Luego firma el token usando la clave pública del servidor (que a menudo está públicamente disponible). El servidor, al ver HS256, usa su “secreto” (que en realidad es su clave pública) para verificar la firma. La matemática cuadra, y el atacante obtiene acceso no autorizado.

4. Los asesinos silenciosos: claves de cuentas de servicio de larga duración

Mientras que los JWT suelen ser de corta duración (minutos u horas), las claves de cuentas de servicio usadas para solicitar esos JWT suelen ser permanentes. Estas son los “secretos” que nunca duermen.

La persistencia de claves obsoletas

En una arquitectura de microservicios, los desarrolladores a menudo generan un archivo de clave JSON para una cuenta de servicio que permite a una canalización CI/CD desplegar código.

El problema: Estas claves se codifican frecuentemente en variables de entorno, se comprometen accidentalmente en repositorios privados de GitHub o se dejan en registros de compilación.

El peligro: A diferencia de una contraseña de usuario, estas claves no expiran. Una clave generada en 2024 aún podría estar activa en 2026, proporcionando una puerta trasera permanente a la infraestructura.

El agente “sobre-permisivo”

Debido a que es “más fácil” para el desarrollo, las cuentas de servicio a menudo reciben roles de Administrador u Owner. Cuando un IA Agentic usa una cuenta de servicio así, su “radio de explosión” es total. Si el IA es engañado mediante Prompt Injection para llamar a una API específica, lo hace con todo el peso de su cuenta de servicio sobre-permisiva.

5. IA Agentic: la nueva frontera del riesgo JWT

En 2026, el concepto de “Superficie de Identidad” se ha expandido. Los agentes de IA ya no son solo herramientas; son pares en la red.

Explotación de Prompt a Token

Los atacantes han pasado de atacar el código a atacar el razonamiento del agente. Al envenenar los datos que lee un agente (Retrieval-Augmented Generation o RAG), un atacante puede convencer a un agente de que necesita enviar su JWT actual a un “servicio de registro” externo (controlado por el atacante) para “depuración.”

Comunicación entre agentes

Los sistemas multi-agente involucran a agentes hablando entre sí. Si el Agente A (baja seguridad) pasa una solicitud al Agente B (alta seguridad), el Agente B debe verificar que el Agente A está autorizado.

La trampa: Si el Agente B confía en credenciales “en caché” o en ámbitos heredados sin re-validar la intención de la solicitud original, enfrentamos un problema de “Confused Deputy” a velocidad de máquina.

6. Fortaleciendo el perímetro: mejores prácticas para 2026

Asegurar la identidad de máquina requiere alejarse de secretos estáticos hacia una seguridad basada en identidad y efímera.

1. Adoptar tokens efímeros y de corta duración

Deja de usar claves de cuentas de servicio. En su lugar, usa Workload Identity.

Google Cloud/AWS/Azure: Usa federación de identidad de carga de trabajo nativa que permite a tu código intercambiar un token de plataforma de corta duración por un JWT específico de servicio.

Resultado: Incluso si un token es robado, expira en 30 minutos, y no hay una “clave maestra” que robar de un repositorio de GitHub.

2. Implementar SPIFFE/SPIRE

El Marco de Identidad Segura para Producción (SPIFFE) proporciona una forma para que los servicios se identifiquen sin secretos compartidos. Emite SVIDs (Documentos de Identidad Verificables SPIFFE) de corta duración que se rotan automáticamente.

3. Lista blanca estricta de algoritmos

Nunca dejes que el encabezado del JWT dicte tu seguridad.

// MALO: Confiando en el encabezado
jwt.verify(token, secret);

// BUENO: Aplicando la restricción del algoritmo
jwt.verify(token, publicKey, { algorithms: ['RS256'] });

4. Verificaciones continuas de revocación

Para transacciones de alto valor, usa JWT Assertion Grants o un sistema centralizado de Detección y Respuesta a Amenazas de Identidad (ITDR). Esto te permite verificar si un jti (ID de JWT) específico ha sido marcado como sospechoso antes de procesar la solicitud.

7. Análisis comparativo: Identidad máquina vs. humana

Característica	Identidad Humana (H2M)	Identidad de Máquina (M2M/Agentic)
Autenticación	Contraseña, MFA, biometría	Claves, certificados, JWT
Volumen	Bajo (miles)	Extremo (millones)
Velocidad	velocidad humana (segundos/minutos)	velocidad máquina (milisegundos)
Ciclo de vida	Gestionado por HR/IAM	Gestionado por DevOps/Orquestador de IA
Revocación	Fácil (desactivar cuenta)	Difícil (tokens sin estado)
Riesgo	Toma de control de cuenta	Movimiento lateral en infraestructura

Conclusión: La era de “Privilegios en cero” (Zero Standing Privileges)

A medida que avanzamos en la era de la IA Agentic, el antiguo modelo de “Secreto” ha muerto. Ya no podemos confiar en una cadena estática para demostrar quién—o qué—está llamando a una API. Los riesgos de los JWT no son inherentes a la tecnología, sino a nuestra complacencia en su implementación.

En 2026, las organizaciones más seguras son aquellas que tratan cada acción de máquina como un evento único y con tiempo limitado. Al aplicar Zero Standing Privileges (ZSP) y movernos hacia una autenticación efímera basada en identidad, podemos finalmente ir “Más allá del secreto.”

El “interruptor de apagado” para la próxima generación de amenazas de IA no es un cable de alimentación—es la capacidad de revocar una identidad de máquina en milisegundos.