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. 

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). 

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.

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.

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.

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.

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.

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.