Axonius está incorporando agentes de IA a su plataforma SaaS de ciberseguridad sin abandonar el modelo de aislamiento cliente por cliente que sustenta su implementación existente en AWS, según un nuevo caso de estudio del AWS Machine Learning Blog.

La empresa utilizó Amazon Bedrock AgentCore para ejecutar agentes en cientos de entornos de clientes separados. El diseño aborda un problema central para los proveedores de software que añaden funciones agentivas: un agente debe ser útil en muchos inquilinos, a la vez que permanece restringido a los datos, las API, los controles de identidad y los costos operativos del cliente al que sirve.

AWS describe la arquitectura y sus beneficios reportados en una publicación redactada por el propio proveedor. La fuente no ofrece pruebas de rendimiento independientes ni comentarios de clientes de Axonius, por lo que las afirmaciones sobre la escala de despliegue y los resultados operativos deben considerarse como reportadas por AWS.

Axonius mantiene su modelo SaaS basado en silos

Axonius ofrece una plataforma de inteligencia de activos para equipos de seguridad y TI. Según AWS, el servicio concilia información de más de 1.400 sistemas y opera cientos de entornos de cliente aislados. Cada carga de trabajo de cliente se ejecuta en una Amazon Virtual Private Cloud, o Amazon VPC, dedicada, que contiene componentes como balanceadores de carga, bases de datos e infraestructura de cómputo general.

El primer agente de IA descrito en la publicación analiza grandes entornos empresariales, identifica brechas y riesgos, e interpreta millones de puntos de datos procedentes de múltiples integraciones. AWS afirma que la función está pensada para permitir que analistas junior realicen análisis complejos sin que los analistas senior tengan que pasar horas en investigación manual.

En lugar de mover esa carga de trabajo a una arquitectura SaaS compartida, Axonius quería que el agente siguiera su modelo de inquilino existente. Esa decisión dio forma a los requisitos técnicos: un agente que gestiona el entorno de un cliente no debe acceder a los datos de otro cliente, pero aun así debe integrarse con los patrones establecidos de autenticación, despliegue y API del servicio.

Para los desarrolladores de IA, el punto importante es que la multi-tenencia aquí no es solo asignar un identificador de cliente a una solicitud. El agente debe desplegarse, autorizarse, conectarse, supervisarse y facturarse de manera que preserve los límites que ya se esperan de un producto de seguridad.

Tres patrones de despliegue, con diferentes compensaciones

AWS enmarca las decisiones de diseño en torno a tres patrones comunes para despliegues de agentes SaaS: silo, pool y bridge.

En una arquitectura de silo, cada inquilino recibe recursos dedicados. Aplicado a AgentCore Runtime, eso puede significar desplegar un agente dedicado para cada cliente. Esto ofrece un límite de infraestructura claro, pero aumenta el número de recursos que hay que aprovisionar, actualizar, supervisar y retirar.

El modelo de pool utiliza recursos compartidos. Un solo agente puede servir a varios inquilinos, y cada sesión recibe un ID de sesión distinto. AWS dice que AgentCore Runtime proporciona una microVM dedicada para cada sesión, mientras que los controles a nivel de aplicación gestionan la separación entre inquilinos.

Ese enfoque simplifica el despliegue y la incorporación de clientes, pero traslada más responsabilidad a la aplicación. El agente debe interpretar correctamente el contexto del inquilino en cada solicitud y evitar el acceso cruzado entre inquilinos. El comportamiento específico por inquilino también puede requerir lógica condicional adicional en un despliegue compartido.

El modelo bridge combina ambos enfoques. El runtime del agente puede compartirse mientras se aplican controles más estrictos de inquilino en la capa de herramientas. En la arquitectura discutida por AWS, AgentCore Gateway se sitúa entre el agente y las herramientas salientes, permitiendo comprobar las llamadas a herramientas frente a los límites del inquilino antes de su ejecución.

AWS presenta este patrón híbrido como una forma de reducir la sobrecarga de infraestructura manteniendo un punto de control más fuerte para el acceso a los sistemas del cliente. El caso de estudio no revela todos los detalles de implementación en producción, por lo que no es posible, con la evidencia disponible, evaluar cómo Axonius distribuyó cada componente entre recursos compartidos y dedicados.

La identidad y el acceso a herramientas forman parte del límite de aislamiento

Axonius ya contaba con un módulo de autenticación y autorización ejecutándose sobre infraestructura Amazon EC2 específica por inquilino. Su necesidad era añadir agentes sin reemplazar ese flujo de identidad.

AWS describe un diseño en el que los inquilinos se autentican a través de un proveedor de identidad OAuth 2.0, como Amazon Cognito. Los tokens contienen una reclamación específica del inquilino, por ejemplo un identificador de inquilino personalizado. El autorizador JWT integrado en AgentCore Runtime valida el token usando el endpoint de descubrimiento del proveedor de identidad, mientras que el agente lee la reclamación para enrutar las solicitudes al entorno correcto del cliente.

Esta división es significativa. La validación del token establece que una solicitud proviene de un proveedor de identidad aceptado, pero el agente y sus herramientas aún deben aplicar correctamente la reclamación del inquilino. En la práctica, el límite de seguridad depende tanto del mecanismo de autorización de la plataforma como del código que mapea la identidad a las API, almacenes de datos y herramientas.

El mismo principio se aplica a la integración de servicios. AWS dice que el agente asociado a un inquilino debe tener acceso seguro a las API de ese inquilino. La publicación presenta AgentCore Gateway como un posible punto de aplicación para las llamadas salientes a herramientas, creando una capa donde se puede comprobar el contexto del inquilino antes de que una herramienta interactúe con la carga de trabajo del cliente.

Evidencia, control de costos y escala operativa

AWS identifica el seguimiento de costos como uno de los requisitos centrales de Axonius, porque se espera que la invocación del modelo represente gran parte del gasto de un agente. La contabilidad por inquilino puede ayudar a un proveedor SaaS a decidir cómo fijar el precio de una función de IA, establecer límites de uso e identificar clientes o flujos de trabajo con consumo inusualmente alto.

La empresa también necesitaba añadir la carga de trabajo del agente a su proceso existente de entrega continua basado en silos. Ese requisito es fácil de pasar por alto: una arquitectura que funciona en un prototipo puede volverse difícil de operar cuando cada entorno de cliente tiene su propio ciclo de vida de despliegue.

La observabilidad fue otra preocupación declarada. AWS dice que Axonius necesitaba monitorización, alertas y trazado a nivel de flota para un gran número de agentes, con suficiente detalle para investigar fallos. Esas necesidades hacen que las operaciones de agentes sean diferentes del monitoreo de aplicaciones ordinarias. Los equipos deben entender no solo si un servicio está disponible, sino también qué llamadas al modelo, herramientas, sesiones y permisos de inquilino contribuyeron a un resultado.

La evidencia disponible proviene de AWS y no de un auditor independiente ni de una entrevista con un cliente. AWS informa que AgentCore permitió a Axonius desplegar agentes aislados multiinquilino sin construir desde cero una infraestructura personalizada de aislamiento de cómputo, autenticación u observabilidad. Eso es una afirmación del proveedor sobre el papel de la plataforma, no una comparación verificada de forma independiente sobre tiempo de ingeniería, seguridad o costo total.

Qué significa para constructores y compradores empresariales

Para las empresas SaaS, el caso de Axonius destaca una secuencia práctica para añadir agentes: empezar con el modelo de inquilino existente, identificar los límites de datos y herramientas, y luego decidir qué controles pertenecen al runtime, a la aplicación o a una capa de gateway.

La elección también afecta la economía del producto. Los recursos dedicados pueden ofrecer un aislamiento y una personalización más claros, pero los runtimes compartidos pueden simplificar la incorporación y las operaciones. Un diseño bridge puede reducir la duplicación, aunque requiere una aplicación cuidadosa de políticas en cada límite de herramienta. Ninguno de los modelos elimina la necesidad de probar fallos de autorización, reclamaciones de inquilino malformadas, permisos de herramientas excesivos y fugas accidentales de datos.

Los compradores empresariales que evalúan funciones de IA deberían preguntar a los proveedores cómo sigue la identidad del inquilino a una solicitud de agente, si las llamadas a herramientas se autorizan de forma independiente, cómo se atribuye el uso del modelo y cómo se separan los trazos para la respuesta a incidentes. Estas preguntas son especialmente importantes para el software de seguridad, donde un agente puede procesar información sensible de inventario, configuración y vulnerabilidades.

La implicación más amplia para el mercado es que las plataformas de agentes compiten tanto por primitivas operativas como por acceso a modelos. El aislamiento en runtime, la integración de identidad, los gateways, la automatización del despliegue y la observabilidad pueden determinar si un agente pasa de demostración a un producto que un proveedor SaaS puede soportar en cientos de entornos.

Qué observar a continuación

Las próximas señales serán detalles concretos de producción de Axonius o AWS: si la empresa utiliza un runtime compartido, runtimes dedicados o un esquema bridge en producción; cómo se implementa la atribución de costos a nivel de inquilino; y qué controles se aplican en el código de la aplicación frente a AgentCore Gateway.

Los desarrolladores también deberían vigilar evidencia independiente sobre la sobrecarga de despliegue, la gestión de incidentes y las pruebas de aislamiento. Más detalles sobre la selección de modelos, el rendimiento, la latencia y el costo de ejecutar el primer agente de Axonius facilitarían juzgar la arquitectura más allá de sus objetivos de diseño declarados.

Perspectiva de Creati.ai

El ejemplo de Axonius trata menos de añadir un chatbot a un producto de seguridad y más de adaptar la ejecución de agentes a un plano de control SaaS ya existente. El trabajo difícil consiste en vincular identidad, acceso a datos, herramientas, facturación, lanzamientos y depuración al inquilino que posee la solicitud.

El caso de estudio de AWS muestra por qué la infraestructura gestionada de agentes resulta atractiva para los ISV, pero no demuestra que una abstracción de plataforma elimine el riesgo de seguridad a nivel de aplicación. La lección más fuerte para los desarrolladores es tratar el enrutamiento de inquilinos y la autorización de herramientas como controles críticos del producto, y luego validar las afirmaciones del proveedor con datos de despliegue y fallos antes de comprometerse con una arquitectura a gran escala.