8.0
热点
AI SCORE
技术实践2026-08-19 00:27
Axonius多租户AI Agent隔离方案实践
AWS ML Blog#AWS Bedrock#Agent#多租户
Editor brief · 编辑速览
基于Bedrock AgentCore实现数百客户环境间的完全隔离部署，无需自建计算隔离、认证和可观测性基础设施。
独立软件供应商（ISV）正在扩展其产品线并引入 AI 智能体。组织在引入智能体工作时需要考虑的主要因素包括安全性、可扩展性、上市时间和成本核算。ISV 还有一个额外的维度——他们向其他组织提供服务，需要为每个客户管理智能体工作负载。因此，ISV 需要在全局层面和租户层面同时管理这些共同的挑战。
Axonius 是一个资产情报平台，帮助安全和 IT 团队优先处理风险并协调修复工作。通过将来自 1400 多个系统的数据协调到一个权威的可信数据源中，Axonius 使安全团队及其支持的团队能够有效协作，将安全、审计和合规的手动工作量减少高达 50%。Axonius 在 AWS 上以软件即服务（SaaS）基础设施模式运行，管理着数百个隔离的客户环境。
Amazon Bedrock AgentCore 是一个用于大规模构建、连接和优化智能体的平台，支持任何框架或模型。在这篇文章中，我们涵盖 SaaS 供应商部署 AI 智能体的可用策略，描述 Amazon Bedrock AgentCore 如何支持这些选项，深入了解 Axonius 的考量因素，并分享 Axonius 选择的架构。我们还描述了 Axonius 如何将其智能体工作负载与现有方法论集成。这篇文章面向在 AWS 上构建安全、多租户 AI 智能体部署的平台工程师和架构师。
独立软件供应商（ISV）倾向于使用 SaaS 模式提供服务。在选择架构时，ISV 有三种常见的架构模式：隔离（silo）、桥接（bridge）和池化（pool）。以下各节将详细说明当我们在 Amazon Bedrock AgentCore 中审视智能体 AI 时，每种模式意味着什么。
隔离模式指为租户提供专用资源的架构。从 AgentCore 运行时来看，这意味着每个租户使用一个专用智能体。池化模式下，租户共享资源，一个智能体为多个租户提供服务。在 AgentCore 运行时中，您可以通过为每个用户会话分配唯一的会话 ID 来隔离每个用户会话。第三种模式是桥接模式，其中某些组件处于隔离模式，而其他组件处于池化模式。例如，我们可以使用共享的 Amazon Bedrock Knowledge Bases（一个 AWS 托管的检索增强生成（RAG）服务）将专用智能体部署到 AgentCore 运行时中。
Axonius 希望为其产品添加 AI 智能体。他们的第一个 AI 智能体可以解读大型企业环境的状态，识别差距和风险，并利用 AI 分析和理解来自数十个并发集成源的数百万数据点。这一举措使初级分析师能够执行复杂分析，而无需让高级分析师投入数小时的手动工作。Axonius 选择维持其当前的租户管理方法论。
Axonius 的 SaaS 部署模式是隔离模式。每个客户工作负载驻留在一个专用的 Amazon Virtual Private Cloud（Amazon VPC）中。该 VPC 包含一个 Application Load Balancer（ALB）、Network Load Balancer（NLB）、数据库和通用计算基础设施。
Axonius 希望在保持隔离部署模式的同时引入 AI 智能体。Axonius 需要解决几个关键需求：
租户隔离 – Axonius 处理敏感的客户数据。为一个客户服务的智能体必须仅限于该客户的数据范围。
身份认证 – 现有服务在分配给租户的 Amazon Elastic Compute Cloud（Amazon EC2）上有一个身份认证和授权模块。Axonius 需要将智能体的身份流程与现有模块集成，且不造成中断。
成本追踪 – 智能体成本可能会失控。大部分成本在于模型调用，因此按租户追踪模型成本至关重要。了解成本对于考虑智能体产品的定价方案至关重要。
与服务集成 – 与租户关联的智能体实例需要安全访问该租户工作负载的 API。
生命周期管理 – 将智能体工作负载添加到当前的隔离持续交付（CD）工作流程中。
可观测性 – 使用隔离模式，Axonius 将有大量智能体。DevOps 团队需要高质量、易于集成的可观测性功能，能够追踪大量智能体集群，在出现问题时发出警报，并提供追踪能力来调试问题。
以下各节涵盖了 Axonius 评估的选项及其选择。
在租户部署模式的探索上，Axonius 考虑了以下选项。
AgentCore 运行时通过为每个会话分配专用 microVM 来强制执行结构化隔离。单个运行时为租户提供服务，同时通过应用层控制保持完整的租户隔离。
租户通过 OAuth 2.0 身份提供商（例如 Amazon Cognito）进行身份认证，JWT 携带唯一的租户声明（例如 custom:tenant_id）。运行时的内置 JWT 授权者使用配置的发现 URL 获取公钥并验证令牌颁发者。然后智能体代码读取该声明，以将工具调用和数据访问路由到正确的租户环境。
图 1：具有单一共享运行时和基于 JWT 的租户路由的池化模型
运营简洁性：只需部署、监控和更新一个运行时。
快速上线：新客户可以立即上线，无需配置基础设施，减少了价值实现时间。
应用依赖的隔离：租户隔离完全依赖于应用代码。
同质化部署：按租户的自定义需要额外的条件逻辑。
一种混合方法，将单一共享运行时的运营简洁性与工具层的基础设施级租户强制执行相结合，通过 AgentCore Gateway 实现。租户共享一个运行时，但每个出站工具调用都经过一个 Gateway，该 Gateway 在工具代码执行之前强制执行租户边界。
租户连接到同一个 AgentCore 运行时，该运行时使用专用 microVM 进行每个会话的计算隔离，与选项 1 相同。不同之处在于每个工具调用都通过一个共享的 AgentCore Gateway 路由，该 Gateway 有两种强制执行机制：
Amazon Bedrock AgentCore 中的策略 – 确定性访问控制。Cedar 规则根据调用者的身份属性（例如 Cognito 组声明）评估每个工具调用，并产生允许/拒绝决定。forbid 规则可以阻止特定租户组调用受限工具。
AWS Lambda 拦截器（REQUEST） – 动态验证和上下文丰富。在工具调用到达目标之前运行，提取 JWT，查找租户上下文，并通过 STS AssumeRole（"代表行事"模式）将令牌交换为短期、租户范围的 IAM 凭证。下游工具接收这些最小权限凭证，而不是原始 JWT。
Gateway 在 Cedar 策略之前评估拦截器，使拦截器能够丰富策略随后评估的请求上下文。
RESPONSE 拦截器还可以根据租户身份过滤工具发现。
这意味着两个独立的机制在基础设施层（智能体代码之外）强制执行租户隔离。
图 2：具有共享运行时和网关强制工具隔离的桥接模型
分层基础设施强制执行：即使智能体代码有路由错误，Gateway 也会阻止跨租户工具调用。Cedar 策略（确定性）和 Lambda 拦截器（动态）提供了纵深防御。
集中治理：一个 Gateway 即可跨所有工具调用审计和强制执行租户策略，每个决策都记录到 Amazon CloudWatch。
共享效率：运行时、知识库和可观测性基础设施集中管理，不共享安全风险。
设置复杂性：需要配置 Gateway、REQUEST/RESPONSE 拦截器 Lambda、租户映射、Cedar 策略和 STS 角色信任关系。这比选项 1 或 3 添加了更多的移动部件。
VPC 连接：后端工具通常驻留在 VPC 中，需要 VPC 端点进行私有 Gateway 连接，这增加了网络复杂性并可能带来故障点。
在隔离模式下，每个租户在专用 AgentCore 运行时上运行。访问控制完全通过 AWS Identity and Access Management（IAM）强制执行。运行时及其端点上的基于资源的策略决定哪些委托者（无论是同账户角色还是跨账户身份）允许调用智能体。因为每个租户的工作负载运行在独立的基础设施上，所以租户之间没有共享计算。
图 3：每个租户专用运行时的隔离模型
每个租户获得一个专用的 AgentCore 运行时，在新客户入驻时自动配置（例如使用 AWS CloudFormation 或 CDK）。在该运行时内，每个用户会话运行在各自独立的 microVM 中，因此即使同一租户的不同用户之间也不会共享进程状态。访问控制通过附加到 AgentCore 运行时及其端点的 IAM 资源策略来强制执行。调用方必须持有其租户特定运行时的明确权限。
最大隔离性：每个租户专用计算资源，无共享进程状态。每个会话在各自的 microVM 中运行，租户之间无法访问彼此的基础设施。
简单的授权模型：应用于运行时及其端点的 IAM 资源策略是唯一的强制执行点。无需应用层路由逻辑。
独立配置：每个运行时可以运行不同版本的智能体、模型或端点配置，不影响其他租户。
规模限制：默认配额为每个 AWS 账户 1,000 个智能体（可通过 Service Quotas 调整），这需要对大型客户群进行容量规划。
配置延迟：每个新租户需要创建专用运行时和端点，与共享运行时模型相比，会带来入驻延迟。
运营开销：监控、更新和管理数百个运行时增加了运营复杂性，需要强大的自动化（例如 CDK/CloudFormation 流水线、集中式可观测性）。
Axonius 目前以隔离模式运行，在添加智能体时选择继续采用这种方法。每个客户拥有专用的智能体。Axonius 使用 Amazon Bedrock 和 AgentCore 设计了多租户智能体 AI 架构，包含以下关键组件：
AgentCore 运行时 – Axonius 为每个客户部署专用智能体，每个用户会话在隔离的 microVM 上运行，使用 AgentCore 运行时。
Amazon Elastic Container Registry (Amazon ECR) – 存储每个租户的智能体容器镜像。
Amazon Bedrock – 为底层基础模型（FM）提供支持，并带有用于成本分配的 IAM 角色标签。
Amazon Bedrock Knowledge Bases (KB) – Axonius 使用 Amazon Bedrock Knowledge Bases (KB) 配合 Amazon S3 Vectors，因其成本效益和可扩展性。Axonius 使用元数据过滤来隔离租户特定数据。
Amazon Bedrock Guardrails – 提供内容过滤和主题拒绝策略。护栏应用于每个模型响应，在与用户分享之前保持响应安全且在范围内。
Amazon CloudWatch – 监控整体工作负载，在成本控制中发挥重要作用。它跟踪令牌消耗指标（输入/输出），发出警报并使用 IAM 拒绝策略进行成本治理。如果客户超过令牌预算，自动化 IAM 策略会阻止进一步调用。
Amazon VPC Lattice – 允许 Axonius 管理经济高效的私有连接，连接 AgentCore 运行时、客户 VPC 和 AWS 服务端点。
该架构使用 AWS CloudFormation 进行自动化的按客户配置和拆除，使 Axonius 能够在其客户群中扩展智能体部署。
为什么选择 Amazon Bedrock AgentCore 运行时？
在评估多种方法（包括在其现有 EC2 实例中作为额外容器运行智能体）之后，Axonius 选择了 Amazon Bedrock AgentCore 运行时。其专为构建的功能直接满足了他们的多租户 SaaS 需求。
使用 microVM 进行会话隔离 – AgentCore 运行时的会话隔离是决定性因素。每个用户会话在具有隔离 CPU、内存和文件系统资源的专用 microVM 中运行。会话完成后，整个 microVM 被终止，内存被清理。这种确定性安全模型对 Axonius 至关重要，因为每个客户的数据（包括敏感的网络安全资产清单）必须保持完全隔离。
框架灵活性与 VPC 集成 – AgentCore 运行时的框架无关设计允许 Axonius 使用他们首选的工具部署智能体，同时安全地连接到他们现有的 VPC 基础设施。每个智能体通过 ENI 连接到客户的 VPC，允许与在隔离 EC2 实例内运行的 Axonius 应用程序 API 直接交互。
内置可观测性 – 内置的可观测性能力为 Axonius 提供了所需的可见性，而无需构建自定义监控基础设施。这些能力包括用于日志记录的 CloudWatch 集成、用于分布式追踪的 AWS X-Ray，以及捕获推理步骤和工具调用的智能体特定追踪。
每个客户在他们自己 VPC 内的专用工作负载上运行自己的 Axonius 部署。每个客户还获得专用的 AgentCore 运行时：一个按客户的智能体，使用 Claude 进行推理，从 Amazon Bedrock Knowledge Base 中提取产品知识，并返回到该客户的 Axonius API 回答数据问题。客户有一个聊天框，允许他们书写问题。以下流程追踪一个客户问题，例如："与上周相比，我的资产数量有重大变化吗？"
认证：用户已在自己实例上登录 Axonius。当他们发送聊天消息时，Axonius 应用程序对请求进行认证，并生成一个短期模拟 JWT，携带用户的身份、租户 ID、会话 ID 和执行者 ID。这个令牌（而非静态凭证）为下游所有操作授权。
运行时调用：Axonius 应用程序控制平面组装调用有效载荷，并在客户的专用 AgentCore 运行时上调用 InvokeAgentRuntime。该有效载荷仅携带租户配置：AgentCore Memory ID、Knowledge Base 和数据源 ID、AWS 区域、当前 Axonius 版本以及客户自己实例的回调地址。JWT 位于自定义 AgentCore 头中而非正文中，因此认证材料不会落入智能体的保存状态，会话和执行者 ID 将调用限定为单个用户的对话。
专用隔离运行时：每个客户都有自己的 AgentCore 运行时，该运行时连接到放置在客户自己 VPC 和子网内的专用弹性网络接口（ENI）。AgentCore 创建一个隔离会话，针对客户的 Axonius 应用程序对 JWT 进行验证（签名、过期、撤销和权限），并将推理限定为该单一租户。无效令牌在模型运行之前就被拒绝。
使用 Claude 进行智能体推理：团队现有的 LangGraph 监督器检查问题并将其路由到正确的专业智能体。该专业智能体使用 Amazon Bedrock 分析问题，在每一步决定是否可以直接回答、需要产品文档，还是需要来自客户环境的实时数据。关于模型在各区域的可用性，请参阅 Amazon Bedrock 中的按 AWS 区域支持的模型。
知识检索：当问题是关于 Axonius 如何工作时，智能体从 Bedrock Knowledge Base 中检索相关段落。该知识库通过将最新 Axonius 文档上传到 Amazon Simple Storage Service (Amazon S3) 并同步来保持最新，因此响应反映了客户运行的版本。
访问客户 Axonius API 的工具：当问题需要实时数据时，例如"给我过去 24 小时内发现的所有资产的高级摘要"，智能体会调用其查询工具，该工具：
护栏与响应：Amazon Bedrock Guardrails 在服务端应用于每个模型响应，在响应离开 Amazon Bedrock 之前确保其安全且在范围内。智能体的回答通过运行时逐 token 流式传回聊天 UI，对话内容持久化到 AgentCore Memory 中，使后续问题能够保持上下文。
租户隔离与私有网络
整个架构建立在严格的每客户隔离和私有连接之上：
每个客户专用运行时：每个客户在其 VPC 内的自有 ENI 中获得独立的 AgentCore 运行时，因此一个客户的智能体无法访问另一客户的数据网络路径。
客户数据的网络内访问：由于 ENI 存在于客户的 VPC 中，运行时通过私有地址访问 Axonius 内部 EC2 实例。该流量不经过公共互联网，也不会离开 AWS 网络。
通过 Amazon VPC Lattice 共享 AWS 服务：一个专用的 Axonius 服务 VPC 通过一组私有端点发布运行时依赖的 AWS 服务（Amazon ECR、Amazon S3、Amazon Bedrock 等），并通过 VPC Lattice 与每个客户 VPC 共享。这使得 AgentCore 运行时可以从 Amazon ECR 拉取智能体容器镜像，并私密地访问 Amazon Bedrock 和 Knowledge Base，同时限制访问权限，确保只有客户 VPC 及其运行时可以访问这些服务。
网络成本效率：Amazon VPC Lattice 允许 Axonius 为每个 AWS 服务定义一个私有端点，降低了成本和管理开销。若使用 AWS PrivateLink，Axonius 需要为每个 VPC 每项服务定义一个私有端点。
这一切共同维护了一个清晰的信任边界：推理、知识检索和护栏运行在 Amazon Bedrock 上。权威数据和身份保留在每个客户自己的 VPC 中。它们之间的每一跳都通过私有 AWS 网络传输。智能体不持有长期凭证。它在请求生命周期内借用用户的 JWT，每个会话、内存、工具调用和网络路径都限定在单一租户范围内。
Token 治理与成本管理
Axonius 实现方案的一个显著特点是其 Token 治理方法：
CloudWatch 指标追踪每个智能体的输入和输出 token 总数。此外，Axonius 使用 opentelemetry-instrumentation 获取实时 token 使用量。
IAM 角色标签（利用 Amazon Bedrock 按 IAM 用户/角色分配成本的功能）支持按租户进行成本归属。
自动化 IAM-deny 策略可以通过 CloudWatch 告警触发，以阻止失控的智能体使用。
每个模型的 Application Inference Profiles 允许通过 Amazon EventBridge 进行细粒度标签、告警和成本控制。
该方法提供了每日更新一至两次的成本分配可见性，并通过 CloudWatch 实现实时告警以便即时执行。
ISV 正在积极开发智能体 AI 工作负载。本文描述了可行的路径以及 Axonius 的选择方案——以 Amazon Bedrock 和 AgentCore 为基础构建其智能体 AI 产品。
通过使用 AgentCore 托管运行时、Knowledge Bases for RAG 以及内置的会话内存，Axonius 将多租户 AI 智能体的开发周期从预计八周的定制基础设施工作缩短到仅需十天的生产级部署，时间缩短了 75%。
「AgentCore Runtime 为我们提供了多租户隔离和身份验证框架，使我们能够在大量客户环境中部署 AI 智能体，而不影响我们的安全优先架构。」
—— Dori Shmuel，Axonius SaaS DevOps Lead
要了解更多关于使用 Amazon Bedrock AgentCore runtime 构建多租户 AI 智能体的信息，我们推荐你查阅以下资源：
Amazon Bedrock AgentCore runtime 文档
Amazon Bedrock AgentCore 入门 Workshop
AgentCore 可观测性配置