Axonius is adding AI agents to its cybersecurity SaaS platform without abandoning the customer-by-customer isolation model that underpins its existing AWS deployment, according to a new AWS Machine Learning Blog case study.

The company used Amazon Bedrock AgentCore to run agents for hundreds of separate customer environments. The design addresses a central problem for software vendors adding agentic features: an agent must be useful across many tenants while remaining restricted to the data, APIs, identity controls, and operating costs of the customer it serves.

AWS describes the architecture and its reported benefits in a vendor-authored post. The source does not provide independent performance testing or customer commentary from Axonius, so claims about deployment scale and operational outcomes should be treated as AWS-reported.

Axonius keeps its silo-based SaaS model

Axonius provides an asset intelligence platform for security and IT teams. AWS says the service reconciles information from more than 1,400 systems and operates hundreds of isolated customer environments. Each customer workload runs in a dedicated Amazon Virtual Private Cloud, or Amazon VPC, containing components such as load balancers, databases, and general compute infrastructure.

The first AI agent described in the post analyzes large enterprise environments, identifies gaps and risks, and interprets millions of data points arriving from multiple integrations. AWS says the feature is intended to let junior analysts perform complex analysis without requiring senior analysts to spend hours on manual investigation.

Rather than move that workload into a shared SaaS architecture, Axonius wanted the agent to follow its existing tenant model. That decision shaped the technical requirements: an agent handling one customer’s environment must not reach another customer’s data, while still integrating with the service’s established authentication, deployment, and API patterns.

For AI builders, the important point is that multi-tenancy here is not just a matter of assigning a customer identifier to a request. The agent has to be deployed, authorized, connected, monitored, and billed in a way that preserves the boundaries already expected of a security product.

Three deployment patterns, with different trade-offs

AWS frames the design choices around three common patterns for SaaS agent deployments: silo, pool, and bridge.

In a silo architecture, each tenant receives dedicated resources. Applied to AgentCore Runtime, that can mean deploying a dedicated agent for every customer. This offers a clear infrastructure boundary, but increases the number of resources to provision, update, monitor, and retire.

The pool model uses shared resources. A single agent can serve multiple tenants, with each session receiving a distinct session ID. AWS says AgentCore Runtime provides a dedicated microVM for each session, while application-level controls handle the separation between tenants.

That approach simplifies deployment and customer onboarding, but it places more responsibility on the application. The agent must correctly interpret the tenant context on every request and prevent cross-tenant access. Tenant-specific behavior can also require additional conditional logic in a shared deployment.

The bridge model combines the two approaches. An agent runtime can be shared while more stringent tenant enforcement is applied at the tool layer. In the architecture discussed by AWS, AgentCore Gateway sits between the agent and outbound tools, allowing tool calls to be checked against tenant boundaries before execution.

AWS presents this hybrid pattern as a way to reduce infrastructure overhead while retaining a stronger control point for access to customer systems. The case study does not disclose all production implementation details, so it is not possible from the available evidence to assess how Axonius distributed every component between shared and dedicated resources.

Identity and tool access are part of the isolation boundary

Axonius already had an authentication and authorization module running on tenant-specific Amazon EC2 infrastructure. Its requirement was to add agents without replacing that identity flow.

AWS describes a design in which tenants authenticate through an OAuth 2.0 identity provider, such as Amazon Cognito. Tokens contain a tenant-specific claim, for example a custom tenant identifier. The built-in JWT authorizer in AgentCore Runtime validates the token using the identity provider’s discovery endpoint, while the agent reads the claim to route requests to the correct customer environment.

This division is significant. Token validation establishes that a request came from an accepted identity provider, but the agent and its tools still need to apply the tenant claim correctly. In practice, the security boundary depends on both the platform’s authorization mechanism and the code that maps identity to APIs, data stores, and tools.

The same principle applies to service integration. AWS says the agent associated with a tenant must have secure access to that tenant’s APIs. The post presents AgentCore Gateway as a possible enforcement point for outbound tool calls, creating a layer where tenant context can be checked before a tool interacts with the customer workload.

Evidence, cost control, and operational scale

AWS identifies cost tracking as one of Axonius’s core requirements because model invocation is expected to account for much of an agent’s expense. Per-tenant accounting can help a SaaS provider decide how to price an AI feature, set usage limits, and identify customers or workflows with unusually high consumption.

The company also needed to add the agent workload to its existing silo-based continuous delivery process. That requirement is easy to overlook: an architecture that works in a prototype can become difficult to operate when every customer environment has its own deployment lifecycle.

Observability was another stated concern. AWS says Axonius needed fleet-level monitoring, alarms, and tracing for a large number of agents, with enough detail to investigate failures. Those needs make agent operations different from ordinary application monitoring. Teams must understand not only whether a service is available, but also which model calls, tools, sessions, and tenant permissions contributed to an outcome.

The available evidence comes from AWS rather than an independent auditor or a customer interview. AWS reports that AgentCore allowed Axonius to deploy isolated, multi-tenant agents without building custom compute isolation, authentication, or observability infrastructure from the ground up. That is a vendor claim about the platform’s role, not an independently verified comparison of engineering time, security, or total cost.

What it means for builders and enterprise buyers

For SaaS companies, Axonius’s case highlights a practical sequence for adding agents: begin with the existing tenant model, identify the data and tool boundaries, then decide which controls belong in the runtime, the application, or a gateway layer.

The choice also affects product economics. Dedicated resources may offer clearer isolation and customization, but shared runtimes can simplify onboarding and operations. A bridge design may reduce duplication, yet it requires careful policy enforcement at every tool boundary. Neither model removes the need for testing authorization failures, malformed tenant claims, excessive tool permissions, and accidental data leakage.

Enterprise buyers evaluating AI features should ask vendors how tenant identity follows an agent request, whether tool calls are independently authorized, how model usage is attributed, and how traces are separated for incident response. These questions matter especially for security software, where an agent may process sensitive inventory, configuration, and vulnerability information.

The broader market implication is that agent platforms are competing on operational primitives as much as on model access. Runtime isolation, identity integration, gateways, deployment automation, and observability can determine whether an agent moves from a demonstration into a product that a SaaS provider can support across hundreds of environments.

What to watch next

The next signals will be concrete production details from Axonius or AWS: whether the company uses a shared runtime, dedicated runtimes, or a bridge arrangement in production; how tenant-level cost attribution is implemented; and which controls are enforced in application code versus AgentCore Gateway.

Builders should also watch for independent evidence on deployment overhead, incident handling, and isolation testing. More detail on model selection, throughput, latency, and the cost of running the first Axonius agent would make it easier to judge the architecture beyond its stated design goals.

Creati.ai perspective

Axonius’s example is less about adding a chatbot to a security product than about making agent execution fit an existing SaaS control plane. The difficult work is tying identity, data access, tools, billing, releases, and debugging to the tenant that owns the request.

AWS’s case study shows why managed agent infrastructure is attractive to ISVs, but it does not prove that a platform abstraction eliminates application-level security risk. The strongest lesson for builders is to treat tenant routing and tool authorization as product-critical controls, then validate the vendor’s claims with deployment and failure data before committing to a large-scale architecture.