待翻譯：How Axonius built secure multi-tenant AI agents on Bedrock AgentCore

AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。

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 application that helps Security and IT teams prioritize risks and coordinate fixes. By reconciling data from over 1,400 systems into one authoritative model of truth, the application automatically identifies security coverage gaps and enforces policies with precision. 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 streamlines user experiences and cuts time on tasks with AI recommendations, using AI to act as “another brain” for data management. This initiative allows junior analysts to generate and run complex queries and allows administrators to automate 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. Option 2: Bridge — shared runtime plus gateway-enforced tool isolation 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: 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. 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 [truncated for AI cost control]