Axonius 如何基于 Bedrock AgentCore 构建安全的多租户 AI Agent

独立软件供应商（ISV）正在扩展其产品能力并加入 AI Agent。组织在引入 Agent 工作负载时，通常会考虑安全性、可扩展性、上市时间和成本追踪。ISV 还面临另一层挑战：它们向其他组织提供服务，因此需要为每一位客户管理 Agent 工作负载。也就是说，ISV 不仅需要在整体层面应对这些常见挑战，还必须在租户层面加以管理。

Axonius 是一个资产智能平台，可帮助安全和 IT 团队确定风险优先级并协调修复工作。Axonius 将来自 1,400 多个系统的数据整合为一个权威事实来源，使安全团队及其支持的团队能够高效协作，将安全、审计和合规工作中的人工负担最多降低 50%。Axonius 在 AWS 上以软件即服务（SaaS）基础设施的形式运行其软件，并管理数百个彼此隔离的客户环境。

Amazon Bedrock AgentCore 是一个可大规模构建、连接和优化 Agent 的平台，支持任意框架或模型。本文介绍 SaaS 提供商可用于部署 AI Agent 的策略，说明 Amazon Bedrock AgentCore 如何支持这些选项，探讨 Axonius 的考量，并分享 Axonius 最终选择的架构。我们还将介绍 Axonius 如何将 Agent 工作负载整合进其既有方法体系。本文面向在 AWS 上构建安全多租户 AI Agent 部署的平台工程师和架构师。

AI Agent 的多租户模式

独立软件供应商（ISV）通常通过 SaaS 模式提供服务。在选择架构时，ISV 通常有三种常见架构模式：孤岛（silo）、桥接（bridge）和资源池（pool）。以下章节将结合 Agentic AI 和 Amazon Bedrock AgentCore 进一步说明每种模式的含义。

_孤岛模式（silo model）_是指为租户提供专属资源的架构。对于 AgentCore Runtime，这意味着为每个租户使用专属 Agent。采用_资源池模式（pool model）时，租户共享资源，一个 Agent 为多个租户提供服务。使用 AgentCore Runtime 时，可以通过为每个用户会话分配唯一的会话 ID 来隔离每个用户会话。第三种模式是_桥接模式（bridge model），其中部分组件采用孤岛模式，其他组件则采用资源池模式。例如，我们可以在 AgentCore Runtime 中部署专属 Agent，同时使用共享的 Amazon Bedrock Knowledge Bases；后者是一项由 AWS 托管的检索增强生成（RAG）服务。

挑战

Axonius 希望在其产品中加入 AI Agent。其首个 AI Agent 用于解读大型企业环境的状态，并识别差距和风险；该 Agent 使用 AI 分析并理解来自数十个并发集成数据源的数百万个数据点。这项计划使初级分析师能够执行复杂分析，而无需占用高级分析师数小时的手动工作时间。Axonius 选择维持其现有的租户管理方法。

Axonius 的 SaaS 部署模型是孤岛模式。每个客户工作负载都位于专属的 Amazon Virtual Private Cloud（Amazon VPC）中。该 VPC 包含 Application Load Balancer（ALB）、Network Load Balancer（NLB）、数据库和通用计算基础设施。

Axonius 希望在维持孤岛部署模式的同时引入 AI Agent。Axonius 需要满足以下几项关键要求：

• 租户隔离 — Axonius 处理敏感的客户数据。服务于某一客户的 Agent 必须严格限定在该客户的数据范围内。
• 身份 — 现有服务已部署认证和授权模块，该模块位于分配给租户的 Amazon Elastic Compute Cloud（Amazon EC2）中。Axonius 需要在不造成中断的情况下，将 Agent 的身份流程与现有模块集成。
• 成本追踪 — Agent 工作负载的成本可能迅速失控。大部分成本来自模型调用，因此按租户追踪模型成本至关重要。在考虑 Agent 产品的定价选项时，了解自身成本不可或缺。
• 与服务集成 — 与租户关联的 Agent 实例需要能够安全访问该租户工作负载的 API。
• 生命周期管理 — 将 Agent 工作负载加入现有的孤岛式持续交付（CD）工作流。
• 可观测性 — 在孤岛模式下，Axonius 将拥有大量 Agent。DevOps 团队需要高质量、易于集成的可观测性能力，以追踪大规模 Agent 集群、在出现问题时触发告警，并提供用于调试问题的追踪能力。

以下章节介绍 Axonius 评估过的选项以及最终选择。

可选方案

在考察租户部署模式时，Axonius 考虑了以下选项。

选项 1：资源池 — 基于 JWT 的共享 Runtime 租户路由

AgentCore Runtime 通过为每个会话分配专属微型虚拟机（microVM）来实施结构性隔离。单个 Runtime 为多个租户提供服务，同时通过应用层控制保持完整的租户隔离。

工作原理

租户通过 OAuth 2.0 身份提供商（例如 Amazon Cognito）进行认证，JWT 中携带唯一的租户声明字段（例如 custom:tenant_id）。Runtime 的内置 JWT 授权器使用配置的发现 URL 获取公钥，并验证令牌签发方。随后，Agent 代码读取该声明字段，将工具调用和数据访问路由至正确的租户环境。

图 1：采用单一共享 Runtime 和基于 JWT 租户路由的资源池模式

优势

• 运营简单：只需部署、监控和更新一个 Runtime。
• 快速接入：新客户无需进行基础设施预置即可立即接入，从而缩短实现价值的时间。

劣势

• 依赖应用层的隔离：租户隔离完全依赖应用代码。
• 同质化部署：按租户定制需要额外的条件逻辑。

一种混合方法将单一共享 Runtime 的运营简洁性，与通过 AgentCore Gateway 在工具层实施基础设施级租户控制相结合。租户共享一个 Runtime，但每次出站工具调用都会经过 Gateway，在工具代码执行前强制实施租户边界。

工作原理

租户连接至同一个 AgentCore Runtime，该 Runtime 与选项 1 相同，使用每会话专属微型虚拟机实现计算隔离。不同之处在于，每次工具调用都会路由至共享的 AgentCore Gateway，并通过两种强制执行机制进行控制：

1. Amazon Bedrock AgentCore 中的策略 — 确定性访问控制。Cedar 规则根据调用方的身份属性（例如 Cognito 组声明）评估每次工具调用，并给出允许或拒绝的决策。一条禁止规则可以阻止特定租户组调用受限工具。
2. AWS Lambda 拦截器（REQUEST） — 动态验证和上下文增强。在工具调用到达目标端之前运行，提取 JWT、查询租户上下文，并通过 STS AssumeRole 以“代表执行”（act-on-behalf）模式将令牌交换为短期、租户范围限定的 IAM 凭证。下游工具接收这些最小权限凭证，而非原始 JWT。

Gateway 会在 Cedar 策略之前评估拦截器，使拦截器能够丰富请求上下文，随后由策略进行评估。

RESPONSE 拦截器还可根据租户身份进一步筛选工具发现结果。

这意味着有两套相互独立的机制可在基础设施层面、在 Agent 代码之外实施租户隔离。

图 2：采用共享 Runtime 和由 Gateway 强制实施工具隔离的桥接模式

优势

• **分层的基础设施级强制控制：**即使 Agent 代码存在路由错误，Gateway 也会阻止跨租户工具调用。Cedar 策略（确定性）和 Lambda 拦截器（动态）提供纵深防御。
• 集中式治理：通过单一 Gateway 审计和实施所有工具调用的租户策略，每项决策都会记录到 Amazon CloudWatch。
• **共享效率：**Runtime、知识库和可观测性基础设施均可集中管理，同时不共享安全风险。

劣势

• **部署复杂性：**需要配置 Gateway、REQUEST/RESPONSE 拦截器 Lambda、租户映射、Cedar 策略以及 STS 角色信任关系。与选项 1 或选项 3 相比，这会显著增加组件数量。
• VPC 连接性：后端工具通常位于 VPC 中，需要使用 VPC 端点实现私有 Gateway 连接，这会增加网络复杂性和潜在故障点。

选项 3：孤岛 — 每个租户使用专属 Runtime

在孤岛模式中，每个租户都在专属的 AgentCore Runtime 上运行。访问控制完全通过 AWS Identity and Access Management（IAM）实施。附加在 Runtime 及其端点上的基于资源的策略，决定哪些主体（无论是同一账户内的角色还是跨账户身份）可以调用 Agent。由于每个租户的工作负载运行在独立基础设施上，因此租户之间不存在共享计算资源。

图 3：每个租户使用专属 Runtime 的孤岛模式

工作原理

每个租户都会获得一个专属 AgentCore Runtime，并在新客户接入时自动完成预置（例如，通过 AWS CloudFormation 或 CDK）。在该 Runtime 内，每个用户会话都在其独立的微型虚拟机中运行，因此即使是同一租户内的不同用户之间，也不会共享进程状态。访问控制通过同时附加到 AgentCore Runtime 及其端点的 IAM 基于资源的策略实施。调用方必须明确获得其租户对应特定 Runtime 的权限。

优势

• **最高级别的隔离：**每个租户拥有专属计算资源，不存在共享进程状态。每个会话都在独立的微型虚拟机中运行，租户无法访问彼此的基础设施。
• **简单的授权模型：**应用于 Runtime 及其端点的 IAM 基于资源的策略是唯一的强制执行点。无需应用层路由逻辑。
• **独立配置：**每个 Runtime 都可以运行不同版本的 Agent、模型或端点配置，而不会影响其他租户。

劣势

• **规模限制：**每个 AWS 账户的默认配额为 1,000 个 Agent（可通过 Service Quotas 调整），因此对于庞大的客户群体需要进行容量规划。
• **预置延迟：**每个新租户都需要创建专属 Runtime 和端点，与共享 Runtime 模式相比会增加接入延迟。
• **运营开销：**监控、更新和管理数百个 Runtime 会增加运营复杂性，需要强大的自动化能力（例如 CDK/CloudFormation 流水线、集中式可观测性）。

解决方案概述

Axonius 当前采用孤岛模式运营，并决定在加入 Agent 时继续沿用该方法。每位客户均拥有一个专属 Agent。Axonius 使用 Amazon Bedrock 和 AgentCore 设计了多租户 Agentic AI 架构，其中包括以下关键组件：

• AgentCore Runtime — Axonius 为每位客户部署一个专属 Agent，并使用 AgentCore Runtime 让每个用户会话在独立的微型虚拟机中运行。
• Amazon Elastic Container Registry（Amazon ECR） — 存储按租户划分的 Agent 容器镜像。
• Amazon Bedrock — 为底层基础模型（FM）提供支持，并通过 IAM 角色标签实现成本分配。
• Amazon Bedrock Knowledge Bases（KB） — Axonius 使用搭配 Amazon S3 Vectors 的 Amazon Bedrock Knowledge Bases（KB），原因是其成本效率和扩展能力。Axonius 使用元数据过滤来隔离租户专属数据。
• Amazon Bedrock Guardrails — 提供内容过滤和主题拒绝策略。Guardrails 应用于每一条模型响应，在响应分享给用户之前确保其安全且不超出范围。
• Amazon CloudWatch — 监控整体工作负载，并在成本控制中发挥关键作用。它追踪令牌消耗指标（输入/输出），发出告警，并通过 IAM 拒绝机制实施成本治理。如果客户超出令牌预算，自动化 IAM 策略将阻止后续调用。
• Amazon VPC Lattice — 使 Axonius 能够管理高成本效益的私有连接，连接 AgentCore Runtime、客户 VPC 和 AWS 服务端点。

该架构使用 AWS CloudFormation 自动执行按客户划分的资源预置和拆除，使 Axonius 能够在其客户群中扩展 Agent 部署。

图 4：基于 Amazon Bedrock AgentCore 的 Axonius 多租户 Agentic 架构

为什么选择 Amazon Bedrock AgentCore Runtime？

在评估多种方案后，包括将 Agent 作为额外容器运行在其现有 EC2 实例中，Axonius 选择了 Amazon Bedrock AgentCore Runtime。其专为此场景构建的能力直接满足了 Axonius 的多租户 SaaS 要求。

• 通过微型虚拟机实现会话隔离 — AgentCore Runtime 的会话隔离是决定性因素。每个用户会话都运行在一个

Independent Software Vendors (ISVs) are expanding their offerings and adding AI agents. Common considerations for organizations when adding agentic workloads include security, scalability, time to market, and cost tracking. ISVs have another dimension, they provide services to other organizations and need to manage agentic workloads for each customer. As such, ISVs need to manage those common challenges not only broadly but at the tenant level.

Axonius is the asset intelligence platform that helps Security and IT teams prioritize risks and coordinate fixes. By reconciling data from over 1,400 systems into one authoritative source of truth, Axonius enables security teams and the teams they support to collaborate effectively, reducing the manual burden of security, audit, and compliance by up to 50%. Axonius runs its software as a service (SaaS) infrastructure on AWS, managing hundreds of isolated customer environments.

Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model. In this post, we cover strategies available for SaaS providers to deploy AI agents, describe how Amazon Bedrock AgentCore supports those options, look into Axonius’s considerations, and share Axonius’s chosen architecture. We also describe how Axonius integrated agentic workloads with its existing methodology. This post is for platform engineers and architects building secure, multi-tenant AI agent deployments on AWS.

Multi-tenancy patterns for AI agents

Independent Software Vendors (ISVs) tend to provide services using the SaaS model. When choosing an architecture, ISVs have three common architectural patterns: silo, bridge, and pool. The following sections elaborate on what each model means when we look into agentic AI with Amazon Bedrock AgentCore.

The silo model refers to an architecture where tenants are provided dedicated resources. Looking into AgentCore runtime, it means using a dedicated agent per tenant. With the pool model , tenants share resources, one agent serves multiple tenants. With AgentCore runtim, you can isolate each user session by allocating a unique session ID for each user session. The third pattern is the bridge model in which some components are in silo mode while others are in pool mode. For example, we can have a dedicated agent deployed into AgentCore runtime using shared Amazon Bedrock Knowledge Bases, an AWS managed Retrieval Augmented Generation (RAG) service.

The challenge

Axonius was looking to add AI agents to their offering. Their first AI agent interprets the state of large enterprise environments and identifies gaps and risks, using AI to analyze and make sense of millions of data points from dozens of concurrent integration sources. This initiative allows junior analysts to run complex analyses without tying up senior analysts in hours of manual work. Axonius opted to maintain their current tenant management methodology.

Axonius’s SaaS deployment model is silo. Each customer workload resides in a dedicated Amazon Virtual Private Cloud (Amazon VPC). The VPC contains an Application Load Balancer (ALB), Network Load Balancer (NLB), databases, and general compute infrastructure.

Axonius wanted to introduce AI agents while keeping a silo deployment model. Axonius needed to address several key requirements:

• Tenant isolation – Axonius handles sensitive customer data. An agent serving one customer must be scoped exclusively to that customer’s data.
• Identity – The existing service has an authentication and authorization module in place, residing on the Amazon Elastic Compute Cloud (Amazon EC2) allocated to the tenant. Axonius needed to integrate the agent’s identity flow with the existing module without disruption.
• Cost tracking – Agentic costs can spiral. Most of the cost is in model invocation, thus it’s critical to track model cost per tenant. Knowing your cost is essential when considering pricing options for agentic offerings.
• Integration with the service – The agent instance associated with a tenant needs to have secure access to that tenant workload’s APIs.
• Lifecycle management – Adding the agentic workload to the current silo Continuous Delivery (CD) workflow.
• Observability – With a silo model, Axonius will have a large number of agents. The DevOps team needed high quality, straightforward to integrate observability that can track large fleets of agents, issue alarms when things go wrong, and provide tracing capabilities to debug issues.

The following sections cover the options Axonius evaluated and what they chose.

Possible solutions

Looking into tenant deployment modes, Axonius considered the following options.

Option 1: Pool — shared runtime with JWT-based tenant routing

AgentCore runtime enforces structural separation by allocating a dedicated microVM for each session. A single runtime serves tenants while maintaining full tenant separation through application-level controls.

How it works

Tenants authenticate through an OAuth 2.0 identity provider (for example, Amazon Cognito) with JWTs carrying a unique tenant claim (for example, custom:tenant_id). The runtime’s built-in JWT authorizer uses the configured discovery URL to fetch public keys and validate the token’s issuer. The agent code then reads the claim to route tool calls and data access to the correct tenant environment.

Figure 1: Pool model with a single shared runtime and JWT-based tenant routing

Advantages

• Operational simplicity : Only one runtime to deploy, monitor, and update.
• Rapid onboarding : New customers onboard immediately without infrastructure provisioning, reducing time-to-value.

Disadvantages

• Application-dependent isolation : Tenant separation relies entirely on application code.
• Homogeneous deployment : Per-tenant customization requires additional conditional logic.

A hybrid approach combines the operational simplicity of a single shared Runtime with infrastructure-level tenant enforcement at the tool layer through AgentCore Gateway. Tenants share one Runtime, but every outbound tool call passes through a Gateway that enforces tenant boundaries before the tool code executes.

How it works

Tenants connect to the same AgentCore runtime, which uses dedicated microVMs per session for compute isolation, identical to Option 1. The difference is that every tool invocation routes through a shared AgentCore Gateway with two enforcement mechanisms:

1. Policy in Amazon Bedrock AgentCore – Deterministic access control. Cedar rules evaluate each tool call against the caller’s identity attributes (for example, Cognito group claims) and produce an allow/deny decision. A forbid rule can block specific tenant groups from invoking restricted tools.
2. AWS Lambda Interceptor (REQUEST) – Dynamic validation and context enrichment. Runs before the tool call reaches the target extracts the JWT, looks up tenant context, and exchanges the token for short-lived, tenant-scoped IAM credentials through STS AssumeRole (“act-on-behalf” pattern). The downstream tool receives these least-privilege credentials instead of the original JWT.

The Gateway evaluates the interceptor before the Cedar policy, enabling the interceptor to enrich the request context that the policy then evaluates.

A RESPONSE interceptor can additionally filter tool discovery based on tenant identity.

This means two independent mechanisms enforce tenant isolation at the infrastructure layer, outside agent code.

Figure 2: Bridge model with a shared runtime and gateway-enforced tool isolation

Advantages

• Layered infrastructure enforcement: Even if the agent code has a routing bug, the Gateway blocks cross-tenant tool calls. Cedar policy (deterministic) and a Lambda interceptor (dynamic) provide defense in depth.
• Centralized governance : A single Gateway to audit and enforce tenant policies across all tool invocations, with every decision logged to Amazon CloudWatch.
• Shared efficiency: Runtime, knowledge bases, and observability infrastructure are managed centrally without sharing security risk.

Disadvantages

• Setup complexity: Requires configuring a Gateway, REQUEST/RESPONSE interceptor Lambdas, tenant mappings, Cedar policies, and STS role trust relationships. This adds significantly more moving parts than Option 1 or 3.
• VPC connectivity : Backend tools typically reside in a VPC, requiring VPC endpoints for private Gateway connectivity, which adds networking complexity and potential points of failure.

Option 3: Silo — dedicated runtime per tenant

In the silo model, every tenant operates on a dedicated AgentCore runtime. Access control is enforced entirely through AWS Identity and Access Management (IAM). Resource-based policies on both the Runtime and its endpoint determine which principals, whether same-account roles or cross-account identities, are allowed to invoke the agent. Because each tenant’s workload runs on separate infrastructure, there is no shared compute between tenants.

Figure 3: Silo model with a dedicated runtime per tenant

How it works

Each tenant gets a dedicated AgentCore runtime, provisioned automatically (for example, with AWS CloudFormation or CDK) when a new customer is onboarded. Within that runtime, each user session runs in its own isolated microVM, so no process state is shared even between users of the same tenant. Access control is enforced through IAM resource-based policies attached to both the AgentCore runtime and its endpoint. The caller must hold explicit permission for their tenant’s specific runtime.

Advantages

• Maximum isolation: Dedicated compute per tenant with no shared process state. Each session runs in its own microVM, and tenants cannot reach each other’s infrastructure.
• Simple authorization model: IAM resource-based policies, applied to both the Runtime and its endpoint, are the sole enforcement point. No application-level routing logic required.
• Independent configuration: Each runtime can run a different agent version, model, or endpoint configuration without affecting other tenants.

Disadvantages

• Scale limitations: The default quota is 1,000 agents per AWS account (adjustable through Service Quotas), which requires capacity planning for large customer bases.
• Provisioning latency: Each new tenant requires creating a dedicated Runtime and endpoint, introducing onboarding delays compared to a shared-runtime model.
• Operational overhead: Monitoring, updating, and managing hundreds of runtimes adds operational complexity that demands robust automation (for example, CDK/CloudFormation pipelines, centralized observability).

Solution overview

Axonius operates today in a siloed mode and chooses to continue with that approach when adding agents. Each customer has a dedicated agent. Axonius designed a multi-tenant agentic AI architecture using Amazon Bedrock and AgentCore with the following key components:

• AgentCore runtime – Axonius deploys a dedicated agent for each customer, and each user session runs on an isolated microVM, using AgentCore runtime.
• Amazon Elastic Container Registry (Amazon ECR) – Stores per-tenant agent container images.
• Amazon Bedrock – Powers the underlying foundation models (FMs), with IAM role tagging for cost allocation.
• Amazon Bedrock Knowledge Bases (KB) – Axonius uses Amazon Bedrock Knowledge Bases (KB) with Amazon S3 Vectors because of their cost efficiency and ability to scale. Axonius uses metadata filtering to isolate tenant-specific data.
• Amazon Bedrock Guardrails – Provides content filtering and topic denial policies. Guardrails are applied to every model response, keeping responses safe and in scope before they are shared with the user.
• Amazon CloudWatch – Monitors the overall workload and is instrumental in cost control. It tracks token consumption metrics (input/output), issuing alerts and using IAM-deny enforcement for cost governance. If a customer exceeds their token budget, an automated IAM policy blocks further invocations.
• Amazon VPC Lattice – Allows Axonius to manage cost-efficient private connectivity, connecting AgentCore runtime, customer VPCs, and AWS service endpoints.

The architecture uses AWS CloudFormation for automated per-customer provisioning and teardown, allowing Axonius to scale agent deployments across their customer base.

Figure 4: Axonius multi-tenant agentic architecture on Amazon Bedrock AgentCore

Why Amazon Bedrock AgentCore runtime?

After evaluating multiple approaches, including running agents as additional containers within their existing EC2 instances, Axonius chose Amazon Bedrock AgentCore runtime. Its purpose-built capabilities directly addressed their multi-tenant SaaS requirements.

• Session isolation with microVMs – AgentCore runtime’s session isolation was the decisive factor. Each user session runs in a dedicated microVM with isolated CPU, memory, and filesystem resources. After session completion, the entire microVM is terminated and memory is sanitized. This deterministic security model was critical for Axonius, where each customer’s data, including sensitive cybersecurity asset inventories, must remain completely isolated.
• Framework flexibility and VPC integration – AgentCore runtime’s framework-agnostic design allowed Axonius to deploy agents using their preferred tooling while connecting securely to their existing VPC infrastructure. Each agent connects through an ENI to the customer’s VPC, allowing direct interaction with the Axonius application APIs running inside the isolated EC2 instances.
• Built-in observability – The built-in observability capabilities gave Axonius the visibility they needed without building custom monitoring infrastructure. These capabilities include CloudWatch integration for logging, AWS X-Ray for distributed tracing, and agent-specific tracing that captures reasoning steps and tool invocations.

User session flow

Each customer runs their own Axonius deployment on a dedicated workload inside their own VPC. Every customer also gets a dedicated AgentCore runtime: a per-customer agent that reasons with Claude, pulls product knowledge from an Amazon Bedrock Knowledge Base, and reaches back into that customer’s Axonius API to answer data questions. Customers have a chat box that allows them to write questions. The following flow traces a customer question, for example, “ Are there any major changes in my asset count compared to last week? ”

1. Authentication: The user is already signed in to Axonius on their own instance. When they send a chat message, the Axonius application authenticates the request and mints a short-lived impersonation JWT carrying the user’s identity, tenant ID, session ID, and actor ID. This token, rather than a static credential, authorizes everything downstream.
2. Runtime invocation : The Axonius application control plane assembles the invocation payload and calls InvokeAgentRuntime on the customer’s dedicated AgentCore runtime. The payload carries only tenant configuration: the AgentCore Memory ID, Knowledge Base and data-source IDs, AWS Region, current Axonius version, and the callback address for the customer’s own instance. The JWT rides in a custom AgentCore header rather than in the body, so authentication material does not land in the agent’s saved state, and the session and actor IDs scope the call to one user’s conversation.
3. Dedicated, isolated runtime : Each customer has its own AgentCore runtime, and that runtime is attached to a dedicated elastic network interface (ENI) placed inside the customer’s own VPC and subnet. AgentCore creates an isolated session, validates the JWT back against the customer’s Axonius application (signature, expiry, revocation, and permissions), and scopes the reasoning to that single tenant. An invalid token is rejected before the model runs.
4. Agent reasoning with Claude : The team’s existing LangGraph supervisor inspects the question and routes it to the right specialist agent. The specialist uses Amazon Bedrock to analyze the question, deciding at each step whether it can respond directly, needs product documentation, or needs live data from the customer’s environment. For model availability by Region, refer to Supported models by AWS Region in Amazon Bedrock.
5. Knowledge retrieval: When the question is about how Axonius works, the agent retrieves relevant passages from a Bedrock Knowledge Base. That knowledge base is kept current by uploading the latest Axonius documentation to Amazon Simple Storage Service (Amazon S3) and syncing it, so responses reflect the customer’s running version.
6. Tool access into the customer’s Axonius API : When the question needs live data, such as “Give me a high-level summary of all assets discovered in the last 24 hours,” the agent invokes its query tool, which:
   1. Uses the Knowledge Base and large language model (LLM) to translate the natural-language question into an Axonius Query Language (AQL) expression.
   2. Reaches the customer’s Axonius application instance through the runtime’s dedicated ENI, so the traffic stays inside the customer’s VPC and doesn’t leave the AWS network. It compiles the query and fetches the matching assets, carrying the same JWT, so the agent can only ever see data the user is already allowed to see.
   3. Returns the results to the agent, which reasons over them to compose the response.
7. Guardrails and response : Amazon Bedrock Guardrails are applied server-side to every model response, keeping responses safe and on scope before they leave Amazon Bedrock. The agent’s answer streams back token by token through the runtime to the chat UI, and the exchange is persisted in AgentCore Memory so follow-up questions keep context.

Tenant isolation and private networking

The whole design rests on strict per-customer isolation and private connectivity:

• Dedicated runtime per customer: Every customer gets its own AgentCore runtime with its own ENI inside their VPC and subnet, so one customer’s agent has no network path to another customer’s data.
• In-network access to customer data: Because the ENI lives in the customer’s VPC, the runtime reaches the internal Axonius EC2 instance over private addressing. That traffic doesn’t traverse the public internet and does not leave the AWS network.
• Shared AWS services over Amazon VPC Lattice: A dedicated Axonius services VPC publishes the AWS services the runtime depends on (Amazon ECR, Amazon S3, Amazon Bedrock, and others) through a set of private endpoints, shared with each customer VPC through VPC Lattice. This lets the AgentCore runtime pull the agent container image from Amazon ECR and reach Amazon Bedrock and the Knowledge Base privately, while restricting access so that only the customer VPC and its runtime can reach those services.
• Networking cost efficiency: Amazon VPC Lattice allows Axonius to define one private endpoint per AWS service, reducing cost and management overhead. With AWS PrivateLink, Axonius would have needed to define a private endpoint per VPC per service.

Together, this keeps a clean trust boundary: the reasoning, knowledge retrieval, and guardrails run on Amazon Bedrock. The authoritative data and identity stay on each customer’s own VPC. And every hop between them travels private AWS networking. The agent does not hold long-lived credentials. It borrows the user’s JWT for the life of a request, and every session, memory, tool call, and network path is scoped to a single tenant.

Token governance and cost management

A notable aspect of Axonius’s implementation is their approach to token governance:

• CloudWatch metrics track sum of input and output tokens per agent. In addition, Axonius uses opentelemetry-instrument to get real-time token usage.
• IAM role tagging (using Amazon Bedrock cost allocation by IAM user/role feature) allows per-tenant cost attribution.
• Automated IAM-deny policies can be triggered by using CloudWatch alarms to block runaway agent usage.
• Application Inference Profiles per model allow granular tagging, alerting, and cost control through Amazon EventBridge.

This approach provides cost allocation visibility updated once or twice daily, with real-time alerting through CloudWatch for immediate enforcement.

Conclusion

ISVs are in the process of developing agentic AI workloads. This post describes possible avenues and Axonius’s chosen solution, using Amazon Bedrock and AgentCore as the foundation for its agentic AI offering.

By using the AgentCore managed runtime, Knowledge Bases for RAG, and built-in session memory, Axonius reduced the development cycle for their multi-tenant AI agent from an estimated eight weeks of custom infrastructure work to only 10 days of production-ready deployment, a 75 percent reduction in time-to-market.

“AgentCore Runtime gave us the multi-tenant isolation and authentication framework we needed to deploy AI agents across large numbers of customer environments without compromising our security-first architecture.”

— Dori Shmuel, SaaS DevOps Lead, Axonius

To learn more about building multi-tenant AI agents with Amazon Bedrock AgentCore runtime, we recommend you review these additional resources:

---

About the authors

Amir Krispin

Amir is a Senior Technical Account Manager at Amazon Web Services with over 20 years of experience leading product management for cloud offerings. He helps ISV customers run reliably and cost-efficiently on AWS through architecture reviews and guidance on emerging technologies and led the cross-team collaboration behind this post. Outside of work, Amir enjoys downhill mountain biking and exploring new destinations worldwide.

Yaakov Tayeb

Yaakov is a Senior GenAI Specialist Solutions Architect at AWS in Tel Aviv, Israel, on the Worldwide Specialist Organization’s AI/ML GTM team. He helps customers across EMEA design and scale generative AI workloads, with a focus on agentic architectures, cost optimization, token governance and production-readiness services such as Amazon Bedrock and AgentCore.

Yossi Lagstein

Yossi is a Senior Solutions Architect at Amazon Web Services. Yossi has over 30 years of experience as a specialist and manager in developing infrastructure components for a variety of projects and products. Yossi supports AWS customers to evolve, design, and build well architected solutions. Outside of work, Yossi enjoys running, swimming and hiking.

Dori Shmuel

Dori is the DevOps Team Lead at Axonius, the cybersecurity asset intelligence platform. He leads the team responsible for Axonius’s cloud infrastructure and platform reliability and drove the architecture decisions behind Axonius’s adoption of Amazon Bedrock AgentCore, including the networking and image-delivery optimizations covered here.

Omar Sawara

Omar is a Senior DevOps Engineer at Axonius, where he builds and operates the cloud infrastructure powering the company’s platform. He focuses on scalable, cost-efficient deployments on AWS and worked on the AgentCore cost analysis and optimization efforts featured in this post.