El autor, profesional de seguridad empresarial, analiza el riesgo de conceder a los agentes de inteligencia artificial acceso a recursos sensibles como calendarios o correo electrónico. Estos agentes, no deterministas, manipulan credenciales que a menudo quedan almacenadas en disco y pueden filtrarse a repositorios git o servicios externos, exponiendo datos corporativos críticos.
La mayoría de los proveedores de identidad actuales no admiten mecanismos robustos como certificados respaldados por hardware o hipervisor para vincular los tokens a una instancia concreta, por lo que la práctica habitual es recurrir al flujo de device code, en el que un usuario humano se autentica y el token acaba dentro del entorno del agente sin que el proveedor pueda verificar la postura de seguridad del equipo.
Ante estas limitaciones, el texto propone un modelo de intermediación: un broker central obtiene los tokens reales y emite un JWT sustituto firmado con clave propia, que contiene el token original cifrado. El agente utiliza ese JWT falso para hacer llamadas a través de un proxy, que verifica la firma, descifra el token real y lo reenvía al servicio remoto. El entorno del agente nunca contiene una credencial válida y no hace falta almacenar estado persistente.
Para reforzar el esquema, se sugiere exigir al agente un certificado de cliente (por ejemplo, emitido mediante SPIFFE) en la solicitud al broker y emparejarlo con mTLS en el proxy. Si la clave privada está respaldada por hardware o hipervisor, el token queda vinculado a una instancia concreta, reduciendo aún más la superficie de ataque. La idea coincide con un enfoque publicado por fly.io tres años antes, según reconoce el propio autor.