MyThreatIntel: Plataforma de Threat Intelligence desde la experiencia en DFIR y Respuesta a Incidentes

La inteligencia sobre amenazas se ha convertido en una pieza fundamental dentro de la ciberseguridad moderna. Sin embargo, el principal problema al que se enfrentan hoy los analistas no es la falta de información. Ocurre, de hecho, todo lo contrario: existen demasiadas fuentes, demasiados datos y demasiados contextos dispersos.

Figura 1: MyThreatIntel - Plataforma de Threat Intelligence desde

la experiencia en DFIR y Respuesta a Incidentes

Durante una investigación real, ya sea en un entorno SOC, en un servicio de DFIR, en tareas de Threat Hunting o en un proceso de Cyber Threat Intelligence, el analista necesita responder con rapidez a preguntas muy concretas: qué actor está detrás de una campaña, qué infraestructura mantiene activa, si una organización ya ha sido publicada en un portal de ransomware, si la extorsión sigue en negociación, si ya ha habido filtración, qué vulnerabilidades se están publicando, qué indicadores se conocen o qué artefactos de malware estánrelacionados.

Figura 2: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

El problema es que esa información rara vez se encuentra en un único lugar. Normalmente está repartida entre Data Leak Sites, bases de datos de vulnerabilidades, repositorios de IoCs, servicios Onion, mercados de la Darknet, fuentes OSINT, catálogos de malware y repositorios de filtraciones. El resultado es un coste operativo claro: una parte muy importante del tiempo no se dedica a analizar, sino a buscar, ordenar y contextualizar. De esa necesidad nace MyThreatIntel, una plataforma pensada para reducir esa fricción y ayudar a que la inteligencia llegue al analista de una manera más estructurada, más rápida y más útil.

Una plataforma orientada al contexto

MyThreatIntel no se diseñó como un simple agregador de datos ni como un panel más de ciberseguridad. La idea era más ambiciosa: construir una plataforma capaz de obtener información desde fuentes heterogéneas, normalizarla, enriquecerla y ponerla en contexto. Fue precisamente esa necesidad operativa la que nos llevó a Javier Martí Sanz y a mí - Manuel Martínez Casasola -  a desarrollar MyThreatIntel. Tras trabajar en investigaciones forenses, respuesta a incidentes y servicios de inteligencia, la conclusión era clara: los datos existían, pero el esfuerzo necesario para convertirlos en conocimiento útil seguía siendo demasiado alto.

Figura 3: Contactar con Javier Marti Sanz

Actualmente, MyThreatIntel es una herramienta de Secure&IT, desarrollada para reforzar sus capacidades de Cyber Threat Intelligence y servir de apoyo en tareas de monitorización, análisis, investigación y respuesta ante incidentes. La plataforma permite centralizar y relacionar información que, de otro modo, tendría que localizarse y analizarse de forma independiente en múltiples fuentes.

Por eso, el valor de MyThreatIntel no reside únicamente en centralizar información, sino en relacionarla. Una víctima publicada por un grupo de ransomware puede vincularse con el actor responsable, su infraestructura Onion, el estado de la negociación, las filtraciones asociadas, posibles IoCs relacionados y, en determinados escenarios, incluso con las vulnerabilidades o artefactos de malware observados en una campaña.

Ese enfoque convierte la plataforma en algo más que una colección de secciones independientes: la convierte en un entorno de trabajo orientado a la investigación y al contexto.

Ransomware: visibilidad directa del ecosistema de extorsión

Uno de los pilares de la plataforma es la monitorización continua del ecosistema ransomware. MyThreatIntel sigue de forma directa los portales utilizados por los actores para publicar nuevas víctimas, manteniendo un histórico de actividad que permite observar tendencias, distribución geográfica, sectores afectados y volumen por actor.

Figura 4: Dashboard de ransomware con víctimas registradas,

distribución geográfica y actividad por actor.

Esto no solo facilita saber quién está publicando más víctimas en un momento dado, sino también analizar la evolución de los grupos y entender mejor el comportamiento del ecosistema criminal. Tener esa visión agregada, pero también aterrizada en cada incidente, aporta un enorme valor para analistas CTI, equipos CSIRT y servicios de respuesta a incidentes.

Figura 5: Registro de incidentes en crudo, con filtrado

por fechas, países, actores y sectores.

Además, la plataforma permite consultar el “registro en crudo” de incidentes, filtrando por fechas, países, actores o sectores. Ese enfoque combina visualización ejecutiva y detalle técnico, algo especialmente útil cuando se necesita pasar rápidamente de una visión global a un caso concreto.

Negociaciones: seguir la extorsión más allá de la publicación

Si hay una capacidad especialmente diferencial dentro de MyThreatIntel, esa es la monitorización de negociaciones. La mayoría de soluciones se detienen en la publicación de la víctima dentro del Data Leak Site. Sin embargo, desde el punto de vista de la investigación, ese suele ser solo el comienzo de la historia. A partir de ahí empieza una fase crítica: el proceso de extorsión.

MyThreatIntel monitoriza directamente, desde los portales de los propios actores, el estado de esas negociaciones: si siguen activas, si ha habido filtración parcial o completa, si la víctima ha desaparecido del portal o si existen indicios públicos de que el rescate ha sido abonado. Esta capacidad aporta una visibilidad muy poco habitual y permite entender mejor el ciclo completo de una operación de ransomware.

Figura 6: Sección de Negociaciones (Beta), con distribución

por actor, eventos monitorizados y pagos detectados.

Más allá del interés analítico, este seguimiento tiene un valor operativo evidente. Permite estudiar el comportamiento real de los actores, comparar patrones entre grupos y observar cómo evolucionan las extorsiones en el tiempo.

Vulnerabilidades: monitorización continua desde fuentes oficiales

La inteligencia sobre amenazas no se limita a seguir actores o incidentes activos. También requiere una vigilancia constante sobre la exposición técnica del ecosistema. Por ello, MyThreatIntel incorpora una sección de vulnerabilidades alimentada a partir de fuentes oficiales como NIST y CVE.org. 

Figura 7: Dashboard de vulnerabilidades, con severidad, fabricantes y frecuencia de detección.

La plataforma permite consultar CVEs descubiertas, severidad, fabricantes, vectores de ataque y metadatos asociados, facilitando tanto la revisión rápida de nuevas publicaciones como la exportación de resultados para otros flujos de trabajo.

Figura 8: Vista detallada de CVEs individuales con descripción, vector y puntuación CVSS.

 

La utilidad aquí no está solo en mostrar una lista de CVEs, sino en integrarlas dentro de un entorno de investigación más amplio. La vulnerabilidad deja de ser un identificador aislado y pasa a formar parte del contexto que rodea una amenaza o una investigación concreta.

Indicadores de Compromiso: del dato técnico a la utilidad operativa

Los IoCs siguen siendo una pieza esencial en investigación, detección y respuesta. MyThreatIntel incorpora un repositorio de indicadores con clasificación por tipo, criticidad y telemetría, permitiendo realizar búsquedas, filtros y exportación de resultados.

Figura 9: Dashboard de IoCs con volumen total, criticidad y distribución por tipo.

Aquí el objetivo no es solo acumular artefactos, sino facilitar su consumo real por parte del analista. Hashes, dominios, archivos y otros indicadores aparecen organizados de forma que puedan emplearse con rapidez durante una investigación o integrarse en tareas de detección.

Figura 10: Telemetría de indicadores, con fichas detalladas por artefacto.

Este enfoque resulta especialmente útil cuando el volumen de datos es alto y el analista necesita reducir ruido para centrarse en aquello que tiene mayor relevancia operativa.

Darknet & Markets: seguir la infraestructura donde operan los actores

MyThreatIntel también incorpora una capa específica para la vigilancia de servicios Onion y mercados de la Darknet. Este componente permite observar qué servicios continúan activos, cuáles han caído, qué mercados siguen operando y cómo evoluciona su infraestructura con el tiempo.

Figura 11: Vista global de Darknet & Markets, con servicios Onion,

mercados activos y distribución por grupos.

No se trata únicamente de listar URLs. El valor real está en mantener un histórico de disponibilidad, relaciones con actores y capturas o notas asociadas. En entornos donde la infraestructura cambia rápidamente, esa trazabilidad resulta especialmente valiosa.

Figura 12: Detalle de mercados Darknet, mostrando estado operativo y URLs monitorizadas.

De esta forma, la plataforma aporta una visión mucho más estable sobre un ecosistema que, por naturaleza, es altamente volátil.

Figura 13: Detalle de servicios Onion asociados a actores, con enlaces activos y caídos.

Filtraciones y grupos: conocimiento estructurado sobre el adversario

El repositorio de filtraciones añade una perspectiva distinta: la exposición histórica de organizaciones. Los registros pueden buscarse por nombre, fecha o tamaño, lo que ayuda a comprobar si una entidad, dominio o conjunto de datos ya apareció en una filtración conocida. Este componente puede utilizarse tanto en investigaciones de terceros como en análisis de exposición, procesos de ciberinteligencia y respuesta a incidentes. La información deja de estar distribuida entre referencias aisladas y pasa a formar parte de un catálogo consultable desde el mismo entorno.

Figura 14: Repositorio de filtraciones y catálogo histórico.

La sección Grupos funciona como una base de conocimiento sobre actores de amenazas. Incluye descripciones, aliases, infraestructura Onion, capturas y notas, permitiendo contextualizar rápidamente a un grupo sin depender de búsquedas dispersas.

Figura 15 Inteligencia de amenazas: fichas de grupos,

enlaces Onion y documentación asociada.

La relación entre actores, víctimas, portales, notas de rescate e infraestructura es uno de los puntos donde MyThreatIntel deja de comportarse como un agregador y empieza a funcionar como una herramienta de investigación. Al analizar una víctima, el investigador puede acceder al contexto del actor, revisar sus canales e infraestructura y observar su actividad documentada desde una única interfaz.

Malware y artefactos técnicos

El repositorio de malware reúne muestras con sus hashes, nombre, firma, tamaño, tipo y etiquetas técnicas. Esta clasificación permite localizar artefactos por familia o característica y relacionarlos con los indicadores utilizados durante una investigación.

Figura 16: Repositorio de muestras de malware, hashes, firmas y etiquetas.

El apoyo de MITRE ATT&CK aporta contexto sobre técnicas, tácticas y comportamientos, especialmente cuando una muestra forma parte de una cadena de intrusión más amplia. De este modo, el repositorio no actúa únicamente como almacén de archivos, sino como fuente de apoyo para análisis de malware, Threat Hunting y construcción de hipótesis durante una investigación.

Permutaciones DNS para investigar suplantaciones

La consulta DNS amplía la plataforma hacia la detección de typosquatting, phishing e infraestructura sospechosa. A partir de un dominio, el motor genera permutaciones y comprueba su registro utilizando diferentes TLD y palabras clave asociadas a accesos corporativos, identidad, Microsoft 365, VPN, correo, servicios cloud o soporte técnico.

Figura 17: Consulta de permutaciones DNS, TLD, palabras clave y dominios registrados.

El resultado permite distinguir entre dominios generados y registrados, revisar fechas de creación, aplicar filtros y exportar el análisis. Integrar esta capacidad dentro de MyThreatIntel facilita conectar una posible suplantación con el resto del contexto disponible, en lugar de tratarla como una consulta independiente.

Consumo mediante Web y API

La interfaz web está orientada a la investigación manual, pero la inteligencia también debe poder salir de la plataforma. MyThreatIntel dispone de una API con autenticación mediante Bearer Token, respuestas JSON estandarizadas, búsqueda de texto y filtrado por fuentes y categorías. Esto permite consumir vulnerabilidades, IoCs, muestras de malware, víctimas de ransomware, infraestructura Tor, mercados, grupos, negociaciones y filtraciones desde plataformas SIEM, herramientas SOAR, scripts o automatizaciones desarrolladas en PowerShell, Python, JavaScript y otros lenguajes.

MyThreatIntel puede utilizarse directamente desde https://mythreatintel.secureit.es/, donde centraliza toda esta información en una única interfaz. Además, como la plataforma dispone de API, lo que permite integrarla en flujos de trabajo, herramientas SIEM y SOAR, scripts de investigación o procesos de automatización propios. Este punto es importante porque la inteligencia no siempre termina en el panel. En muchos casos, su verdadero valor aparece cuando puede integrarse en otros procesos de seguridad y respuesta.

Conclusión

MyThreatIntel no nace para sustituir fuentes, sino para darles sentido conjunto. En un escenario donde la información está cada vez más fragmentada, el verdadero reto no consiste en recopilar más datos, sino en reducir el tiempo necesario para convertirlos en contexto útil. Ransomware, negociaciones, vulnerabilidades, IoCs, Darknet, filtraciones, grupos, malware y DNS no son piezas aisladas. En una investigación real suelen formar parte de una misma historia. La utilidad de MyThreatIntel está precisamente en ayudar a contar esa historia con menos fricción, más contexto y una mejor capacidad de respuesta.

Saludos,

Autor: Manuel Martínez, founder de The Hackers Lab

Contactar con Manuel Martínez

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. 

Figura 14: non-person identities en ZTA Administration

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. 

Figura 16: Dashboard de Cloudflare One

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.

Figura 18: Añadiendo herramientas al Agente IA

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.

Figura 19:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

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

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.

Un saludo,   

Autor: Juan Luis Cuenca Ramos

Contactar con Juan Luis Cuenca Ramos