jueves, agosto 06, 2026

Cómo desplegar Zero Trust para Agentes IA en Cloudflare (y 4)

Continuando lo visto en la primera parte de esta serie, en la segunda, y en la tercera parte de este artículo terminamos en este apartado con recomendaciones de cómo configurar modelos de Zero Trust para Agentes IA utilizando las tecnologías de Cloudflare.

Figura 33: Cómo desplegar Zero Trust para Agentes IA en Cloudflare (y 4)

Hay que decir que este artículo fue escrito antes de la Agents Week de Cloudflare, que es justo esta en la que estamos, y donde la compañía está publicando muchas actualizaciones de plataforma que deberán ser tenidas en cuenta para la aplicación de Zero Trust en Agentes IA, y que quedan al final de este artículo de hoy.

4.7.- Gobernanza.

El principio.

Los controles anteriores son eficaces sólo si alguien decide cómo se configuran, quién puede modificarlos y cómo se mantienen coherentes con el tiempo. Esa es la función de la gobernanza, que CISA eleva a capacidad trasversal de toda arquitectura Zero Trust: la definición y la aplicación de las políticas, procedimientos y procesos de seguridad, dentro de cada pilar y entre ellos, para gestionar el riesgo de la organización en apoyo de los principios Zero Trust.


Sin gobernanza, los controles se degradan. Una política de salida que cualquiera puede reescribir no protege, un secreto que nunca rota acaba filtrándose, un dato que nunca se borra se acumula como riesgo.

En un Agente IA, la gobernanza abarca cuatro frentes: quién puede cambiar las políticas que rige el agente, cómo se gestionan y rotan sus credenciales, cuánto tiempo se conservan sus datos y cómo se controla la procedencia de los componentes que el agente carga.

Dónde se sitúa hoy el ecosistema de Cloudflare.

El despliegue de referencia no sólo ofrece mecanismos de gobernanza, sino que también incluye una lista de comprobación de modelo de amenazas que es, en sí misma, una guía de gobernanza. Sus puntos articulan esta dimensión.

Sobre quién puede cambiar qué, la lista lo advierte expresamente: conviene limitar quién puede editar secretos y políticas, porque las páginas de secretos y de políticas de salida son poderosas (quien las alcanza puede reescribir el tráfico de toda la sesión). Es el principio de separación de privilegios aplicado al plano de control del Agente IA.

Figura 35: Securing Access Policies

Sobre las credenciales, la misma lista recomienda rotar la calve de la API según la cadencia que exija el equipo de seguridad, una operación que se realiza sin interrupción de servicio. Y la arquitectura ya favorece la buena higiene: los secretos se guardan en el almacén de claves cifrados, no en el código y se inyectan en las peticiones sin que el agente los vea, como se trató en la segmentación.

Sobre la retención de datos, hay un punto que la gobernanza debe asumir explícitamente: el almacenamiento de objetos no expira las copias de recuperación por sí solo, de modo que definir y aplicar una política de retención (mediante reglas de ciclo de vida) es responsabilidad de quien despliega. Lo que no se gobierna, se acumula.

Sobre la procedencia de los componentes, el modelo de seguridad del sandbox deja claro el reparto: la plataforma protege frente a ciertas amenazas, pero la implementación, la validación, la limitación de tasa y la seguridad a nivel de aplicación corresponde a quien despliega. La gobernanza es, en buena medida, asumir conscientemente esa segunda lista en lugar de suponer que la plataforma la cubre.

Hay un frente de gobernanza que hay que atender y que a menudo se pasa por alto: las capacidades que se añaden al Agente IA (servidores MCP, skills) son superficies que también deben gobernarse. Para los servidores MCP, el ecosistema de Cloudflare One permite curar qué herramientas quedan expuestas y someter el acceso a la identidad corporativa con registro de llamadas.

Las skills que un agente carga son, por su parte, contenido que entra en su contexto y por la premisa fundamental (el modelo no distingue una instrucción legitima de una incrustada) una skill manipulada o de procedencia no verificada es un vector de inyección y si incluye código, de cadena de suministro. Gobernar las skills (verificar su origen, cargar sólo las necesarias, no tratar su texto como instrucción privilegiada) es parte de la gobernanza del agente, no un asunto menor.

Continuando la maduración Zero Trust.

El primer avance es convertir la lista de comprobación en política viva: no una verificación única en el despliegue, sino una revisión periódica de quién tiene acceso y políticas, con qué cadencia se rotan las credenciales y si las reglas de retención se están aplicando. La gobernanza madura es continua, no un acto fundacional que luego se olvida.

El segundo avance es centralizar el control donde la plataforma lo permita, de modo que las decisiones de seguridad no dependan de la configuración individual de cada agente sino de una política común que no pueda relajarse localmente. Es la traducción, al plano de la gobernanza, del principio de que la seguridad debe estar en la arquitectura por defecto y no depender de que cada la configure bien.

Figura 37: LLM06-2025 Agencia Excesiva

El tercer avance se extender la gobernanza a toda la cadena de procedencia: tratar los servidores MCP y las skills con el mismo rigor que cualquier dependencia crítica (inventario de lo que el Agente IA puede cargar, verificación del origen, principio de mínimo componente cargado), de modo que la superficie que se añade al agente esté tan gobernada como la que viene de fábrica. En un ecosistema donde las capacidades del agente se amplían instalando componentes de terceros, esta es la frontera de gobernanza que distingue un despliegue maduro.

5.- Conclusión.

Este documento es un marco de razonamiento Zero Trust, independiente y no afiliado, basado exclusivamente en la documentación oficial pública de Cloudflare y Anthropic y en marcos de referencia conocidos. En ella se destaca, en el momento de escribir estas líneas, que se trata de un software en fase temprana, por lo que sus interfaces, sus parámetros por defecto y sus capacidades pueden cambiar entre versiones.

Este documento ha partido de una premisa: el modelo de lenguaje que da inteligencia a un Agente IA no distingue de forma fiable una instrucción legítima de una orden maliciosa incrustada en los datos que procesa. De esa premisa inicial, arranca todo lo demás. Si el agente no puede ser el guardián de propia seguridad, entonces los controles deben estar fuera de él, en la arquitectura que le rodea. Zero Trust ofrece el marco para construir esa arquitectura.

El recorrido por las siete dimensiones de control muestra un hecho que conviene enunciar con claridad: el despliegue de Agentes IA gestionados sobre Cloudflare dispone hoy, de fábrica, de la mayoría de las piezas que una arquitectura Zero Trust necesita. 

La identidad puede afirmarse con certificados y tokens de servicio; el acceso puede restringirse a lo mínimo mediante curaduría de herramientas, políticas de permisos y herramientas personalizadas deterministas; la segmentación de salida se aplica antes de que el agente actúe; la entrada y la salida pueden validarse en puntos bien definidos; la actividad deja rastro observable; la contención y la recuperación están diseñadas con cuidado y una lista de gobernanza que articula quién controla qué. No es un entorno al que haya que añadirle seguridad desde cero, sino que uno que ya proporciona los cimientos.

Figura 38: The Agent Access Model en Cloudflare

Para alcanzar un estadio óptimo solo hay que conectar y endurecer deliberadamente lo que ya existe. La adopción de la denegación por defecto frente a la confianza implícita, preferir credenciales efímeras y atribuibles a las que sean únicas y longevas. Vigilar los canales que se escapan a las políticas, convertir las listas de comprobación de gobernanza en revisiones vivas y extenderlo con el mismo rigor a las capacidades que se añaden al agente (servidores MCP, skills). Cada uno de los pasos son el movimiento desde el control disponible al control aplicado.

El modelo de madurez del despliegue se encuentra por debajo del nivel óptimo, a pesar de contar con capacidades que no son improvisadas, sino que son de primera clase y son habilitadas por la plataforma, pero la configuración, la automatización en la respuesta a incidentes y la gobernanza continua no son impuestas por defecto. Se han de aplicar en su configuración de forma consciente por el usuario. El factor condicional no es la tecnología, es el criterio ensamblador de dicha tecnología.

La seguridad de un agente se ha de construir partiendo de una buena base. Cloudflare proporciona, junto con Anthropic, esa base de forma óptima. El propósito de estas líneas ha sido ofrecer un criterio (los principios Zero Trust), con el que recorrer la distancia que separa un despliegue funcional a uno maduro. Continuar con la maduración no es eliminar defectos, sino ejercer la disciplina Zero Trust sobre una arquitectura que lo permite.

6.- Nota de Actualización.
7.- Bibliografía.
  • Anthropic. (22 de junio de 2026). Tools
  • Cloudflare. (22 de junio de 2026). Commands
  • Cloudflare. (22 de junio de 2026). Tunnels
  • Cloudflare. (22 de junio de 2026). Retries
  • Cloudflare. (22 de junio de 2026). Skills

Publicado por Chema Alonso a las 7:46 a. m. 0 comentarios

Etiquetas: , , , , , , , , , , , , ,

Suscribirse a: Entradas (Atom)

Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares