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

Los modelos de lenguaje que aportan la inteligencia a un Agente IA procesan en un mismo flujo las instrucciones y los datos, no hay una frontera que distinga de forma fiable una orden legítima de una instrucción maliciosa incrustada en el contenido. Esa premisa estructural es la tesis de este documento: la seguridad del Agente de IA no puede residir en el propio modelo, sino en controles externos, deterministas y verificados de forma continua. Es, precisamente, la lógica del Zero Trust.

En este artículo se pretende dar traslado a los principios Zero Trust, reconocidos por NIST, CISA, NSTAC, OWASP, CSA y Anthropic, al despliegue de Agentes IA gestionados sobre la infraestructura de Cloudflare. Tras situar al agente como sujeto a proteger, se recorren siete dimensiones de control (identidad, acceso, segmentación, validación de datos, observabilidad, contención y gobernanza), mostrando en cada uno qué pide el principio, qué ofrece hoy la plataforma y cómo avanzar hacia un estadio de madurez óptimo.

1.-La premisa fundamental: el modelo como eslabón estructural.

La seguridad de un sistema agéntico parte de una observación que hay que tener presente, ya que en ella se basa todo lo demás. Los modelos de lenguaje frontera actuales, con independencia del proveedor, procesan en un mismo flujo las instrucciones del sistema, los datos que se le entregan, las instrucciones del usuario y, cuando existe, una instrucción maliciosa insertada en dichas instrucciones o incrustada en los datos. No posee una división en su arquitectura que identifique de forma fiable una orden legítima, de una instrucción inyectada en el contenido que analiza. Esto no es una limitación de un modelo concreto, es una propiedad estructural del paradigma.

El consenso en el sector así lo recoge. OWASP señala que la inyección de Prompts es viable por la propia naturaleza de la IA Generativa y que debido a la influencia estocástica en el funcionamiento de los modelos, no está claro que exista un método eficaz a la hora de prevenirlo. Microsoft lo enfoca desde la arquitectura: el modelo no ejecuta nada por sí mismo, simplemente genera la solicitud. Es el código de la aplicación o el framework quien lo interpreta y lo ejecuta, siendo esa separación un límite clave en la seguridad. Anthropic por su parte señala en su marco de seguridad para agentes, que el Agente IA puede ser manipulado y que el daño que puede provocar es llevado a cabo a velocidad de máquina.

De esta premisa se deduce una consecuencia directa para el diseño: la seguridad no puede apoyarse en el modelo. Si las instrucciones del sistema son, para el modelo, un texto más dentro del mismo flujo que los datos, entonces los controles existentes para que el modelo “decida bien” son insuficientes por construcción. Una protección efectiva ha de apoyarse en controles externos al modelo y de forma determinista, para poder eliminar la dependencia interpretativa que este haga de su contexto. 

Es la lógica que el Zero Trust aplica desde su origen: NIST sitúa la decisión de acceso en el punto de decisión de y un punto de aplicación de políticas (PDP/PEP) externos a la entidad que solicita el acceso y el mismo estándar advierte que las entidades que no son personas, como los agentes de software, pueden ser inducidas a realizar acciones para las que no tienen privilegios.

2.- Zero Trust aplicado a agentes: principios y método.

Esta es la base sobre la que se construye el resto del documento. Implementar Zero Trust en Agentes IA no es endurecer el modelo, sino restringir su autonomía con controles externos, deterministas y verificables de forma continua, de tal manera que la confianza no exista de forma implícita ni permanente, sino que sea evaluada en cada una de sus acciones.


2.1.- Los principios, aplicados a un sujeto que actúa solo.

El Zero Trust no es un producto ni una arquitectura concreta, es un conjunto de principios rectores. Su premisa: la confianza no se concede de forma implícita, sino que se evalúa de forma continua, partiendo de que la red debe considerarse comprometida. Tres principios articulan esta premisa y los tres adquieren un matiz particular, cuando el sujeto no es una persona, sino un Agente IA que interpreta objetivos y ejecuta acciones por sí mismo para conseguir sus metas.

El primero, Verificar Siempre: toda solicitud de acceso se autentica y se autoriza con independencia del origen, y hacerlo una vez no es suficiente. La autenticación y la autorización han de ser dinámicas y han de reevaluarse durante la sesión. El estándar advierte que evaluar cada petición de forma aislada puede dejar pasar un ataque mantenido dentro de un rol autorizado, mientras tener el contexto en cuenta permite detectar desviaciones en relación con la tarea esperada. Esto se hace especialmente relevante en agentes, cuya actividad legítima es intensa y una anomalía en su comportamiento puede ser la primera señal de compromiso.

El segundo, Asumir la Brecha: se diseña dando por hecho que el compromiso ya ha ocurrido u ocurrirá. Se trabaja para limitar el daño. En agentes, esto es contener el radio de impacto (Blast radius) si el compromiso se ha producido o antes de que este suceda.

El tercero, Mínimo Privilegio: permitir solo el acceso estrictamente necesario para realizar una tarea. En el plano agéntico esto debe afinarse: no solo a que datos accede el agente, sino qué herramientas invoca, con qué frecuencia y sobre qué recursos. La autonomía deja de ser un valor por defecto, en línea con lo que describe OWASP, al tratar la agencia excesiva como un riesgo propio de las aplicaciones agénticas.

2.2.- El control vive fuera del modelo: el modelo PDP/PEP.

De su premisa fundacional se desprende que el mecanismo donde se decide y se aplica la confianza no puede estar integrado en el propio sujeto. La arquitectura Zero Trust lo resuelve separando estas funciones: la decisión recae en el Punto de Decisión de Políticas (PDP) y su ejecución en un Punto de Aplicación de Políticas (PEP), siendo ambos componentes totalmente externos a la entidad que solicita el acceso. El objetivo fundamental de este diseño es acercar dichos controles al recurso protegido, reduciendo así al mínimo la zona de confianza implícita.

Esto encaja con la naturaleza del Agente IA. El agente genera la intención de actuar, produciendo una secuencia de Tokens que representa una llamada a la herramienta, que es después el código externo quien interpreta y ejecuta. 

Es en ese punto de ejecución, fuera del modelo, donde PEP puede evaluar y autorizar la acción de forma determinista. El control no consiste en convencer al modelo de que se comporte, sino en situar la decisión en un componente externo.

2.3.- Test de diseño: ¿imposible o solo tedioso?

Tener un criterio práctico ayuda a evaluar cada control: hacerse la pregunta de si un posible ataque se convierte en algo “imposible” o si solo es algo tedioso, puede ser un principio. Los controles diseñados para añadir fricción son insuficientes ante un adversario que recorre sus pasos a gran escala y con un coste por intento descartable.

Esto importa a la hora de trabajar con Agentes IA por una razón concreta: un atacante que opera a través de un agente, o el propio agente comprometido, actúa a velocidad de máquina y con una paciencia cuasi ilimitada. Ante la duda, es preferible tener un control que impida una capacidad a mantener solo una limitación que ralentice una actividad dañina.

2.4.- El método para escribir políticas: la interrogación de cada acción.

Definir el privilegio mínimo de cada uno de los agentes, exige un método para redactar políticas acceso. El informe del NSTAC al Presidente recomienda el método Kipling añadiendo “cómo” (5W+H) para la redacción de políticas Zero Trust, como forma de determinar quien o qué puede acceder a la superficie que se quiere proteger. El método utiliza las seis preguntas quién, qué, cuándo, dónde, por qué y cómo, convirtiéndolas en atributos sobre los que se construye las reglas.

Aplicado a un Agente IA, ofrece una visión interrogativa sobre cada acción: qué agente la solicita, qué herramienta pretende invocar, en qué momento, sobre qué recurso, con qué propósito y de qué manera. Hay que precisar que el NSTAC recomienda el método para redactar políticas de acceso en general. Aplicarlo a cada acción de un agente y reevaluarlo de forma continua es una extensión natural llevado al plano agéntico, de forma que se alinee con el principio Zero Trust de verificación continua.

Esa coherencia tiene una consecuencia de diseño: si cada acción se interroga como si fuera la primera, sin que el agente acumule una confianza que después pueda ser aprovechada, se cierra el vector del agente que se comporta de forma intachable hasta el momento de actuar, un riesgo que el propio Zero Trust contempla al asumir la brecha y exigir reevaluación continua. 

2.5.- Un recorrido por estadios, no un interruptor.

Conviene encuadrar todo lo anterior en cómo el sector enfoca la adopción del Zero Trust: es un recorrido gradual. El modelo de madurez de CISA lo describe en cuatro estadios: tradicional, inicial, avanzado y óptimo. Subraya que la progresión es incremental, que puede llevar tiempo y que cada pilar avanza a su propio ritmo. 

Situar un despliegue de agentes en ese recorrido permite reconocer lo ya resuelto y orientar las aportaciones hasta el siguiente estadio, que CISA define con rasgos como el acceso justo a tiempo (JIT) y justo lo necesario, el privilegio mínimo dinámico, las políticas que responden a disparadores automáticos y la verificación continua. Esos rasgos del estadio optimo serán la referencia hacia la que se orientará la sección de aplicación.

3.- El sujeto: el agente gestionado en Cloudflare (managed-agent).

Antes de aplicar controles es perceptivo definir que es lo que se controla. El modelo Zero Trust razona sobre entidades que solicitan acceso a recursos y trasladar ese razonamiento a un Agente IA exige saber que partes lo componen, donde se ejecuta cada y que frontera de confianza lo separan. Esta sección sitúa al agente como un sujeto Zero Trust, señalando aquellos puntos donde, en la sección siguiente, enganchan concretamente los controles.

3.1.- Dos formas de ejecutar un agente, una misma capacidad.


Anthropic distribuye la misma capacidad agéntica en dos formatos operativos distintos: 

• El Agente SDK es una librería que ejecuta un bucle del agente, la lógica decide el paso siguiente, enruta las llamadas a herramientas y realimenta los resultados, todo dentro del propio proceso.

• Managed Agents, en cambio, es una API REST gestionada en la que Anthropic ejecuta el agente y el sandbox, mientras la aplicación envía eventos y recibe los resultados de forma continua a medida que se producen.

La recomendación publicada por Anthropic es prototipar localmente con el Agent SDK y pasar a Managed Agents para producción. Esta distinción importa para Zero Trust porque determina quien opera cada componente y, por tanto, donde puede situarse cada control. 

Managed Agents se organiza en torno a cuatro conceptos que conviene fijar, porque reaparecen en cada control posterior. El Agent (agente) es la definición del agente: el modelo, el prompt del sistema, las herramientas, los servidores MCP y las skills. Se crea una vez y se referencia a lo largo de muchas sesiones. El Environment (entorno) es la configuración de donde se ejecutan las sesiones: un sandbox en la nube gestionado por Anthropic o un sandbox ‘serf-hosted’ sobre la infraestructura propia. La Session (sesión) es una instancia del agente en ejecución dentro de un entrono, que realiza una tarea concreta y genera salidas. 

Los Events (eventos) son los mensajes que se intercambian entre la aplicación y el agente: turnos del usuario, resultados de herramientas y actualizaciones de estado. Esa cuarta pieza, los Events, para un entorno Zero Trust es más relevante de lo que a priori resultaría ser. El historial de eventos persiste en el lado del servidor y puede recuperarse íntegro, lo que convierte a la sesión en un registro auditable de todo lo que el agente ha hecho. 

Otro matiz, se refiere a entornos regulados: entre los casos de uso que se desprenden de la propia documentación, se señala la ejecución ‘self-hosted’, es decir, sandboxes sobre infraestructura propia para cumplimiento o residencia de datos. El despliegue de referencia de Cloudflare se realiza en la forma de ejecución ‘self-hosted’: Anthropic define la capacidad y avisa del inicio y del final de cada sesión, mientras que el plano de control y los sandboxes donde el agente se ejecuta, se despliegan en la cuenta de Cloudflare de quien lo implementa. 

En el despliegue de referencia de Cloudflare, el plano de control es un único Cloudflare Worker. Ese Worker recibe los webhooks de la plataforma de Managed Agents, despacha cada sesión a una sandbox MicroVM o ‘Isolate’ y ofrece un panel de control por HTTPs. No mantiene ningún proceso de larga duración, sino que trabaja únicamente en respuesta a un webhook de Anthropic más un cron diario que elimina filas antiguas. Esta condición implica que no hay un servidor del Agente IA  ‘siempre conectado’ que defender, sino una serie de activaciones acotadas y trazables.

Una pieza decisiva desde la perspectiva Zero Trust es que una sesión está respaldada por un ‘Durable Object’ que se ejecuta en Workers, fuera de la propia sandbox. La documentación de Cloudflare lo describe como un fragmento de código con estado que permite almacenar información sobre la sesión y controlarla desde una ubicación de confianza.

En términos del modelo Zero Trust, esto sitúa el punto de decisión y el punto de aplicación de políticas (PDP/PEP) en un lugar distinto y de mayor confianza que el sujeto controlado: el agente se ejecuta dentro del sandbox, pero quien lo gobierna lo hace desde fuera. Es la separación que hace posible que un control sea determinista en lugar de depender de la voluntad del modelo, una distinción sobre la que se volverá en el punto 4 adelante.

El ciclo de vida de una petición sigue seis pasos que conviene conocer porque cada uno es una oportunidad de control. 

• Primero un webhook entrante verifica mediante firma, HMAC-SHA256 según la verificación Standard Webhooks con una tolerancia de +/-300 segundos, guarda el evento en la base de datos D1 en Cloudflare y cuando el evento indica que la sesión ha arrancado, pasa a atender el trabajo pendiente.

• Segundo, recoge ese trabajo consultando la cola del entorno de Anthropic. 

• Tercero, elige el backend de ejecución: la elección se hace por agente, se guarda en D1 y queda en caché para las siguientes peticiones. Por defecto es MicroVM. 

• Cuarto, envía el trabajo al sandbox elegido (el contenedor MicroVM o el Durable Object del Isolate) y aquí ocurre el paso decisivo: ambos aplican la política del ‘egress’ de la sesión antes de iniciar cualquier código del agente. 

• Quinto, ejecuta: en MicroVM las herramientas estándar (bash, operaciones de ficheros) corren dentro del contenedor, mientras que las herramientas personalizadas las atiende un despachador alojado en el Durable Object; en Isolate no hay contenedor y tanto las operaciones de fichero como la ejecución de código se hacen a través del mismo despachador. 

• Sexto, el estado persiste: MicroVM guarda una instantánea de su directorio de trabajo en el almacenamiento de objetos R2 de Cloudflare cuando la sesión se queda inactiva e Isolate lo conserva automáticamente en el almacenamiento SQLite de su Durable Object.

De todo eso conviene destacar el cuarto paso. Tanto el backend de MicroVM como el de Isolate adjuntan la política de ‘egress’ de la sesión antes de iniciar cualquier código del Agente IA. Es decir la frontera de red de la sesión queda establecida antes de que el agente pueda actuar, no después. Esta precedencia reaparecerá como un patrón en varios controles de la sección 4 más adelante en este artículo.

3.3.- Dos backends de ejecución y un reparto explícito de responsabilidades.

El Agente IA se ejecuta en uno de dos backends. El backend MicroVM utiliza una sandbox SDK y los contenedores de Cloudflare, ofreciendo un shell completo dentro del contenedor y persistiendo su directorio de trabajo mediante snaptshots a almacenamiento de objetos. El backend de Isolate se construye sobre Agents SDK de Cloudflare y los Dynamic Workers. No tiene contenedor alguno y realiza las operaciones de sistema de ficheros y de ejecución de código a través de llamadas a herramientas dentro del propio Durable Object con almacenamiento SQLite. 

La elección entre ambos tiene consecuencias para varios controles (observabilidad del terminal, intercepción de tráfico, superficie shell) que se detallan más adelante. Las sesiones Isolate, no admiten la conexión de terminal en vivo que si ofrece MicroVM. Bajo el backend de MicroVM subyace el modelo de seguridad de Sandbox SDK, que conviene leer en clave Zero Trust porque reparte las responsabilidades de forma explícita. Cada sandbox se ejecuta en su propia máquina virtual, lo que proporciona un aislamiento fuerte.

Ese aislamiento, sin embargo, opera entre sandboxes no dentro de ellos. Entre sandboxes el sistema de ficheros, la memoria y la red están aislados, pero dentro del mismo sandbox todos los procesos ven los mismos ficheros, por lo que ejecutar código no confiable exige el uso de sandboxes separados por usuario. 

Lo relevante para una guía de implementación, es que la documentación advierte que el aislamiento a nivel de contenedor no protege de forma automática de cualquier amenaza. El sandbox no puede explotarse para escapar del host, pero sí puede usarse indebidamente si no se aplican una serie de patrones de seguridad (validación de entrada, aislamiento por usuario, gestión de variables de entorno y protección de secretos). Esto corresponde a quien despliega, no a la plataforma.

Todo esto es el punto de partida de todo lo que sigue. La sección 4 que tendremos en la próxima parte de este artículo recorre, dimensión por dimensión esa segunda lista (lo que corresponde a quien despliega el agente) y muestra donde el ecosistema de Cloudflare y de Anthropic ya ofrecen la pieza necesaria y dónde el avance hacia un estado de madurez más alto consiste en conectar esa pieza de forma debida. No se trata de suplir posibles carencias de la plataforma, sino de continuar con la maduración Zero Trust sobre los cimientos que la plataforma ya proporciona.

Un saludo,   

Autor: Juan Luis Cuenca Ramos