La plataforma CNAPP de OX Security reúne la postura cloud y la defensa en tiempo de ejecución de agentes de IA
OX Security lanzó el 16 de septiembre una plataforma CNAPP que combina controles cloud consolidados con monitorización en tiempo real de agentes de IA. La plataforma CNAPP de OX Security, denominada OX Cloud, aborda una brecha de seguridad creada cuando el software autónomo adquiere identidades, permisos y acceso a herramientas empresariales.
El lanzamiento no es simplemente otra ampliación de una lista de funciones de seguridad cloud. OX sostiene que los equipos de seguridad necesitan un único grafo que conecte código, configuración cloud, identidades, datos, prompts y acciones de agentes en vivo. Esta afirmación desafía tanto a los productos CNAPP convencionales como a las herramientas independientes de seguridad para IA.
Palo Alto Networks y otros grandes proveedores de seguridad ya ofrecen protección en tiempo de ejecución, gestión de la postura de IA y controles para agentes. Por tanto, OX debe demostrar que su contexto desde el prompt hasta el tiempo de ejecución genera mejores decisiones, y no solo un panel más amplio.
La cuestión central es si combinar estas señales ayuda a los defensores a aislar riesgos alcanzables y comportamientos inseguros de los agentes. Si es así, OX Cloud podría reducir la brecha entre descubrir una debilidad cloud y comprender cómo un sistema autónomo podría explotarla.
La plataforma CNAPP de OX Security amplía la visibilidad a la actividad de agentes en vivo
OX Cloud añade el comportamiento de los agentes a las señales de infraestructura, identidad, vulnerabilidades y datos que ya recopilan las plataformas de seguridad cloud.
Una plataforma de protección de aplicaciones nativas de la nube, o CNAPP, combina varias funciones de seguridad cloud dentro de un mismo sistema. Estas funciones suelen incluir monitorización de configuración, protección de cargas de trabajo, análisis de permisos, gestión de vulnerabilidades y mapeo de rutas de ataque.
OX Cloud incluye gestión de la postura de seguridad cloud, gestión de la postura de Kubernetes, gestión de la postura de seguridad de datos, detección de vulnerabilidades en tiempo de ejecución, inventario cloud y análisis de rutas de ataque basado en grafos. La empresa también añade AI Detection and Response, que abrevia como AIDR.
La diferencia radica en lo que OX quiere que la plataforma observe. Las herramientas de postura convencionales examinan recursos como buckets de almacenamiento, contenedores, identidades, rutas de red y políticas de acceso. OX Cloud también busca identificar agentes, modelos, prompts y servidores de Model Context Protocol que operan dentro de ese entorno.
MCP es una interfaz estándar que permite a los sistemas de IA conectarse con herramientas y datos externos. Un servidor MCP podría exponer una base de datos, un sistema de archivos, un servicio de tickets, un repositorio de código o una API interna a un agente.
Esa conexión aporta más utilidad a un agente, pero también convierte la salida del modelo en acciones. Un agente manipulado podría recuperar registros restringidos, invocar una herramienta no aprobada o utilizar una credencial válida fuera de su flujo de trabajo previsto.
OX afirma que su plataforma conecta estas acciones con el contexto cloud circundante. Según el anuncio de OX Cloud de la empresa, el producto puede inventariar cargas de trabajo, identidades, almacenes de datos, clústeres de Kubernetes y agentes de IA activos.
La plataforma utiliza después análisis de alcanzabilidad para priorizar los hallazgos. La alcanzabilidad determina si un componente expuesto, un paquete vulnerable o un permiso excesivo puede conectarse realmente a un recurso valioso o a una ruta de ejecución.
Este enfoque importa porque los escáneres cloud pueden generar largas listas de hallazgos técnicamente válidos. Un paquete vulnerable dentro de una carga de trabajo aislada no presenta el mismo riesgo inmediato que ese paquete dentro de un servicio expuesto a internet con acceso a registros de clientes.
OX aplica esa lógica a los agentes. Un prompt cuestionable o una llamada inusual a una herramienta adquieren mayor importancia cuando el agente responsable puede acceder a datos de producción, API administrativas o sistemas de despliegue.
La empresa también afirma que OX Cloud puede asociar la actividad en tiempo de ejecución con el prompt o el código que la inició. Esa conexión podría ayudar a los investigadores a reconstruir por qué un agente realizó una acción, en lugar de limitarse a registrar que ocurrió.
Estas siguen siendo afirmaciones del proveedor. OX ha descrito capacidades y arquitectura de producto, pero no ha publicado tasas comparativas de detección, mediciones de falsos positivos, sobrecarga de despliegue ni evaluaciones independientes para este lanzamiento.
Esa falta de evidencia no hace que el producto sea irrelevante. Define lo que los compradores empresariales deben validar antes de tratar la nueva plataforma como un plano de control consolidado.
Por qué los agentes de IA presionan a la seguridad cloud tradicional
Los agentes condensan varios problemas de seguridad conocidos en una identidad dinámica que puede razonar, elegir herramientas e iniciar cambios.
Una carga de trabajo tradicional suele seguir código que los ingenieros pueden revisar antes del despliegue. Sus permisos aún pueden ser excesivos y sus dependencias aún pueden contener vulnerabilidades. Sin embargo, la ruta de ejecución esperada es relativamente estable.
Un agente se comporta de forma diferente. Interpreta instrucciones, recupera contexto, selecciona herramientas y construye una secuencia de acciones en tiempo de ejecución. Pequeños cambios en los prompts, los documentos recuperados, las versiones del modelo o las descripciones de las herramientas pueden alterar esa secuencia.
Esta variabilidad no significa que el comportamiento de los agentes sea incognoscible. Significa que los defensores necesitan telemetría tanto sobre la ruta de decisión como sobre las llamadas al sistema resultantes.
La identidad es una parte esencial de ese problema. Un agente que actúa mediante una cuenta de servicio compartida puede dificultar la interpretación de los registros. Los investigadores pueden ver una consulta a una base de datos o un cambio de archivo sin saber qué agente lo inició, por qué actuó o quién autorizó el flujo de trabajo.
La guía de mínimo privilegio de Microsoft recomienda tratar cada agente como un principal distinto. Cada agente debería tener una identidad gestionada, un propietario explícito, roles con alcance limitado y un manifiesto de herramientas aprobado.
Este modelo crea un límite medible. Los equipos pueden determinar qué herramientas debe invocar un agente, a qué recursos puede acceder y si su actividad en tiempo de ejecución se mantiene dentro de su propósito asignado.
El problema se vuelve más grave cuando los servidores MCP heredan credenciales amplias. MCP admite mecanismos de autorización, incluido OAuth, pero el protocolo no aplica automáticamente una política segura en todos los despliegues.
Microsoft informó que el 15 por ciento de los servidores MCP remotos observados mediante señales de Defender for Cloud permitían acceso sin autenticar a datos sensibles o capacidades operativas. Sus hallazgos sobre exposición de MCP incluían conexiones a sistemas de tickets, repositorios privados y herramientas de recursos humanos.
Esa cifra no describe todos los despliegues de MCP. Sí demuestra que la conectividad de los agentes puede exponer sistemas empresariales reales cuando la autenticación y los límites de ejecución están mal configurados.
Un escaneo de postura podría identificar el servidor expuesto. Un producto de identidad podría encontrar su credencial. Una herramienta de tiempo de ejecución podría registrar una llamada sospechosa. OX apuesta a que un grafo compartido puede conectar los tres elementos antes de que un analista reconstruya manualmente la cadena.
Este es el argumento más sólido para combinar datos CNAPP con defensa en tiempo de ejecución de agentes de IA. La amenaza no es por completo un problema de aplicaciones ni por completo un problema cloud.
Pensemos en un agente encargado de resolver solicitudes de soporte. Puede leer tickets, buscar documentación interna y actualizar registros de clientes. Un prompt indirecto oculto en un ticket podría indicarle que recupere registros no relacionados o envíe datos a un endpoint externo.
Un filtro de prompts podría señalar la instrucción. Sin embargo, su gravedad depende de la identidad que utiliza el agente, de las herramientas que puede invocar y de los registros a los que esas herramientas pueden acceder.
A la inversa, una llamada API inusual no siempre indica un ataque. El agente podría estar completando una tarea legítima tras encontrarse con una solicitud poco común. Los defensores necesitan suficiente contexto para distinguir el comportamiento inesperado del comportamiento no autorizado.
OX Cloud está diseñado en torno a esa distinción. Su promesa no es simplemente detectar prompts extraños. Es conectar el comportamiento en vivo con activos alcanzables, permisos efectivos y la ruta de software de origen.
OX Cloud convierte la alcanzabilidad en su principal diferenciador
El mecanismo central de la plataforma es la priorización vinculada a evidencias, donde el comportamiento en tiempo de ejecución y las rutas de ataque determinan qué hallazgos merecen atención.
Los equipos de seguridad cloud ya tienen dificultades con el volumen de alertas. Los escáneres de postura detectan configuraciones incorrectas, las herramientas de vulnerabilidades enumeran paquetes, los sistemas de identidad identifican permisos excesivos y las herramientas de datos clasifican almacenes sensibles.
Añadir agentes puede crear otro inventario sin resolver esa fragmentación. Un equipo de seguridad podría saber que existe un agente, utiliza un modelo concreto y se conecta a varias herramientas. Esos hechos todavía no muestran si su comportamiento crea una ruta explotable.
OX describe un flujo de trabajo de cuatro fases: identificar, priorizar, investigar y gobernar. Las fases utilizan los mismos datos contextuales en lugar de funcionar como módulos de producto desconectados.
La identificación abarca cargas de trabajo, identidades, agentes, almacenes de datos y activos cloud. OX afirma que esto incluye recursos descubiertos a partir de la actividad observada, no solo recursos declarados en archivos de configuración.
La priorización aplica la alcanzabilidad a vulnerabilidades, permisos, configuraciones incorrectas y exposición de la cadena de suministro. Los hallazgos que no pueden conectarse a una carga de trabajo activa o a un activo valioso reciben menor urgencia.
La investigación utiliza un grafo cloud para reconstruir las relaciones que rodean un evento. Un analista debería poder ver qué identidad actuó, qué recurso tocó y qué sistemas adicionales eran alcanzables.
La gobernanza aplica restricciones a la actividad de los agentes y al uso de IA. Aquí es donde las funciones AIDR y de superficie de ataque agéntica de OX se convierten en algo más que características de descubrimiento.
El mecanismo parece coherente, pero su calidad depende de la fidelidad de los datos. OX debe descubrir activos de forma fiable, interpretar permisos, rastrear llamadas de agentes y conservar suficiente contexto para la investigación.
Las brechas de cobertura pueden generar una falsa sensación de seguridad. Una llamada a herramienta no observada, una credencial no gestionada, una ruta de tráfico cifrada o un framework de agentes no compatible podrían romper la cadena que conecta el prompt con el resultado.
La correlación de datos también puede producir conclusiones ambiguas. Que un prompt aparezca poco antes de una llamada API no demuestra automáticamente que haya causado la llamada. Los flujos de trabajo de larga duración, los agentes paralelos, los reintentos y las subtareas delegadas complican la atribución.
Por tanto, OX debe distinguir la correlación de la causalidad dentro de su interfaz. Los analistas necesitan marcas de tiempo, cadenas de invocación, registros de identidad, decisiones de políticas y trazas de aplicaciones que respalden la relación propuesta.
La arquitectura de despliegue también importa. La inspección en tiempo de ejecución puede realizarse mediante interceptación de red, sensores de cargas de trabajo, bibliotecas de aplicaciones, gateways de API, registros cloud o integraciones con frameworks de agentes.
Cada método ofrece una visibilidad distinta. Los controles de red pueden observar destinos y cargas útiles, pero no el razonamiento interno. La instrumentación de frameworks puede capturar la selección de herramientas, pero proporcionar una cobertura incompleta en aplicaciones personalizadas.
OX afirma que la plataforma AINAPP más amplia conecta las fases de prompt, código, compilación, despliegue y tiempo de ejecución. AINAPP es el término de la empresa para una plataforma de protección de aplicaciones nativas de IA.
El concepto otorga a OX una posición potencialmente útil. Sus productos de seguridad de aplicaciones ya examinan el código fuente y las cadenas de suministro de software. OX Cloud amplía esa propuesta hacia la infraestructura desplegada y la actividad de agentes en tiempo real.
Sin embargo, los compradores deberían preguntarse cómo funciona la conexión con código y agentes que no se gestionan ya mediante productos de OX. Una plataforma unificada ofrece un valor limitado si el contexto más enriquecido solo aparece dentro de una cadena de herramientas estrechamente controlada.
La prueba práctica es un incidente real. Un equipo de seguridad debería introducir una descripción de herramienta sospechosa, activar un intento de acceso no autorizado e inspeccionar si OX reconstruye la ruta completa.
Ese ejercicio debería mostrar el contenido iniciador, la identidad del agente, la herramienta seleccionada, los parámetros, el destino, el permiso efectivo, los datos afectados y el resultado de la aplicación de políticas. Cualquier cosa menos que eso obliga a los analistas a ensamblar evidencias entre distintos sistemas.
OX Security se enfrenta a plataformas CNAPP y de seguridad de IA consolidadas
OX compite contra la consolidación de plataformas liderada por proveedores más grandes, no contra escáneres estáticos de nube que ignoraban por completo la IA.
El mercado ya ha avanzado hacia una cobertura de todo el ciclo de vida. Los principales proveedores combinan ahora descubrimiento de IA, análisis de postura, red teaming, inspección en tiempo de ejecución, controles de identidad y aplicación de políticas.
Palo Alto Networks presenta Prisma AIRS como una plataforma que cubre aplicaciones de IA, modelos, datos y agentes. Su documentación de Prisma AIRS describe firewalls de tiempo de ejecución, APIs, red teaming, seguridad de modelos, gestión de postura y protección de agentes.
Palo Alto también integra el descubrimiento de IA con Cortex Cloud. Esa conexión puede identificar modelos, endpoints, conjuntos de datos, agentes y relaciones de dependencia en Amazon Web Services, Microsoft Azure y Google Cloud.
Esto hace que la competencia principal sea más amplia que OX frente a un CNAPP convencional. Se trata de la integración centrada en el contexto de OX frente a plataformas de seguridad ya establecidas que ensamblan controles similares en sus carteras de productos existentes.
Los proveedores consolidados aportan bases instaladas, telemetría de nube, inteligencia de amenazas, integraciones de identidad y relaciones de compra consolidadas. Los compradores podrían preferir ampliar un contrato existente en lugar de incorporar otra plataforma de seguridad.
OX puede responder con enfoque. Un proveedor más pequeño puede diseñar en torno a flujos de trabajo de agentes sin tener que preservar cada supuesto arquitectónico de una suite de productos más antigua.
Su narrativa de código a tiempo de ejecución también puede atraer a los equipos de seguridad de aplicaciones. Estos equipos quieren saber si un hallazgo introducido durante el desarrollo sigue siendo alcanzable tras el despliegue y si un agente puede activar la ruta vulnerable.
Esa conexión podría reducir las discrepancias entre desarrolladores y analistas de seguridad. Los desarrolladores suelen recibir hallazgos de escáneres sin evidencia de que el código afectado esté expuesto. El contexto de tiempo de ejecución puede establecer qué problemas tienen relevancia operativa inmediata.
Sin embargo, los grandes proveedores están planteando el mismo argumento de consolidación. Palo Alto informó aproximadamente 120 millones de dólares en ingresos recurrentes anuales para Prisma AIRS tras un año de disponibilidad general.
La empresa también informó de más de 800 clientes de Prisma AIRS en su presentación del cuarto trimestre fiscal de 2026. Estas cifras emplean las propias definiciones de Palo Alto para la asignación de ingresos y las cotizaciones reservadas, pero indican una demanda comercial significativa.
Esta presión competitiva obliga a OX a demostrar ventajas específicas. Una lista más larga de funciones no bastará, porque las plataformas de nube ya cubren muchas de las mismas categorías.
OX puede diferenciarse mediante investigaciones más rápidas, priorización más clara, soporte más amplio para frameworks o una atribución más clara desde el prompt hasta el tiempo de ejecución. También podría competir mediante flexibilidad de despliegue y menor complejidad operativa.
Los clientes deberían comparar flujos de trabajo, no etiquetas de categorías. Ambos productos pueden afirmar que ofrecen descubrimiento de agentes, defensa en tiempo de ejecución y gestión de postura, mientras recopilan telemetría diferente o aplican políticas en puntos distintos.
Una plataforma podría bloquear prompts maliciosos antes del procesamiento del modelo. Otra podría interceptar llamadas a herramientas, restringir permisos de identidad o aislar la carga de trabajo tras detectar actividad sospechosa.
Estos controles son complementarios, pero su ubicación afecta a la latencia, la cobertura y los modos de fallo. Un producto situado fuera de la ruta de ejecución puede observar con mayor seguridad, aunque carezca de autoridad de bloqueo inmediato.
Un control en línea puede detener una acción, pero también pasa a formar parte de la ruta de disponibilidad de la aplicación. Los compradores deben entender qué ocurre cuando el servicio de seguridad se vuelve lento, pierde conectividad o no puede clasificar una solicitud.
OX no ha proporcionado públicamente suficiente evidencia específica del lanzamiento para resolver estas comparaciones. Su reto inmediato es convertir una arquitectura creíble en resultados repetibles para los clientes.
La defensa en tiempo de ejecución no puede sustituir el diseño de agentes y el control de acceso
Ningún CNAPP puede compensar agentes que comparten identidades, reciben permisos excesivos o ejecutan acciones de gran impacto sin autorización independiente.
La supervisión en tiempo de ejecución suele recibir atención porque puede detectar comportamientos que las revisiones estáticas no detectan. Esa fortaleza también puede animar a los equipos a tratar la observación como sustituto de una arquitectura más segura.
Un agente no debería obtener acceso amplio solo porque un producto de supervisión registra sus acciones. Registrar una transferencia de datos no autorizada no deshace la transferencia.
La taxonomía de riesgos agénticos de OWASP incluye uso indebido de herramientas, abuso de identidad y privilegios, envenenamiento de memoria, fallos en cascada y comportamiento de agentes maliciosos. Estos riesgos atraviesan los límites entre modelos, aplicaciones, identidad e infraestructura.
Los defensores deberían empezar con identidades de agente diferenciadas. Las credenciales compartidas dificultan atribuir la responsabilidad y revocar el acceso. Cada agente de producción necesita un propietario identificado, una finalidad documentada y un conjunto limitado de recursos permitidos.
El acceso a herramientas también debería ser explícito. Un agente diseñado para resumir tickets de soporte no debería heredar acceso administrativo a la plataforma de tickets. Debería recibir únicamente las operaciones de lectura necesarias para esa tarea.
El acceso de escritura merece una decisión independiente. Si el flujo de trabajo se amplía para modificar registros, el equipo debería crear nuevos permisos y reglas de aprobación en lugar de ampliar un rol existente sin revisión.
Las acciones de gran impacto necesitan una aplicación determinista. Eliminar datos, modificar infraestructura de producción, emitir pagos o publicar contenido externo no debería depender únicamente de la interpretación de un modelo sobre instrucciones en lenguaje natural.
La aprobación humana sigue siendo adecuada para acciones con consecuencias financieras, operativas o legales importantes. La aprobación automatizada puede funcionar para tareas de menor impacto cuando las condiciones de la política son estrictas y se aplican de forma independiente.
La memoria introduce otro riesgo. Un agente puede almacenar historial de conversaciones, preferencias, hechos recuperados o planes intermedios entre sesiones. El contenido malicioso puede persistir en esa memoria e influir en decisiones posteriores.
Un producto de tiempo de ejecución debería exponer las lecturas y escrituras de memoria cuando sea posible. También debería mostrar si un agente utilizó contenido recuperado al seleccionar una herramienta o construir parámetros.
Sin embargo, el acceso a la memoria puede ocurrir dentro de un framework o servicio de modelos que proporciona telemetría limitada. Los compradores deberían comprobar si OX Cloud captura estas interacciones en toda su pila de despliegue real.
Los falsos positivos presentan un desafío independiente. Los flujos de trabajo de agentes producen naturalmente secuencias de acciones inusuales porque se adaptan a las solicitudes de los usuarios. Una detección simple de anomalías puede marcar variaciones legítimas y saturar a los analistas.
OX afirma que la alcanzabilidad ayuda a reducir ese ruido. La afirmación es plausible, pero la alcanzabilidad no prueba intención maliciosa. Una ruta alcanzable puede respaldar un flujo de trabajo legítimo, mientras que un fallo de software no alcanzable puede volverse relevante después de un cambio de configuración.
Las empresas deberían medir la precisión durante un despliegue controlado. Las métricas útiles incluyen incidentes confirmados, falsos positivos, tiempo de investigación, tareas legítimas bloqueadas, flujos de trabajo no compatibles y brechas de telemetría.
También deberían medir el impacto en el rendimiento. La inspección en tiempo de ejecución puede añadir latencia cuando evalúa prompts, llamadas a herramientas, flujos de datos o políticas de identidad de forma síncrona.
OX no ha publicado cifras generales de latencia o sobrecarga para OX Cloud. Los resultados probablemente dependerán del método de despliegue, el volumen de tráfico, la complejidad de las políticas y la cantidad de contexto recopilado.
Otra incertidumbre es la coherencia de la aplicación. Una organización puede operar agentes creados con varios frameworks en múltiples nubes y plataformas SaaS. Una política debe sobrevivir a esas diferencias arquitectónicas.
Un panel que descubre todos los agentes pero gobierna solo un subconjunto crea una protección desigual. Los equipos de seguridad necesitan una matriz de compatibilidad clara y evidencia de que las rutas no compatibles siguen siendo visibles.
La conclusión adecuada no es que la defensa en tiempo de ejecución carezca de valor. Es que la supervisión en tiempo de ejecución funciona mejor como una capa dentro de un sistema de control más amplio.
El diseño seguro de agentes comienza con autoridad limitada. La defensa en tiempo de ejecución verifica entonces si el comportamiento se mantiene dentro de esos límites y ayuda a los investigadores a comprender las desviaciones.
Tres señales mostrarán si OX Cloud cumple
La próxima prueba es la evidencia operativa, incluida la validación de clientes, una reducción medible del ruido y una aplicación amplia en pilas reales de agentes.
La primera señal es evidencia independiente de clientes. OX debería mostrar cómo funciona la plataforma en entornos de producción que contienen múltiples nubes, frameworks de agentes, proveedores de identidad y servidores MCP.
Los estudios de caso útiles cuantificarían cuántos agentes e identidades no humanas se descubrieron. También deberían informar qué rutas de riesgo fueron confirmadas, cuántas alertas se suprimieron y cómo cambió el tiempo de investigación.
La segunda señal es el rendimiento comparativo. Los compradores necesitan pruebas de detección y aplicación que cubran inyección de prompts, descripciones de herramientas envenenadas, permisos excesivos, secuencias inusuales de API e intentos de exfiltración de datos.
Estas pruebas deberían incluir variaciones benignas para medir los falsos positivos. Un sistema que bloquea toda acción poco común aporta poco valor a los flujos de trabajo adaptativos.
OX también debería revelar dónde se aplica el control. Los clientes necesitan saber si los controles operan dentro de las cargas de trabajo, mediante inspección de red, dentro de frameworks de agentes o a través de APIs de nube.
La tercera señal es la respuesta competitiva. Palo Alto Networks, Microsoft y otros proveedores de seguridad están integrando identidad de agentes, postura, inspección en tiempo de ejecución y gobernanza en plataformas más amplias.
Si esos proveedores conectan código, prompts, identidades, recursos de nube y llamadas a herramientas con una precisión similar, la distinción arquitectónica de OX se reducirá. Entonces OX competirá en calidad de despliegue, velocidad de investigación, cobertura y servicio al cliente.
Si los proveedores consolidados mantienen esos controles fragmentados, OX puede argumentar que un único grafo contextual genera decisiones más rápidas y defendibles. Las evaluaciones de los clientes determinarán qué resultado refleja la realidad de producción.
Los responsables de seguridad que evalúen la plataforma CNAPP de OX Security deberían comenzar con un flujo de trabajo de agente acotado. Pueden mapear su identidad, herramientas aprobadas, datos alcanzables, acciones esperadas y reglas de escalamiento antes de habilitar una cobertura más amplia.
La evaluación debería introducir después fallos controlados. Deben probar un servidor MCP expuesto, una identidad con privilegios excesivos, un documento envenenado, una llamada a herramienta no autorizada y una carga de trabajo vulnerable y alcanzable.
La plataforma debería mostrar no solo que ocurrió algo inusual, sino por qué era importante. Debería conectar la instrucción de origen con la identidad actuante, la herramienta seleccionada, el activo alcanzable, la decisión de política y el resultado final.
Este estándar se aplica más allá de OX. Los productos de seguridad para agentes deben convertir una telemetría compleja en una aplicación fiable y en investigaciones explicables.
El lanzamiento refleja un cambio real en la seguridad en la nube. Los agentes están pasando a ser participantes activos de la nube, en lugar de otra clase de activos que inventariar.
OX Cloud responde incorporando el comportamiento en tiempo de ejecución al mismo grafo que el código, las cargas de trabajo, las identidades y los datos. El diseño es creíble, pero las afirmaciones más contundentes todavía requieren validación independiente.
Los equipos que evalúen OX Cloud deberían solicitar una prueba con condiciones similares a producción, no una demostración de funciones cuidadosamente pulida. ¿Puede la plataforma identificar a cada agente, distinguir las variaciones legítimas del uso indebido y reconstruir una cadena de acciones completa? ¿Puede aplicar límites sin retrasar el trabajo habitual ni generar otra cola de alertas? Esos resultados determinarán si la plataforma CNAPP de OX Security se convierte en un plano de control significativo o en otra capa que los equipos de seguridad deban conciliar.
