Axonius already knew how to keep more than 1,400 customer environments apart. The asset-intelligence company reconciles security and IT data from a huge spread of connected systems into one source of truth, and it runs every customer inside a dedicated Amazon VPC AWS Machine Learning blog. Its first agent interprets the state of large enterprise environments, flags gaps and risks across millions of data points, and frees junior analysts from hours of manual work. Adding that agent to the picture threatened to undo the separation the company had spent years building.
Security and IT teams use that unified view to decide which vulnerabilities to fix first and which audit findings to chase. The data is also among the most heavily regulated material a company holds, which is why Axonius had always refused to co-mingle it. An agent that could quietly widen that aperture was a non-starter from the start.
The hard part was never the model. It was the memory.
A security agent that studies a customer’s environment touches sensitive asset inventories, identity data, and the credentials that connect to dozens of integrations at once. If one customer’s agent could read another’s context, the silo that defines the Axonius product would collapse overnight. Axonius explained the requirement without hedging: an agent serving one customer must be scoped exclusively to that customer’s data, and the boundary has to hold even when the agent code has a bug AWS Machine Learning blog.
Three ways to share an agent
Every SaaS vendor that bolts agents onto a multi-tenant product hits the same fork. The AWS Well-Architected SaaS Lens names three patterns, and each one trades isolation for operational simplicity AWS Well-Architected SaaS Lens.
The pool model puts every tenant behind a single shared runtime. Tenants authenticate through an identity provider, and a token claim carries the tenant identifier that the agent code uses to route tool calls and data access. In practice the runtime’s built-in authorizer fetches signing keys from a discovery URL and validates the token’s issuer before the agent ever runs, so the tenant claim is trustworthy at the edge. It is cheap to run and instant to onboard, but tenant separation lives entirely in application logic. One routing mistake can leak data across customers.
The bridge model keeps the shared runtime but pushes enforcement down to the tool layer AWS Well-Architected SaaS Lens. Every outbound call passes through a gateway that evaluates a policy before the tool executes. A Lambda interceptor can swap the original token for short-lived, tenant-scoped credentials, so the downstream system never sees the broad token. The policy engine can also forbid specific tenant groups from reaching restricted tools, while a response interceptor trims which tools a tenant is even allowed to discover. That gives defense in depth, but it adds a gateway, policy rules, and credential plumbing to operate.
The silo model gives each tenant its own dedicated resources. Nothing is shared, so nothing can cross. The price is scale: every new customer means new infrastructure to provision, monitor, and update, and the default AgentCore quota of 1,000 agents per AWS account forces real capacity planning for large customer bases AWS Machine Learning blog.
Why Axonius kept the silo
Axonius already ran in silo mode, and the team decided the agent had to follow the same rule. Each customer gets a dedicated Bedrock AgentCore runtime, and each user session inside that runtime runs in its own isolated microVM Amazon Bedrock AgentCore runtime sessions.
Isolation is not free.
Axonius described the microVM model as the feature that settled the architecture debate: “Session isolation with microVMs was the decisive factor.” After a session ends, the entire microVM is torn down and its memory sanitized, which removes the chance that one customer’s state bleeds into the next Amazon Bedrock AgentCore runtime sessions.
That cleanup is what lets Axonius keep sensitive cybersecurity inventories apart without trusting the agent’s own logic. The company noted that deterministic isolation matters more than the convenience of shared infrastructure when the data is as exposed as asset inventories are. The silo also lets each tenant run a different agent version or model without affecting anyone else.
Axonius also had to wire the agent into the authentication module that already lives inside each tenant’s VPC, so the agent inherits the same login and authorization the customer’s human users already trust, rather than standing up a parallel identity system. The existing module handles who can see what; the agent now plugs into that decision instead of bypassing it.
The downside is the operational bill. Hundreds of runtimes mean hundreds of things to patch, monitor, and tear down, which is why Axonius leans on CloudFormation to provision and remove each customer’s agent automatically.
Cost can spiral with the agent
Multi-tenant agents create a second problem that has nothing to do with security. Most of the bill is model invocations, and a chatty agent serving hundreds of customers can quietly run up a cost that no one can attribute to a single account. Most agentic cost is model tokens rather than compute, so metering has to live at the invocation layer where each call is counted, not at the infrastructure layer where a shared runtime hides who spent what.
Axonius tracks token consumption per tenant in CloudWatch and turns governance into a hard limit. When a customer exceeds its token budget, an automated IAM policy blocks further invocations instead of merely sending an alert AWS Machine Learning blog.
The trade-off is real. A hard IAM deny can stop a legitimate workflow cold, so the budget has to be set with care and probably revisited as usage patterns emerge. But Axonius argued that a predictable ceiling beats an unpredictable invoice, especially when the cost must eventually be passed through to the customer as a priced offering.
The pieces that made it work
The runtime is only one part of the design. Axonius layered Bedrock Guardrails on every model response to keep output on topic and inside policy, used Bedrock Knowledge Bases with metadata filtering so each tenant’s retrieval stays separated, and connected agents to customer VPCs through a private network link rather than the public internet. Guardrails reject off-topic or unsafe responses before they reach the user, and the Knowledge Bases sit on S3 Vectors so tenant data stays separated by metadata instead of being copied into separate stores.
Private connectivity runs over VPC Lattice so the agent reaches customer workloads and AWS service endpoints without leaving the private network, and IAM role tags attribute each model call to the right tenant for billing. That tagging is what makes per-tenant cost governance possible in the first place.
Observability closes the loop. Axonius uses CloudWatch and X-Ray to trace each agent’s reasoning steps and tool calls across a fleet that will only grow as customers onboard. Without per-session tracing, a fleet of dedicated runtimes becomes impossible to debug, and a single misbehaving agent is hard to isolate from the noise.
Provisioning is handled by CloudFormation templates that stand up and tear down a customer’s agent as a single unit. That automation is what makes the silo model bearable at scale, because the alternative is manually managing hundreds of isolated stacks by hand.
What other SaaS vendors should steal
The Axonius design is a reference point for any vendor shipping agents into regulated, multi-tenant environments. The lesson is not “always use a silo” — that choice hurts at scale — but “pick the isolation model that matches the sensitivity of the data, then enforce it below the agent rather than inside it.”
Other teams are reaching the same conclusion from different stacks. nOps says it runs FinOps agents on Bedrock to speed delivery of cost tooling nOps FinOps agents on Amazon Bedrock, and n8n users can run production agents against Bedrock AgentCore through a managed harness run production AI agents in n8n with Amazon Bedrock AgentCore.
The bridge pattern is where the interesting engineering now lives. It promises shared efficiency without surrendering the safety of a silo, but it demands a gateway, policy rules, and short-lived credentials wired together correctly. Get that wiring wrong and the “defense in depth” is just more places to fail.
The agents are coming to the tenant boundary
Agents are moving from demos into the systems that hold a company’s most sensitive records, and the tenant boundary is the line they are not allowed to cross. Axonius shows one defensible path: keep the wall intact, enforce isolation where the hardware actually separates memory, and treat runaway cost as a control rather than a finance footnote. The question for every multi-tenant vendor is no longer whether to add agents, but where the wall goes once they do. The vendors that treat the tenant boundary as an afterthought will be the ones explaining the breach.
