Zero Trust para agentes: identidad después de OAuth

Aplicamos confianza cero a los agentes que actúan en nombre de equipos humanos: identidad propia, permisos mínimos y registro verificable de cada acción. La frase suena breve, pero cambia por completo la manera de construir. Un agente ya no es una función que se ejecuta dentro de un perímetro confiable; es un actor más dentro del sistema, con nombre, con credenciales y con una historia de acciones que cualquiera puede revisar.

La base viene de trabajo real: autenticación con OAuth 2.0, SAML, OpenID Connect y JWT, temas ya tratados en Medium en septiembre de 2023, y seguridad de datos con confianza cero, en agosto de 2024. Esos protocolos resolvieron la identidad de las personas y de las aplicaciones que actúan en su nombre. La pregunta nueva es qué ocurre cuando quien actúa es un agente autónomo que encadena herramientas, delega subtareas y toma decisiones entre una petición y la siguiente.

01 · Primero la identidad

Un agente rápido sin identidad clara solo produce errores más rápido. La identidad define qué puede hacer cada agente, con qué permisos y bajo qué registro. Por eso el orden importa: primero la identidad, después la autonomía. Cuando un agente comparte las credenciales de una persona, cada acción suya se confunde con las acciones de esa persona, y la primera pregunta de cualquier auditoría — quién hizo qué — deja de tener respuesta.

La identidad propia se construye con las mismas piezas que ya conocemos de la federación clásica. OAuth 2.0 aporta la delegación con alcance limitado: un token dice qué se puede hacer, dónde y hasta cuándo. OpenID Connect añade la capa de identidad sobre ese flujo. SAML sigue resolviendo la federación empresarial. Y JWT ofrece el formato firmado que transporta las afirmaciones de un servicio a otro. Ninguna de estas piezas es nueva; lo nuevo es aplicarlas a actores que no son personas ni aplicaciones tradicionales, sino agentes que planifican.

02 · Permisos mínimos, siempre

El segundo principio es el privilegio mínimo llevado en serio. Un agente que resume documentos no necesita permiso para enviarlos; un agente que consulta una base de datos no necesita permiso para modificarla. Cada permiso extra es superficie de ataque regalada, y los agentes, que actúan a velocidad de máquina, convierten cualquier exceso de permiso en un exceso de daño potencial a la misma velocidad.

En la práctica, el privilegio mínimo se combina con la caducidad. Las credenciales de un agente deben vivir poco: minutos u horas, no meses. Una credencial robada con caducidad corta es un problema pequeño; una credencial permanente robada es una puerta abierta para siempre. La arquitectura de confianza cero publicada por el NIST en su SP 800-207 lo expresa con claridad: el acceso a cada recurso se concede por sesión y tras verificar la identidad, y ninguna comunicación se considera confiable por el solo hecho de ocurrir dentro de la red.

03 · Cada acción, verificada

Verificar una vez al inicio de la sesión no basta cuando quien actúa encadena decenas de acciones por minuto. La verificación debe acompañar a la acción: cada llamada a una herramienta, cada lectura sensible y cada escritura deberían pasar por el mismo punto de control que decidió la identidad y los permisos. Ese punto de control es el lugar donde la política se convierte en comportamiento: qué agente, qué acción, sobre qué recurso, con qué justificación registrada.

Este diseño tiene un beneficio lateral que aparece en cuanto el sistema crece: el punto de control se convierte en el mejor lugar para observar. Si toda acción verificada pasa por el mismo sitio, ese sitio sabe qué agentes trabajan, qué herramientas usan y qué resultados devuelven. La seguridad y la observabilidad dejan de ser dos sistemas distintos y pasan a ser dos lecturas del mismo registro.

04 · El registro que se puede comprobar

El tercer compromiso es el registro verificable. No alcanza con guardar registros que el propio sistema puede editar: el registro debe permitir que un tercero compruebe qué ocurrió, en qué orden y bajo qué identidad. Cuando un agente actúa en nombre de un equipo humano, la confianza no se declara; se demuestra mostrando la cadena completa de decisiones y acciones.

Ese registro también protege al propio equipo que despliega agentes. Cuando algo sale mal — y algo saldrá mal — la diferencia entre un incidente y una crisis es poder reconstruir la secuencia exacta: qué se pidió, qué se verificó, qué se permitió y qué se ejecutó. Sin registro verificable, cada error de un agente se convierte en una sospecha sobre todo el sistema.

05 · Las cautelas honestas

La confianza cero para agentes no es gratuita, y conviene decirlo. Verificar cada acción añade latencia y coste de cómputo; un punto de control mal diseñado se convierte en cuello de botella o en punto único de fallo. La gestión de identidades también crece: decenas de agentes con credenciales cortas exigen automatización seria para emitir, rotar y revocar sin intervención manual. Y existe un riesgo sutil: un sistema que verifica credenciales con rigor puede seguir permitiendo acciones legítimas en forma pero equivocadas en fondo, porque la identidad comprueba quién actúa, no si la acción tiene sentido.

Por eso la identidad es el principio, no el final. Primero la identidad, después la autonomía, y entre ambas, la verificación continua y el registro que permite comprobarlo todo. Los agentes que construyen los equipos en los próximos años heredarán los permisos que hoy se les concedan; la disciplina de conceder pocos, verificar siempre y registrar todo es la diferencia entre una flota de agentes confiable y una flota de errores muy rápidos.