A Axonius está adicionando agentes de IA à sua plataforma SaaS de cibersegurança sem abandonar o modelo de isolamento cliente a cliente que sustenta sua implantação existente na AWS, segundo um novo estudo de caso do AWS Machine Learning Blog.

A empresa usou o Amazon Bedrock AgentCore para executar agentes em centenas de ambientes de clientes separados. O design aborda um problema central para fornecedores de software que adicionam recursos agentivos: um agente precisa ser útil em vários inquilinos, permanecendo restrito aos dados, APIs, controles de identidade e custos operacionais do cliente que atende.

A AWS descreve a arquitetura e seus benefícios relatados em uma publicação escrita pelo próprio fornecedor. A fonte não fornece testes de desempenho independentes nem comentários de clientes da Axonius, portanto as alegações sobre escala de implantação e resultados operacionais devem ser tratadas como relatadas pela AWS.

A Axonius mantém seu modelo SaaS baseado em silos

A Axonius oferece uma plataforma de inteligência de ativos para equipes de segurança e TI. Segundo a AWS, o serviço consolida informações de mais de 1.400 sistemas e opera centenas de ambientes de clientes isolados. Cada carga de trabalho de cliente roda em uma Amazon Virtual Private Cloud, ou Amazon VPC, dedicada, contendo componentes como balanceadores de carga, bancos de dados e infraestrutura de computação geral.

O primeiro agente de IA descrito no post analisa grandes ambientes corporativos, identifica lacunas e riscos e interpreta milhões de pontos de dados vindos de múltiplas integrações. A AWS diz que o recurso foi criado para permitir que analistas juniores realizem análises complexas sem que analistas seniores precisem passar horas em investigação manual.

Em vez de mover essa carga de trabalho para uma arquitetura SaaS compartilhada, a Axonius queria que o agente seguisse seu modelo de inquilino existente. Essa decisão moldou os requisitos técnicos: um agente que lida com o ambiente de um cliente não pode acessar os dados de outro cliente, ao mesmo tempo em que precisa se integrar aos padrões já estabelecidos de autenticação, implantação e API do serviço.

Para quem constrói IA, o ponto importante é que a multi-inquilinidade aqui não é apenas atribuir um identificador de cliente a uma solicitação. O agente precisa ser implantado, autorizado, conectado, monitorado e cobrado de forma que preserve os limites já esperados de um produto de segurança.

Três padrões de implantação, com diferentes trade-offs

A AWS enquadra as escolhas de design em torno de três padrões comuns para implantações de agentes SaaS: silo, pool e bridge.

Em uma arquitetura silo, cada inquilino recebe recursos dedicados. Aplicado ao AgentCore Runtime, isso pode significar implantar um agente dedicado para cada cliente. Isso oferece uma fronteira de infraestrutura clara, mas aumenta o número de recursos a provisionar, atualizar, monitorar e desativar.

O modelo pool usa recursos compartilhados. Um único agente pode atender vários inquilinos, com cada sessão recebendo um ID de sessão distinto. A AWS diz que o AgentCore Runtime fornece uma microVM dedicada para cada sessão, enquanto controles no nível da aplicação cuidam da separação entre inquilinos.

Essa abordagem simplifica a implantação e a integração de clientes, mas coloca mais responsabilidade sobre a aplicação. O agente precisa interpretar corretamente o contexto do inquilino em cada solicitação e impedir acesso entre inquilinos. O comportamento específico de um inquilino também pode exigir lógica condicional adicional em uma implantação compartilhada.

O modelo bridge combina as duas abordagens. Um runtime de agente pode ser compartilhado enquanto controles mais rígidos de inquilino são aplicados na camada de ferramentas. Na arquitetura discutida pela AWS, o AgentCore Gateway fica entre o agente e as ferramentas de saída, permitindo que chamadas de ferramenta sejam verificadas em relação às fronteiras do inquilino antes da execução.

A AWS apresenta esse padrão híbrido como uma forma de reduzir a sobrecarga de infraestrutura e, ao mesmo tempo, manter um ponto de controle mais forte para acesso aos sistemas do cliente. O estudo de caso não divulga todos os detalhes de implementação em produção, então não é possível, com as evidências disponíveis, avaliar como a Axonius distribuiu cada componente entre recursos compartilhados e dedicados.

Identidade e acesso a ferramentas fazem parte da fronteira de isolamento

A Axonius já tinha um módulo de autenticação e autorização rodando em infraestrutura Amazon EC2 específica por inquilino. Sua necessidade era adicionar agentes sem substituir esse fluxo de identidade.

A AWS descreve um design em que os inquilinos autenticam-se por meio de um provedor de identidade OAuth 2.0, como o Amazon Cognito. Os tokens contêm uma reivindicação específica do inquilino, por exemplo um identificador de inquilino personalizado. O autorizador JWT embutido no AgentCore Runtime valida o token usando o endpoint de descoberta do provedor de identidade, enquanto o agente lê a reivindicação para rotear solicitações ao ambiente correto do cliente.

Essa divisão é significativa. A validação do token estabelece que uma solicitação veio de um provedor de identidade aceito, mas o agente e suas ferramentas ainda precisam aplicar corretamente a reivindicação do inquilino. Na prática, a fronteira de segurança depende tanto do mecanismo de autorização da plataforma quanto do código que mapeia identidade para APIs, armazenamentos de dados e ferramentas.

O mesmo princípio se aplica à integração de serviços. A AWS diz que o agente associado a um inquilino deve ter acesso seguro às APIs desse inquilino. O post apresenta o AgentCore Gateway como um possível ponto de imposição para chamadas de ferramentas de saída, criando uma camada em que o contexto do inquilino pode ser verificado antes que uma ferramenta interaja com a carga de trabalho do cliente.

Evidência, controle de custos e escala operacional

A AWS identifica o rastreamento de custos como um dos requisitos centrais da Axonius, porque a invocação do modelo deve responder por grande parte da despesa de um agente. A contabilização por inquilino pode ajudar um provedor SaaS a decidir como precificar um recurso de IA, definir limites de uso e identificar clientes ou fluxos de trabalho com consumo incomumente alto.

A empresa também precisava adicionar a carga de trabalho do agente ao seu processo existente de entrega contínua baseado em silos. Esse requisito é fácil de passar despercebido: uma arquitetura que funciona em um protótipo pode se tornar difícil de operar quando cada ambiente de cliente tem seu próprio ciclo de vida de implantação.

A observabilidade foi outra preocupação declarada. A AWS diz que a Axonius precisava de monitoramento, alarmes e tracing em nível de frota para um grande número de agentes, com detalhes suficientes para investigar falhas. Essas necessidades tornam as operações de agentes diferentes do monitoramento de aplicações comuns. As equipes precisam entender não apenas se um serviço está disponível, mas também quais chamadas de modelo, ferramentas, sessões e permissões de inquilino contribuíram para um resultado.

As evidências disponíveis vêm da AWS, e não de um auditor independente ou de uma entrevista com cliente. A AWS relata que o AgentCore permitiu à Axonius implantar agentes isolados e multi-inquilino sem construir do zero uma infraestrutura personalizada de isolamento de computação, autenticação ou observabilidade. Isso é uma alegação do fornecedor sobre o papel da plataforma, não uma comparação verificada de forma independente sobre tempo de engenharia, segurança ou custo total.

O que isso significa para construtores e compradores corporativos

Para empresas SaaS, o caso da Axonius destaca uma sequência prática para adicionar agentes: começar com o modelo de inquilino existente, identificar as fronteiras de dados e ferramentas e então decidir quais controles pertencem ao runtime, à aplicação ou a uma camada de gateway.

A escolha também afeta a economia do produto. Recursos dedicados podem oferecer isolamento e personalização mais claros, mas runtimes compartilhados podem simplificar o onboarding e as operações. Um design bridge pode reduzir duplicação, mas exige aplicação cuidadosa de políticas em cada fronteira de ferramenta. Nenhum dos modelos elimina a necessidade de testar falhas de autorização, reivindicações de inquilino malformadas, permissões excessivas de ferramentas e vazamentos acidentais de dados.

Compradores corporativos que avaliam recursos de IA devem perguntar aos fornecedores como a identidade do inquilino acompanha uma solicitação de agente, se as chamadas de ferramenta são autorizadas de forma independente, como o uso do modelo é atribuído e como os traces são separados para resposta a incidentes. Essas perguntas são especialmente importantes para software de segurança, onde um agente pode processar informações sensíveis de inventário, configuração e vulnerabilidades.

A implicação mais ampla para o mercado é que plataformas de agentes competem tanto em primitivas operacionais quanto em acesso a modelos. Isolamento de runtime, integração de identidade, gateways, automação de implantação e observabilidade podem determinar se um agente passa de demonstração para um produto que um provedor SaaS consegue suportar em centenas de ambientes.

O que observar a seguir

Os próximos sinais serão detalhes concretos de produção da Axonius ou da AWS: se a empresa usa em produção um runtime compartilhado, runtimes dedicados ou uma configuração bridge; como a atribuição de custos em nível de inquilino é implementada; e quais controles são aplicados no código da aplicação versus no AgentCore Gateway.

Os construtores também devem observar evidências independentes sobre sobrecarga de implantação, tratamento de incidentes e testes de isolamento. Mais detalhes sobre seleção de modelo, throughput, latência e o custo de executar o primeiro agente da Axonius ajudariam a avaliar a arquitetura para além de seus objetivos de design declarados.

Perspectiva da Creati.ai

O exemplo da Axonius trata menos de adicionar um chatbot a um produto de segurança e mais de fazer a execução de agentes se encaixar em um plano de controle SaaS já existente. O trabalho difícil é ligar identidade, acesso a dados, ferramentas, cobrança, releases e depuração ao inquilino dono da solicitação.

O estudo de caso da AWS mostra por que a infraestrutura gerenciada de agentes é atraente para ISVs, mas não prova que uma abstração de plataforma elimina o risco de segurança no nível da aplicação. A lição mais forte para construtores é tratar roteamento de inquilinos e autorização de ferramentas como controles críticos do produto, e então validar as alegações do fornecedor com dados de implantação e falhas antes de se comprometer com uma arquitetura em grande escala.