Inside Axonius's dedicated-runtime agent design
Axonius has kept its silo-style SaaS architecture as it adds AI agents, according to an AWS technical case study. The cybersecurity company is using Amazon Bedrock AgentCore with a dedicated runtime for each customer, private VPC connectivity and per-tenant cost controls. The design shows how some software vendors are prioritizing isolation and governance over the simpler economics of a shared agent runtime.Why Axonius stayed with tenant silos
AWS describes Axonius as choosing the most isolated of three common SaaS patterns for agentic AI: silo, bridge and pool. In the selected silo model, every customer receives a dedicated AgentCore runtime rather than sharing a single runtime across tenants.The decision fits Axonius's existing SaaS deployment model. AWS says each customer workload already resides in a dedicated Amazon VPC containing load balancers, databases and compute infrastructure. Keeping that model for AI agents lets Axonius avoid application-level tenant routing as the main security boundary, but it also means the company must automate provisioning, monitoring and updates across many runtimes.
AWS frames the agent as a way for customers to ask questions about large enterprise environments. The first agent is described as interpreting asset state, identifying gaps and risks, and helping junior analysts run complex analyses without relying on senior analysts for hours of manual work. That is a narrow operational use case, not a general claim that AI can replace security expertise.
How requests move through the agent
The request flow begins inside the customer's existing Axonius instance. When a signed-in user sends a chat message, the Axonius application authenticates the request and issues a short-lived impersonation JWT containing user, tenant, session and actor identifiers, according to AWS.The application then calls InvokeAgentRuntime on that customer's dedicated AgentCore runtime. AWS says the invocation payload carries tenant configuration such as memory, knowledge base, data-source IDs, AWS Region, Axonius version and callback address. The JWT is sent in a custom AgentCore header rather than in the request body, which is intended to keep authentication material out of saved agent state.
Once inside the runtime, the agent validates the JWT against the customer's Axonius application before the model runs. AWS says Axonius uses a LangGraph supervisor to route questions to specialist agents and uses Amazon Bedrock models, including Claude, to decide whether the answer requires product documentation, live customer data or a direct response.
Private networking and credential scope
The design's security argument rests on network separation, short-lived identity and per-session isolation. AWS says each customer has a dedicated AgentCore runtime attached to an elastic network interface inside that customer's VPC and subnet.When a question needs live data, the agent can invoke a query tool that translates natural language into an Axonius Query Language expression, then reaches the customer's Axonius application instance over private addressing. AWS says the traffic stays inside the customer VPC and AWS network, and the same JWT limits the agent to data the user is already allowed to access.
For product documentation, Axonius uses Amazon Bedrock Knowledge Bases with Amazon S3 Vectors and metadata filtering to isolate tenant-specific data. AWS also says Bedrock Guardrails are applied server-side to every model response before the response is returned to the user interface. The practical implication is that identity, retrieval and output filtering are layered, although the effectiveness still depends on correct configuration and operational discipline.
Cost governance is tied to token use
Axonius also built token governance into the architecture because model invocation is the main cost driver for agentic workloads. AWS says CloudWatch tracks input and output token metrics per agent, while OpenTelemetry instrumentation gives Axonius real-time token usage visibility.For allocation, AWS says Axonius uses IAM role tagging through Amazon Bedrock cost allocation by IAM user or role. Application Inference Profiles per model allow more granular tagging, alerting and cost control through Amazon EventBridge. AWS says the resulting cost allocation visibility is updated once or twice daily, with CloudWatch used for immediate alerts.
The strongest control described is automated enforcement. If usage exceeds a customer's token budget, a CloudWatch alarm can trigger an IAM-deny policy that blocks further invocations. For SaaS vendors, that kind of stop mechanism may be as important as dashboards because agent use can vary sharply across tenants.
The trade-off: isolation over operational simplicity
AWS's comparison makes clear that Axonius did not choose the easiest operating model. A pooled runtime would simplify deployment and onboarding, while a bridge pattern could centralize some enforcement through AgentCore Gateway. Axonius instead accepted the overhead of a runtime per customer.The benefit is a cleaner isolation story. AWS says each user session inside AgentCore runs in a dedicated microVM with isolated CPU, memory and filesystem resources, and the microVM is terminated after the session. Each customer also has a dedicated runtime and private network path to its own Axonius deployment.
The cost is scale management. AWS notes the default quota is 1,000 agents per AWS account, adjustable through Service Quotas, and that managing hundreds of runtimes requires automation. Axonius uses AWS CloudFormation for per-customer provisioning and teardown, according to the case study.
AWS claims a shorter build cycle
AWS says Axonius reduced its multi-tenant AI agent development cycle from an estimated eight weeks of custom infrastructure work to 10 days of production-ready deployment, described as a 75 percent reduction in time to market. Because that figure comes from the AWS case study, it should be read as a vendor-reported implementation result rather than a benchmark.The post includes a statement from Dori Shmuel, SaaS DevOps Lead at Axonius:
For other software vendors, the case is most useful as an architectural reference. It shows one path for adding AI agents to an existing regulated or security-sensitive SaaS platform without abandoning tenant silos, but it does not remove the need to validate permissions, costs, observability and failure modes in each deployment.
Conclusion
Axonius's Bedrock AgentCore deployment highlights a pragmatic split in enterprise AI agent design. Shared runtimes may reduce operating burden, but Axonius chose dedicated runtimes because its existing product architecture and customer data model already depend on strong tenant separation.The most newsworthy part is not that a SaaS company added a chatbot. It is that Axonius tied the agent to short-lived user identity, private VPC access, per-tenant runtimes, knowledge-base filtering, guardrails and token-budget enforcement. That combination is likely to become a reference pattern for security-focused software vendors evaluating agentic features on managed cloud infrastructure.
Sources
Editorial Team - CoinBotLab