Mostrando entradas con la etiqueta hardening. Mostrar todas las entradas
Mostrando entradas con la etiqueta hardening. Mostrar todas las entradas

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: , , , , , , , , , , , , ,

martes, agosto 04, 2026

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

Continuando lo visto en la primera parte de esta serie, y en la segunda, continuamos en este apartado con cómo configurar modelos de Zero Trust para Agentes IA utilizando las tecnologías de Cloudflare, comenzando ahora con la validación de los datos de entrada y los datos de salida, un tema de los más importantes.

Figura 23: Cómo desplegar Zero Trust para Agentes IA en Cloudflare (3)

En la próxima parte daremos por terminado este artículo, pero antes vamos a recorrer las fortificaciones que aún nos quedan por hacer en un modelo Zero Trust y cómo hacer éstas con Cloudflare.

4.4.- Validación de entrada y salida de datos.

El principio.

La segmentación traza el mapa de con quién puede hablar el agente, este control vigila que viaja por esas conexiones. Tiene dos caras. En la entrada, el problema es la inyección. Como se estableció en la premisa, el agente no distingue de forma fiable una instrucción legítima de una orden maliciosa incrustada en los datos que procesa (un correo, una página web, el resultado de una herramienta). 

OWASP lo recoge como el secuestro objetivo del agente (ASI01- Agent Goal Hijack), una de sus categorías primarias. En la salida, el problema es la exfiltración: que el agente, comprometido o no, emita datos que no deberían salir.

Figura 24: ASI01- Agent Goal Hijack

El eBook de Anthropic articula este control con claridad: la validación de entrada bloquea los intentos de manipulación en la frontera, rechazando instrucciones maliciosas antes de que el agente las procese y los controles de salida restringen lo que el agente puede producir, limitando la fuga de datos incluso cuando un atacante logra comprometer su comportamiento. La idea rectora es que el agente no puede ser su propio filtro. La validación debe ser un filtro externo, previo al procesamiento.

Figura 25: Prompt Injection

Hay un matiz propio del mundo agéntico que conviene no ignorar. La validación de entradas no se traslada directamente desde la seguridad tradicional. La inyección SQL, tiene patrones definidos y campos acotados, pero las entradas de un agente son libres e impredecibles, lo que hacen que sean insuficientes dichas reglas. Aun así, se puede validar contra esquemas esperados, imponer longitudes máximas y rechazar patrones conocidos antes de que la entrada llegue al agente.

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

El despliegue ofrece varios puntos donde insertar esta validación, aunque conviene señalar un hecho destacable. La documentación describe los canales por donde entra el contenido externo, pero no afirma que exista un filtrado de contenido automático sobre ellos. El filtro, en buena medida, es algo que quien despliega debe construir en los puntos que la plataforma habilita.

El correo es un ejemplo de entrada no confiable. Cada agente puede tener un buzón y cuando llega un mensaje, el agente recibe un evento que le indica que un correo ha llegado y le ofrece leerlo. Este cuerpo es contenido externo que entra en el contexto del agente: un vector de inyección indirecta. La documentación describe el mecanismo, pero no un filtrado del contenido. Ese filtrado es responsabilidad de quien despliega. Lo mismo ocurre con la navegación web: recuperar una página es ingerir contenido no controlado.

Figura 26: Agent Email en Cloudflare

El punto de inserción natural para la validación es la herramienta personalizada, y a presentada en 4.2. Su esquema de entrada, declarado y válido, rechaza llamadas con forma inesperada antes de ejecutar nada. Su cuerpo es el lugar donde la propia documentación sugiere validar entradas, Redactar información sensible o comprobar autorización antes de hacer el trabajo. Esa redacción de información sensible es, precisamente, en control de salida al filtrar lo que vuelve al agente o sale hacia un servicio.

Para la ejecución de comandos, el Sandbox SDK ofrece una mitigación concreta contra la inyección de shell: pasar los datos por la entrada estándar en lugar de interpolarlos en el comando, lo que permite procesar entrada de usuario sin riesgo de inyección. La documentación lo ilustra con un caso donde una cadena maliciosa, pasada por entrada estándar, resulta inofensiva, mientras que incrustada en el comando sería peligrosa. El propio modelo de responsabilidad del Sandbox sitúa además la validación y el saneamiento de entradas explícitamente del lado de quien despliega, no de la plataforma (Cloudflare, 2026u).

Figura 27: Cloudflare Commands en Sandbox

Y en la dimensión de salida, el ecosistema de Cloudflare One aporta control sobre el canal de los servidores MCP, por el que el agente invoca herramientas externas. El portal de servidores MCP permite curar qué herramientas quedan expuestas (desactivando herramientas individuales o derivando a una lista de permitidos para mostrar solo un subconjunto) y somete el acceso a cada servidor a la identidad corporativa, imponiendo a qué servidores accede cada quién con independencia de las políticas del propio servidor. Además, registra las peticiones individuales realizadas con las herramientas del portal. Curar el canal y auditarlo es, en este contexto, una forma de control sobre lo que el agente puede llegar a enviar a través de él.

Continuando la maduración Zero Trust.

El primer avance de maduración consiste en reforzar progresivamente el filtro de entrada. Un punto de partida razonable es validar formatos contra esquemas esperados, imponer longitudes máximas y rechazar entradas manifiestamente malformadas. Sobre esa base, incorporar detección de patrones de ataque conocidos y filtrado de cargas codificadas y en los entornos más exigentes, delimitar de forma explícita el contenido no confiable para que el modelo lo trate como inseguro (la técnica de spotlighting). El eBook de Anthropic describe esta progresión y aporta criterios concretos para cada estadio  de forma coherente con el principio Zero Trust de no confiar en la entrada y filtrarla en la frontera.

El segundo avance es tratar todo el canal por el que entra el contenido externo (correo, web, resultado de herramientas) como no confiable por defecto, e interponer en cada uno un punto de validación antes de que su contenido alcance el contexto del agente. La forma natural de lograrlo en este despliegue es encapsular esos canales tras herramientas personalizadas que validen y cuando proceda, saneen o delimiten el contenido, en lugar de dejar que entre directamente.
El tercer avance es simétrico, en la salida: definir qué clases de datos no deben abandonar nunca el entorno y materializar esa decisión en los puntos disponibles (la redacción dentro de las herramientas personalizadas y la curaduría y auditoria del canal MCP), de modo que la exfiltración quede dificultada incluso si el agente es manipulado para intentarla.

4.5.- Observabilidad y comportamiento.

El principio.

Los controles anteriores deciden que puede hacer el agente, la observabilidad nos permite saber está ocurriendo realmente en el sistema. Es un requisito indispensable por el cual pueden verificarse, ajustarse y defenderse los demás controles, ante un incidente. 

Por este motivo CISA eleva la visibilidad y analítica a la categoría de capacidad trasversal de toda arquitectura Zero Trust. En la práctica, la visibilidad consiste en recopilar y observar la telemetría, los registros y los eventos que generan el entorno. El análisis de esta información es lo que verdaderamente permite actualizar las políticas de acceso, agilizar la respuesta a incidentes y construir un perfil de riesgo para tomar medidas proactivas antes de que el ataque se materialice. NIST, siguiendo la misma línea, sitúa la monitorización continua entre los fundamentos de la arquitectura Zero Trust.

Figura 29: Capacidades Transversales de CISA para Zero Trust

En un agente, la obsevabilidad tiene una exigencia añadida, no basta con registrar el resultado de una acción, hay que poder reconstruir la cadena de acciones que llevó a ella (que entrada recibió, qué herramienta invocó, con qué argumentos, con qué resultado). Sólo así puede distinguirse un comportamiento legítimo de uno inducido por una inyección y solo así atribuirse una acción a quien la lanzó.

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

El despliegue es en esta dimensión, notablemente sólido, con un posible punto ciego importante que ya se ha señalado.

La sesión es, por diseño, un registro. Como se describió en la sección 3, el historial de eventos de cada sesión persiste y se puede recuperar íntegro: la conversación, los turnos, los resultados de herramientas. La sesión no es solo ejecución, es también su propia bitácora.

Sobre el acceso al panel, cuando se coloca Cloudflare Access delante, se obtiene un registro de auditoria sin escribir código: Access registra cada petición autenticada, lo que resulta útil cuando una sesión hace algo sorprendente y se quiere saber quién la lanzó. La identidad de quien opera queda ligada a lo que la sesión hace.

Figura 30: Securing Access

Sobre el comportamiento interno del agente, los dos backends ofrecen vías distintas. En MicroVM existe un terminal en vivo a través del panel, que permite ver exactamente lo que el agente vio. En Isolate, que no tiene shell, la observabilidad se obtiene de los registros de Workers, donde el despachador de herramientas registra cada nombre de herramienta y su resultado. En ambos casos, la actividad del agente deja rastro consultable.

El punto ciego es el ya conocido y aquí cobra todo el sentido: las herramientas del servidor de Anthropic se ejecutan fuera de la cuenta de Cloudflare y no dejan ninguna traza (ni registro, ni auditoría). Lo que no se ve no se puede vigilar. Por eso el ecosistema ofrece variantes equivalentes de navegación que sí recorren en la cuenta propia y cuyas peticiones son observables en los registros de la cuenta. La diferencia entre una y otra opción es, exactamente, la diferencia entre tener y no tener observabilidad.

Continuando la maduración Zero Trust.

El primer avance es centralizar y correlacionar lo que hoy está disponible pero disperso: el historial de eventos de sesión, los registros de acceso de quien la lanzó y los registros del despachador de herramientas. Reunidos y vinculados por el identificador de sesión, permiten reconstruir la cadena completa (quién lanzó qué sesión, qué hizo el agente, con qué herramientas y resultados) que la investigación de un incidente requiere.

El segundo avance es eliminar los puntos ciegos por decisión de diseño: preferir, para toda navegación web, las variantes observables que corren en la cuenta propia y mantener desactivadas las que no dejan traza. Una observabilidad con huecos conocidos es una observabilidad que un atacante usará precisamente por esos huecos.

El tercer avance lleva la observabilidad del registro pasivo a la detección activa. Disponer de los registros es la base; estadio maduro es analizarlos para construir el perfil de riesgo del que habla la CISA (establecer que comportamiento es normal para un agente y alertar sobre desviaciones, como una herramienta que nunca se invoca, de pronto se le hace una llamada o un volumen de salida anómalo) de modo que la observabilidad no sólo explique los incidentes después, sino que ayude a detectarlos mientras ocurren.

4.6.- Contención y recuperación.

El principio.

Zero Trust asume que las defensas pueden fallar y que un sujeto puede acabar comprometido. Por eso exige, además de prevenir, contener el daño cuando ocurre y poder volver a un estado bueno conocido. La contención busca limitar el radio de alcance (blast radius), es decir que un agente comprometido afecte lo mínimo. Y la recuperación, restaura la operación sin arrastrar el estado corrupto.

Figura 31: Blast Radius

La taxonomía OWASP para aplicaciones agénticas recoge expresamente estos mecanismos: interruptores de parada, límites de radio de alcance, aislamiento entre el planificador y el ejecutor y contención en tiempo de ejecución, como defensas frente a la propagación de errores y el abuso entre agentes. En un agente, esto se concreta en tres capacidades: poder detenerlo de inmediato cuando se detecta un comportamiento anómalo, acotar por diseño lo que su compromiso pueda alcanzar y restaurar su entorno a un punto limpio si propagar aquello que hubiera quedado corrompido.

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

El despliegue ofrece una base de contención y recuperación que cubre las tres capacidades, con un matiz en la resiliencia de la cola de trabajo.
  • El aislamiento como contención ya se trató: cada sandbox corre en su propia máquina virtual, de modo que el compromiso de uno no alcanza a los demás y la segmentación de salida acota con quién puede comunicarse un agente comprometido. La contención del radio de alcance no es, por tanto, un añadido. Está en la arquitectura.
  • La recuperación está cuidadosamente diseñada: El directorio de trabajo de cada sesión MicroVM se preserva mediante copias a almacenamiento de objetivos, que se restauran al reanudar. Isolate persiste su estado de forma transparente. Y el diseño es defensivo en un punto importante: nunca se restuaran sobre un contenedor en ejecución y si una restauración falla, el sistema registra el fallo y arranca con un directorio limpio en lugar de bloquearse. Es una recuperación que prioriza no propagar el estado dañado.
El matiz que señalar está en la resiliencia de la cola de trabajo del entorno de ejecución. La documentación del sistema de colas advierte de que no existe una cola de mensajes fallidos. Una tarea que falla se elimina y se recomienda implementar la persistencia propia, los reintentos bloquean la cabeza de la cola y no hay un cortacircuitos.

Continuando con la maduración Zero Trust

El primer avance es convertir la parada manual en respuesta automática: vincular la detección de comportamiento anómalo (del control de observabilidad) con la función de detención, de modo que una desviación grave no dependa de que un humano esté mirando. Es el interruptor de parada OWASP llevado a su forma efectiva, disparado por una señal, no solo por una persona.

El segundo avance es endurecer el radio de alcance combinando los controles ya descritos: segmentación de salida estricta, identidades de alcance acotado e inyección de credenciales que el agente no custodia. Cada uno reduce lo que un compromiso puede tocar; juntos, materializan el límite del radio de alcance que pide la taxonomía agéntica.
El tercer avance atañe a la resiliencia de las tareas y a la retención de los datos de recuperación. Por un lado, implementar la persistencia propia de las tareas críticas que la cola no garantiza, de modo que un fallo no las pierda en silencio. Por otro, gobernar la retención de las copias automáticamente, así que definir y aplicar una política de retención es responsabilidad de quien despliega, un punto que enlaza directamente con la gobernanza de datos de la sección siguiente.


Publicado por Chema Alonso a las 6:01 a. m. 0 comentarios

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

miércoles, julio 29, 2026

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

Las secciones anteriores - vistas en la primera parte de este artículo que puedes leer aquí - establecieron la premisa (el modelo como eslabón que no distingue una instrucción legítima de una inyectada) y la descripción del sujeto: el Agente IA que se ejecuta en una Sandbox desplegado en la cuenta de Cloudflare, gobernado desde un Durable Object externo. 

Figura 12: Cómo desplegar Zero Trust para Agentes IA en Cloudflare (2)

Esta sección recorre, dimensión por dimensión, los controles para postular esa arquitectura como Zero Trust. Cada uno de los controles sigue el mismo recorrido: primero qué pide el principio Zero Trust, luego dónde se sitúa hoy en el ecosistema Cloudflare frente a ese principio y por último cómo continúa la maduración hacia un estadio óptimo del modelo de madurez.

4.- Aplicación: los controles Zero Trust sobre el agente.

El orden sigue la secuencia natural de una petición. Primero se establece quién es el sujeto (identidad y autenticación). Después se decide qué se le permite hacer (control de acceso) y por dónde puede moverse (segmentación). 

Figura 13: Las siete dimensiones de control Zero Trust.

Luego se vigila lo que entra y lo que sale (validación de datos), lo que hace mientras actúa (observabilidad) y cómo se le contiene si algo va mal (contención y recuperación). Por encima de todo, la gobernanza mantiene el conjunto coherente en el tiempo.

4.1.- Identidad y autenticación.

El principio.

Zero Trust parte de que ningún sujeto goza de confianza implícita en ninguna circunstancia (independientemente de su ubicación o propiedad). Toda identidad debe verificarse antes de conceder acceso y verificarse de forma continua. NIST SP 800-207 extiende ese principio explícitamente a los sujetos que no son personales. En su sección 5.7, dedicada al uso de entidades ‘no-persona’ en la administración de una arquitectura Zero Trust, reconoce que los agentes de inteligencia artificial y otros componentes de software se despliegan para gestionar tareas en la red de la organización y necesitan autenticarse ante los componentes de control, a veces en lugar de un administrador humano. 
Y advierte de tres riesgos que describen con precisión la situación de un agente: que su listón de autenticación sea más bajo que el de un human (una clave de API frente a una autenticación multifactor), que un atacante consiga inducirlo o coaccionarlo para ejecutar una tarea para la que el atacante no tiene privilegios y que un atacante robe las credenciales del agente y lo suplante. La identidad del agente, por tanto, no es un detalle administrativo: puede ser la primera superficie que una atacante intentará explotar o usurpar.

La consecuencia para el diseño es doble. La identidad del agente debe ser fuerte (no una credencial estática y longeva que, si se filtra, abre una puerta de modo indefinido) y debe ser verificable por algo externo al propio agente, porque, como se ha establecido en la premisa, el modelo no puede ser el guardián de su propia identidad.

Aplicándolo en el ecosistema de Cloudflare.

Conviene distinguir desde el principio dos identidades que son fáciles de confundir: la del plano de control (el componente que orquesta las sesiones) y la del Agente IA cuando accede a recursos externos. La primera la resuelve hoy el despliegue de referencia con una credencial única, la llamada Clave de Entorno (ANTHROPIC_ENVIRONMENT_KEY). Es la clave con la que el plano de control se identifica con Anthropic y con ella realiza todas las operaciones de coordinación: pedir el trabajo pendiente, confirmar su recepción, señalar que sigue vivo, forzar la parada de sesión y recibir el flujo de eventos de cada una. Es decir, una sola credencial gobierna toda la relación entre el plano de control y la plataforma.

Figura 15: Claves de control de Antrhopic desde Cloudflare

Que una única clave concentre todas esas operaciones tiene una lectura Zero Trust inmediata. Por un lado, es un punto de alto valor que conviene proteger y rotar con cuidado: el repositorio lo gestiona como secreto, no como variable en claro y verifica además la firma de cada webhook entrante antes de actuar sobre él, de modo que un evento no firmado no llega a procesarse. 

Por otro lado, es exactamente el tipo de credencial cuya captura permitiría a un atacante suplantar al sistema (el tercero de los registros que advierte NIST SP 800-207 en su sección 5.7), lo que refuerza la necesidad de tratarla con el mismo rigor que cualquier identidad privilegiada. Esa credencial sin embargo, identifica al plano de control, no al Agente AI cuando este sale a actuar sobre el mundo (cuando accede a un servicio, una API o un servidor). 

Para esa segunda identidad, la del Agente IA como sujeto que actúa, el ecosistema Cloudflare One aporta dos piezas directamente aplicables. La primera es la autenticación mutua mediante mTLS: en ella, tanto el cliente como el servidor presentan certificados durante el handshake y Cloudflare Access la propone explícitamente como vía para que sistemas automatizados y dispositivos demuestren su identidad presentando un certificado de cliente en lugar de iniciar sesión a través de un proveedor de identidad. 
Es, en términos de NIST SP 800-207, una credencial de identidad para una entidad ‘no-persona’ (también llamadas "Non-Human Identities"): un certificado en lugar de un login humano. La segunda pieza es la emisión de certificados de vida corta para el acceso a infraestructura: en el modelo de acceso por SSH de Cloudflare, las claves estáticas tradicionales, que pueden permanecer sin cambios en los servidores durante años, se sustituyen por certificados efímeros emitidos a partir del token del inicio de sesión, con políticas por destino y por usuario y registro de los comandos ejecutados. Conviene situar esta segunda pieza con precisión: la documentación describe el acceso de usuario humano por SSH, no el del Agente IA.  Su valor aquí es que demuestra que la plataforma ya dispone del mecanismo de credenciales efímeras y de mínimo privilegio temporal, que es justamente el patrón que un Agente IA como entidad ‘no-persona’ necesita.

Situado en el recorrido de madurez, el ecosistema ofrece, por tanto, los materiales para una identidad ‘no-humana’: certificados de cliente, credenciales efímeras, gestión de secretos y verificación de firmas. Pero su aplicación al Agente IA concreto depende de que el operador los conecte deliberadamente. La plataforma provee las piezas, falta ensamblarlas.

Continuando con la maduración Zero Trust

El paso natural hacia un estadio óptimo es sustituir las credenciales estáticas y de larga vida, allí donde hoy haya, por credenciales efímeras y de alcance acotado. Una clave de entorno única y longeva cumple su función, pero el principio Zero Trust de verificación continua y de mínimo privilegio temporal apuntan hacia credenciales que caduquen por diseño y que se emitan en el momento de uso, de modo que una filtración tenga una ventana de validez corta en lugar de definitiva. El mecanismo de certificados efímeros que la plataforma ya usa para el acceso de usuarios marca la dirección: llevar ese mismo patrón (emisión justo a tiempo, vida corta, alcance por destino) a la identidad con laque el agente accede a los recursos.

Un segundo avance consiste en considera la identidad del agente como una entidad ‘no-persona’ de primer orden y no como una extensión de la cuenta que lo despliega: que cada Agente IA, o cada clase de agente, porte una credencial propia y distinguible (un certificado de cliente mediante autenticación mutua) de modo que las decisiones de acceso y los registros de auditoria puedan atribuirse a una identidad concreta y verificable, en lugar de una credencial compartida. Esto alinea el despliegue con la advertencia de NIST SP 800-207 sobre el robo y la suplantación de credenciales de agentes: cuanto más acotada y atribuible es la identidad, menor es el alcance de lo que un atacante obtiene si la captura.

4.2.- Control de acceso: el principio de mínima agencia.

El principio.

Una vez verificada la identidad del sujeto, Zero Trust impone una segunda pregunta: ¿qué se le permite hacer? Para responderla de forma estructurada, el marco Zero Trust recurre al método Kipling, que articula toda política de acceso en torno a seis preguntas (quién, qué, cuándo, donde, por qué y cómo). 

La guía de la Cloud Security Alliance lo recoge en dos planos complementarios: por un lado, define la política como el conjunto de reglas de gobernanza que determina el quién, qué, cuándo, dónde, cómo y por qué del acceso al recurso; por otro, sitúa el método Kipling en el paso concreto de crear las política Zero Trust, para determinar quién o qué puede acceder a la superficie a proteger, considerando de forma explícita tanto entidades persona como no-persona (servicios, aplicaciones, bots). Un Agente de IA es, precisamente, una de esas identidades no-persona y aplicarle las seis preguntas convierte un permiso difuso en una política precisa: quién es el agente (su identidad tratada en la sección anterior), a qué recurso accede y para qué, cuándo y desde dónde, y cómo (con qué herramienta y bajo qué condiciones) se permite la acción.

El principio rector que ordena la respuesta a esas preguntas es el de mínimo privilegio, que en el mundo de los agentes adopta una forma propia, la de mínima agencia: un agente no debe disponer de más capacidades de las estrictamente necesarias para su tarea, porque cada capacidad que posee es también una para que un atacante pueda inducirle a usar. La taxonomía de OWASP para aplicaciones agénticas recoge este riesgo de forma explícita en sus categorías de abuso de identidad y privilegio del agente y de uso indebido de herramientas y sitúa los controles de mínima agencia como una de las defensas trasversales del catálogo.

Figura 17: Abuso de Identidad y Privilegios en OWASP Top 10 para Agentic AI

La diferencia con el control de acceso clásico es importante y conviene no perderla de vista. En un sistema tradicional, los permisos limitan lo que un usuario puede solicitar. En un sistema agéntico, el agente decide por sí mismo qué herramienta invocar a partir de un objetivo en lenguaje natural. Si entre esas herramientas hay una con capacidad de hacer daño, bastaría con que una instrucción inyectada en sus datos de entrada lo dirija hacia ella. Por eso la mínima agencia no es sólo buena higiene, es la contención directa del riesgo de inyección descrito en la premisa. Cuantas menos herramientas potentes estén al alcance del Agente IA, menor es lo que la inyección puede lograr (Blast Radius).

De aquí se derivan dos exigencias de diseño. La primera es que el catálogo de herramientas del Agente IA esté curado: que sólo contenga lo que la tarea requiera y nada más. La segunda es que las decisiones sobre si una acción concreta pueda ejecutarse no dependa del propio modelo (que, como se estableció, no puede ser garantía por sí mismo), sino de una lógica externa y determinista o de la intervención de un humano cuando la acción lo merezca.

Cómo aplicarlo con el ecosistema Cloudflare.

El despliegue de referencia ofrece tres mecanismos que, combinados, cubren buena parte de esta exigencia.

El primer mecanismo es la curaduría del conjunto de herramientas. Cada herramienta del catálogo (tanto las propias del Agente IA como las personalizadas) se activa o desactiva de forma individual en la configuración del agente y una herramienta desactivada no aparece ni puede ser invocada. En el despliegue de Cloudflare, además, las herramientas integradas están condicionadas a que exista la conexión que cada una necesita: sólo aparecen en el catálogo del Agente IA cuando quien lo despliega ha configurado el recurso correspondiente. Es mínima agencia por construcción: lo que no se ha conectado, no existe para el agente.

El segundo mecanismo son las políticas de permiso. Anthropic define para Managed Agents dos tipos de políticas: una que permite la ejecución automática y otra que pausa la sesión y espera la aprobación humana antes de actuar. Los valores por defecto son razonables desde la óptica Zero Trust: las herramientas que provienen de servidores MCP externos quedan por defecto en el modo que exige aprobación, de modo que una herramienta nueva añadida a un servidor MCP no se ejecuta en el despliegue sin que alguien la confirme.
El tercer mecanismo y el más potente para un control determinista, es la herramienta personalizada. En el despliegue de Cloudflare, una herramienta personalizada no es una llamada que el modelo ejecuta por su cuenta. El modelo sólo emite petición estructurada y es el código quien despliega (ejecutándose en el Durable Object, con acceso a las conexiones Worker) el que realiza la operación y devuelve el resultado. Esto convierte a la herramienta personalizada en el lugar natural para insertar un control determinista. La propia documentación señala que una herramienta personalizada puede validar entradas, imponer límites de tasa, redactar información sensible o comprobar autorización antes de hacer el trabajo.

Situado en el recorrido de madurez, el ecosistema ofrece, por tanto, los tres ingredientes de la mínima agencia: un catálogo que se puede recortar, una política que puede exigir aprobación humana y un punto (la herramienta personalizada) donde insertar la comprobación determinista. Conviene, eso sí, ser preciso sobre el límite: las políticas de permisos binarias no se aplican a las herramientas personalizadas. Es decir, para una herramienta personalizada, el control no lo da la política de permiso, sino la lógica que quien la programa incluya dentro de ella. Lejos de ser una carencia, esto sitúa el control en el lugar correcto: dentro de código propio, determinista y auditable. 

Continuando la maduración Zero Trust.

El avance hacia un estadio óptimo consiste en no depender de un único mecanismo, sino en combinarlos según el riesgo de cada herramienta. Las herramientas inocuas pueden quedar en ejecución automática, pero las que tocan sistemas sensibles, tras aprobación humana. Las que requieren una decisión reproducible (comprobar que el identificador pertenece al usuario de la sesión, que la operación está dentro de la cuota, que el dato no contiene información que no deba salir) deben encapsularse como herramientas personalizadas con esa comprobación escrita en su interior. La forma madura consiste en asignar a cada herramienta el mecanismo que corresponde a su riesgo.

Un segundo avance, alineado con el principio de mínima agencia de OWASP, es preferir herramientas tipadas y de propósito estrecho frente a capacidades genéricas y potentes. Una herramienta de shell concede al agente la capacidad de ejecutar prácticamente cualquier cosa. Una herramienta personalizada que hace exactamente una operación, con una entrada válida y una salida acotada, reduce drásticamente lo que una inyección puede lograr a través de ella. Sustituir capacidades amplias por herramientas estrechas y verificables es, en sí mismo, un acto de reducción de agencia.

4.3.- Segmentación: a qué puede conectarse el agente.

El principio.

Las dos preguntas anteriores (quién es el agente y qué se le permite hacer) se completan con una tercera del método Kipling: ¿dónde? Una vez que la entidad está dentro, Zero Trust no concede libertad de movimientos, al contrario, compartimenta todo para que cada una de las entidades alcance solo los recursos que su tarea exige. Es el principio de microsegmentación, que NIST SP 800-207 sitúa como enfoque fundamental en la arquitectura Zero Trust: dividir el entorno en segmentos pequeños y proteger cada recurso de forma que el acceso a uno de ellos no implique el acceso a los demás.

En un agente esto se reduce en el control del tráfico de salida. Un Agente IA comprometido por una inyección puede hacer daño también con aquello que puede comunicarse fuera: el servidor al que envía datos robados, el punto de mando del que recibe instrucciones, el servicio interno al que se conecta sin autorización. Segmentar a un Agente IA es decidir con qué puede hablar. Conviene distinguir este control del de la sección siguiente: la segmentación define a qué destinos puede conectarse (el mapa de sus movimientos). La validación de salida vigila qué datos viajan por esas conexiones. Aquí se traza el mapa, allí se inspecciona la carga.

El requisito es doble: denegación por defecto (ningún destino no autorizado explícitamente) y una frontera establecida antes de que el Agente IA actúe, porque cualquier ventana sin restricciones es una ventana de exfiltración.

Cómo aplicarlo con el ecosistema Cloudflare.

El despliegue resuelve la segmentación con un motor de políticas de salida que cumple ambos requisitos. La frontera antes de la acción está garantizada por diseño: ambos backends adjuntan la política de salida antes de iniciar cualquier código del Agente IA, de modo que no existe ninguna ventana en la que un sandbox sin restringir alcance un destino no deseado.

Figura 20: Políticas de conexión para Sanboxes de Agentes IA

La denegación por defecto está disponible, pero requiere que sea una decisión consciente. El motor admite listas de permitidos y de no permitidos. La primera bloquea todo lo demás. La segunda, una lista solo de no permitidos, deja pasar al resto del acceso público. El primer modo es el que está alineado con Zero Trust y la propia guía recomienda la denegación por defecto frente al permiso por defecto. El matiz que debe conocerse es, que una sesión que no encaja con ninguna política ni con una política general se ejecuta sin restricción alguna de salida. La denegación por defecto, por tanto, no es automática: se consigue con una política general restrictiva que ninguna sesión puede eludir.

El motor va más allá del filtrado por host. Sus reglas permiten cinco comportamientos (permitir, denegar, inyectar una credencial sin que el Agente IA vea el secreto, enrutar a un servicio privado o pasar el tráfico por un proxy propio) y una regla de denegación prevalece siempre sobre cualquier permiso que también encaje.

En MicroVM, además, la interceptación HTTPS está activada, de modo que incluso el tráfico TLS pasa por la política, cerrando el punto ciego del canal cifrado. Para recursos interno que no deben ser accesibles desde internet, la conexión VCP aporta un detalle valioso. El Agente IA ve únicamente los enlaces permitidos por su nombre, nunca los identificadores reales del servicio. No puede dirigirse a lo que no se le ha expuesto, porque no conoce su existencia.

Figura 21: Isolate vs. VM-based Sandboxes

Hay un límite que hay que señalar, porque es la excepción más importante del modelo. Ciertas herramientas no pasan por la política de salida (egress). Las herramientas de servidor de Anthropic, búsqueda y recuperación de web integradas ((web_fetch y web_search), se ejecutan en infraestructura de Anthropic, no en el sandbox ni en la cuenta de Cloudflare. No hay visibilidad sobre ellas, no dejan rastro y la política no se les aplica. El despliegue las desactiva por defecto. 

Existen variantes que sí corren en la cuenta propia y dejan auditoria, pero que tampoco atraviesan la política por sesión, porque se despachan desde la infraestructura de renderizado y no desde dentro del sandbox. La segmentación solo se completa si se tiene en cuenta qué canales quedan fuera de ella.

Continuando con la maduración Zero Trust.

El primer avance es adoptar deliberadamente la denegación por defecto: una política general restrictiva, con una lista de permisos acotada a lo que la tarea necesita, aplicada a toda sesión para que ninguna quede sin restricciones por no encajar con una política especifica. Es la diferencia entre bloquear lo no autorizado y bloquear solo lo que alguien recordó denegar.

El segundo es cerrar o vigilar los canales que escapan a la política. Como las herramientas de servidor de Anthropic no son observables ni filtrables, lo maduro es mantenerlas desactivadas y si se necesitan encauzarlas por las variantes que dejen auditoria, tratando ese rastro como parte de la observabilidad. Los recursos que jamás deban exponerse a internet van tras la conexión VPC, de modo que ni figuren entre los destinos que el agente puede nombrar.

Figura 22: Canales de salida y su cobertura por la política de egress

El tercero aprovecha la inyección de credenciales como segmentación de identidad, no solo de red. Al inyectar el secreto de un servicio en la petición saliente sin que el agente lo vea, se separa el uso del servicio de la posesión de un secreto. El Agente IA habla con la API, pero no puede extraer la clave porque nunca la tiene. Llevar este patrón a toda integración sensible convierte cada secreto en algo que el agente usa sin custodiar.

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

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

lunes, julio 27, 2026

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.

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

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.

Figura 4: Core Trust Zero Logical Core. Fuente:
NIST SP 800-207, Zero Trust Architecture · Dominio público

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. 

Figura 5: El control fuera del modelo (PDP/PEP).
Elaboración propia a partir de (NIST, 2020).

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.

Figura 6: Método Kiplling para Zero Trust for Policy Creation

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. 

Figura 7: Zero Trust Maturity Model v2.0. Fuente CISA

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. 

3.2.- El plano de control: un Worker y un Durable Object por sesión.

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.

Figura 9: Arquitectar del despliegue de referencia de Cloudflare 

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.

Figura 10: Arquitectura del despliegue.

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 tenemos en la siguiente 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,   

Publicado por Chema Alonso a las 9:17 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