Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
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 configura 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).
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.
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.
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.
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 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
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.
escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord
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.
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.
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.
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.
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.
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.
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.
- La parada inmediata existe como operación de primera clase: entre las funciones que el plano de control ejerce con su credencial está la de forzar la detención de una sesión. Hay, además, una contención por diseño que opera sola: las sesiones no se ejecutan indefinidamente, sino que se detienen automáticamente tras un periodo de inactividad. Una sesión olvidada no queda viva indefinidamente como superficie de ataque.
- 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.
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.
Un saludo,
