Axonius runs one agent per tenant on AgentCore, and tracks model cost the same way

AWS has published an account of how Axonius, an asset intelligence platform for security and IT teams, deployed AI agents across a multi-tenant SaaS estate on Amazon Bedrock AgentCore [s1a]^[1]. The interesting part is not the agent. It is that the write-up treats tenant isolation and per-tenant cost tracking as first-order architectural requirements, which is the dimension a single-tenant agent design never has to answer ^[2].

The framing in the post is the standard SaaS trio applied to agents: silo, bridge, and pool ^[3]. Silo means dedicated resources per tenant, which on AgentCore runtime translates to a dedicated agent per tenant ^[4]. Pool means one agent serving many tenants, with each user session isolated by a unique session ID ^[5]. Bridge mixes the two, for example a dedicated runtime agent sitting on shared Amazon Bedrock Knowledge Bases, AWS's managed retrieval augmented generation service ^[6].

Axonius already runs silo. According to the post, each customer workload sits in its own Amazon VPC containing an Application Load Balancer, a Network Load Balancer, databases and general compute, across hundreds of isolated customer environments on AWS ^[7][8]. The company chose to keep that model rather than reshape tenancy around the new workload ^[9]. That decision has arithmetic attached: one dedicated agent per tenant across hundreds of environments means hundreds of agents to deploy, patch and watch ^[10], which is why the post lists fleet-scale observability with alarms as an explicit requirement from the DevOps team ^[11].

The agent itself interprets the state of large enterprise environments and identifies gaps and risks, analysing millions of data points from dozens of concurrent integration sources, with the stated aim of letting junior analysts run complex analyses without consuming senior analyst hours ^[12]. Axonius reconciles data from over 1,400 systems, and says it reduces the manual burden of security, audit and compliance work by up to 50 percent ^[13][14]. Those are vendor figures.

The requirement list is the part worth copying. Isolation: an agent serving one customer must be scoped exclusively to that customer's data ^[15]. Identity: the existing authentication and authorisation module lives on the tenant's EC2 instance, and the agent's identity flow had to integrate with it without disruption ^[16]. Integration: the tenant's agent needs secure access to that tenant workload's APIs ^[17]. Lifecycle: the agentic workload had to join the existing silo continuous delivery workflow ^[18]. And cost: the post states plainly that agentic costs can spiral, that most of the cost is model invocation, and that tracking model cost per tenant is what makes pricing an agentic offering possible at all ^[19][20].

That last item is the one single-tenant reference architectures quietly omit. If you cannot attribute model spend to a customer, you cannot price the feature, cap an abusive workload, or tell a renewal conversation from a margin leak. Silo gives you that attribution close to free, at the cost of fleet management; pool gives you density and pushes the accounting problem into session-level metering ^[4][5].

What to watch: whether ISVs on the pool side get per-session cost attribution that is good enough to bill against, and how many silo adopters find that hundreds of independently deployed agents outgrow their CD and alarming setup before the isolation benefit pays for itself. The published Axonius requirements are a usable checklist for that comparison ^[2].