Cloudflare Mueve la Autenticación de Agentes al Ciclo de Vida de la Tarea, No a Cuentas de Servicio

Cloudflare publicó un artículo arquitectónico formal proponiendo el Agent Access Model (AAM), un marco de seguridad y autorización que trata a los agentes de IA como principales de infraestructura de primera clase en lugar de extensiones de la identidad humana. El artículo aborda un problema concreto: las implementaciones multi-agente en producción están exponiendo los límites de todos los patrones de control de acceso construidos para personas.

Los controles existentes fallan a los agentes de cuatro formas específicas. Primero, las credenciales sobreviven a las tareas. Las cuentas de servicio fueron diseñadas para software de larga duración, como trabajos por lotes nocturnos, y conllevan ámbitos amplios, claves de larga duración y ciclos raros de rotación. Aplicadas a un agente de corta duración, esas credenciales sobreviven al trabajo para el cual fueron emitidas y permanecen en memoria, registros y variables de entorno donde pueden ser reproducidas. La solución de Cloudflare: la vida útil de la credencial debe coincidir con la vida útil de la tarea, que para los agentes suele ser de minutos. Segundo, los agentes operan a velocidad de máquina. La detección de anomalías y los controles de pérdida de datos ajustados para la actividad humana reaccionan demasiado lentamente — un agente con una conexión de base de datos y una ruta de red saliente puede leer una tabla y hacer POST a un extremo externo antes de que un control ajustado para humanos termine de muestrear. Tercero, el prompt no es un perímetro. Instrucciones como "no accedas a producción" moldean el comportamiento pero no imponen acceso, y un modelo puede ser manipulado por contenido inyectado en los datos que lee. Cuarto, los agentes componen autoridad a través de saltos de delegación. Cuando un agente invoca una herramienta que invoca otro agente que llama a una API en nombre del usuario humano original, la respuesta a "¿para quién es esto y qué se les permite hacer?" desaparece en algún lugar de la cadena.

La regla central del AAM: no confíes en la ejecución. Autoriza cada acción contra la tarea y su estado acumulado. BeyondCorp eliminó la confianza implícita de la red. AAM elimina la confianza implícita de la ejecución de tareas. La autorización para una acción no se traslada a la siguiente. Cada acción se evalúa contra tres criterios: quién es el agente, qué tarea fue autorizado a realizar, y qué recursos relevantes para la política el gráfico ya ha tocado. Ese estado acumulado solo puede reducir las capacidades restantes del gráfico — un trinquete que se estrecha, nunca se amplía, el conjunto de capacidades conforme avanza la ejecución. Cloudflare compara esto con el Beyond Zero de Google, que de manera similar mueve el límite de confianza de la aplicación a la acción individual.

Cloudflare lanzó infraestructura complementaria. El SDK de Agents ahora incluye una clase MCPClientManager que maneja el flujo completo de OAuth 2.1 — redirigiendo usuarios al inicio de sesión, generando desafíos de código, intercambiando códigos de autorización por tokens de acceso, y espacios de nombres de herramientas en múltiples servidores MCP para evitar colisiones. Las integraciones con Stytch, Auth0 y WorkOS están disponibles para autenticación de servidor MCP, con restricción de ámbito por usuario y páginas de consentimiento vinculadas a rol. Durable Objects, la primitiva de computación con estado que Cloudflare utiliza como ancla de identidad para agentes, pasó al nivel gratuito. Un anuncio separado introdujo agentes firmados — una extensión del programa verified bots que utiliza firmas de mensaje HTTP de Web Bot Auth para autenticar criptográficamente el tráfico de agentes en la capa de red. La primera cohorte incluye ChatGPT agent, Goose de Block, Browserbase y Anchor Browser. El producto Browser Rendering de Cloudflare ahora envía encabezados de Web Bot Auth y recibe una puntuación de bot de 1 bajo Bot Management.

El artículo nombra un problema sin resolver: control de acceso multijugador, donde múltiples humanos con diferentes niveles de permiso contribuyen contexto a una única ejecución de agente. La delegación OAuth existente maneja un salto de forma limpia pero no se compone entre varios humanos o saltos sin diseño de propagación explícita.

La conclusión: la aplicación pertenece en el arnés que media llamadas de herramientas y en la capa de red que media paquetes, no en el conjunto de instrucciones del modelo. El ámbito de credenciales debe ser diseñado para expirar con la tarea, no con la cuenta de servicio.