Axonius 如何在 Bedrock AgentCore 上构建安全的多租户 AI 代理

独立软件供应商（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代理部署的平台工程师和架构师。

AI代理的多租户模式

独立软件供应商（ISV）倾向于使用SaaS模式提供服务。在选择架构时，ISV有三种常见的架构模式：竖井模式（silo）、桥接模式（bridge）和池化模式（pool）。以下各节将详细说明在使用Amazon Bedrock AgentCore构建代理型AI时，每种模式的含义。

竖井模式指的是一种为租户提供专用资源的架构。就AgentCore运行时而言，这意味着为每个租户使用专用代理。在池化模式下，租户共享资源，一个代理服务多个租户。使用AgentCore运行时，您可以通过为每个用户会话分配唯一的会话ID来隔离每个用户会话。第三种模式是桥接模式，其中某些组件采用竖井模式，而其他组件采用池化模式。例如，我们可以将专用代理部署到AgentCore运行时中，同时使用共享的Amazon Bedrock Knowledge Bases——一种AWS托管的检索增强生成（RAG）服务。

挑战

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评估了以下选项。

选项1：池化模式——共享运行时与基于JWT的租户路由

AgentCore运行时通过为每个会话分配专用的microVM来实施结构性隔离。单个运行时服务多个租户，同时通过应用层控制保持完全的租户隔离。

工作原理

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

优势

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

劣势

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

选项 2：Bridge——共享运行时加网关强制工具隔离

这种混合方法结合了单一共享运行时的运维简单性，以及通过 AgentCore Gateway 在工具层实施基础设施级租户强制隔离的能力。租户共享一个运行时，但每次出站工具调用都会先经过一个网关，该网关在工具代码执行前强制实施租户边界。

租户连接到同一个 AgentCore 运行时，该运行时为每个会话使用专用的 microVM 进行计算隔离，与选项 1 相同。不同之处在于，每次工具调用都会通过一个共享的 AgentCore Gateway 进行路由，该网关具有两种强制机制：

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

Gateway 在 Cedar 策略之前评估拦截器，使拦截器能够丰富请求上下文，然后策略再对该上下文进行评估。

RESPONSE 拦截器还可以根据租户身份额外过滤工具发现结果。

这意味着两个独立机制在基础设施层（代理代码之外）强制实施租户隔离。

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

• 设置复杂：需要配置 Gateway、REQUEST/RESPONSE 拦截器 Lambda、租户映射、Cedar 策略和 STS 角色信任关系。这比选项 1 或 3 增加了更多的活动部件。
• VPC 连接：后端工具通常位于 VPC 中，需要 VPC 端点来实现 Gateway 的私有连接，这增加了网络复杂性并引入了潜在的故障点。

选项 3：Silo——每个租户专用运行时

在 silo 模型中，每个租户在专用的 AgentCore 运行时上运行。访问控制完全通过 AWS Identity and Access Management（IAM）强制执行。运行时及其端点上的基于资源的策略决定了哪些主体（无论是同账户角色还是跨账户身份）被允许调用该代理。由于每个租户的工作负载运行在独立的基础设施上，租户之间没有共享计算。

每个租户获得一个专用的 AgentCore 运行时，在新客户接入时自动配置（例如使用 AWS CloudFormation 或 CDK）。在该运行时内，每个用户会话运行在各自隔离的 microVM 中，因此即使是同一租户的不同用户之间也不会共享进程状态。访问控制通过附加到 AgentCore 运行时及其端点上的 IAM 基于资源的策略强制执行。调用者必须对其租户的特定运行时拥有显式权限。

• 最大隔离：每个租户拥有专用计算，无共享进程状态。每个会话运行在各自的 microVM 中，租户之间无法访问彼此的基础设施。
• 简单的授权模型：应用于运行时及其端点的 IAM 基于资源的策略是唯一的强制点。无需应用层路由逻辑。
• 独立配置：每个运行时可以运行不同的代理版本、模型或端点配置，而不会影响其他租户。

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

解决方案概述

Axonius 目前以隔离模式运营，并在添加代理时选择继续采用这种方式。每个客户拥有一个专用代理。Axonius 使用 Amazon Bedrock 和 AgentCore 设计了一种多租户智能体 AI 架构，包含以下关键组件：

• AgentCore runtime – Axonius 为每个客户部署一个专用代理，每个用户会话在隔离的 microVM 上运行，使用 AgentCore runtime。
• Amazon Elastic Container Registry（Amazon ECR）– 存储每个租户的代理容器镜像。
• Amazon Bedrock – 为底层基础模型（FMs）提供支持，并通过 IAM 角色标记进行成本分配。
• Amazon Bedrock Knowledge Bases（KB）– Axonius 使用 Amazon Bedrock Knowledge Bases（KB）搭配 Amazon S3 Vectors，因为其成本效益高且可扩展。Axonius 使用元数据过滤来隔离租户特定数据。
• Amazon Bedrock Guardrails – 提供内容过滤和主题拒绝策略。Guardrails 应用于每个模型响应，确保在响应与用户共享之前保持安全且在范围内。
• Amazon CloudWatch – 监控整体工作负载，并在成本控制中发挥关键作用。它跟踪令牌消耗指标（输入/输出），发出警报，并使用 IAM-deny 强制执行进行成本治理。如果客户超过其令牌预算，自动化 IAM 策略将阻止进一步调用。
• Amazon VPC Lattice – 允许 Axonius 管理高性价比的私有连接，连接 AgentCore runtime、客户 VPC 和 AWS 服务端点。

该架构使用 AWS CloudFormation 实现每个客户的自动化预置和拆除，使 Axonius 能够在其客户群体中扩展代理部署。

为什么选择 Amazon Bedrock AgentCore runtime？

在评估了多种方法（包括在现有 EC2 实例中作为额外容器运行代理）之后，Axonius 选择了 Amazon Bedrock AgentCore runtime。其专用功能直接满足了他们的多租户 SaaS 需求。

• 使用 microVM 进行会话隔离 – AgentCore runtime 的会话隔离是决定性因素。每个用户会话在专用的 microVM 中运行，具有隔离的 CPU、内存和文件系统资源。会话结束后，整个 microVM 被终止，内存被清理。这种确定性的安全模型对 Axonius 至关重要，因为每个客户的数据（包括敏感的网络安全资产清单）必须完全隔离。
• 框架灵活性和 VPC 集成 – AgentCore runtime 的框架无关设计允许 Axonius 使用他们偏好的工具部署代理，同时安全地连接到他们现有的 VPC 基础设施。每个代理通过 ENI 连接到客户的 VPC，允许与运行在隔离 EC2 实例中的 Axonius 应用 API 直接交互。
• 内置可观测性 – 内置的可观测性功能为 Axonius 提供了所需的可见性，而无需构建自定义监控基础设施。这些功能包括用于日志记录的 CloudWatch 集成、用于分布式追踪的 AWS X-Ray，以及捕获推理步骤和工具调用的代理特定追踪。

用户会话流程

每个客户在自己的 VPC 内的专用工作负载上运行自己的 Axonius 部署。每个客户还获得一个专用的 AgentCore runtime：一个按客户划分的代理，使用 Claude 进行推理，从 Amazon Bedrock Knowledge Base 获取产品知识，并回连到该客户的 Axonius API 以回答数据问题。客户有一个聊天框，可以输入问题。以下流程追踪一个客户问题，例如：“与上周相比，我的资产数量是否有重大变化？”

1. 身份验证：用户已登录其自身的Axonius实例。当用户发送聊天消息时，Axonius应用会对请求进行身份验证，并生成一个携带用户身份、租户ID、会话ID和操作者ID的短期模拟JWT。该令牌而非静态凭据，用于授权下游所有操作。

1. 运行时调用：Axonius应用控制平面组装调用负载，并对客户专用的AgentCore运行时调用InvokeAgentRuntime。负载仅携带租户配置：AgentCore Memory ID、Knowledge Base和数据源ID、AWS区域、当前Axonius版本，以及客户自身实例的回调地址。JWT通过自定义的AgentCore标头而非请求体传递，因此身份验证材料不会落入代理的已保存状态中，同时会话ID和操作者ID将调用范围限定为单个用户的对话。

1. 专用隔离运行时：每个客户拥有自己的AgentCore运行时，该运行时挂载在置于客户自身VPC和子网内的专用弹性网络接口（ENI）上。AgentCore创建隔离会话，向客户的Axonius应用回验JWT（签名、有效期、撤销状态和权限），并将推理范围限定为单一租户。无效令牌在模型运行之前即被拒绝。

1. 使用Claude进行代理推理：团队现有的LangGraph监督器检查问题并将其路由到相应的专家代理。专家代理使用Amazon Bedrock分析问题，在每一步决定是直接回答、需要产品文档，还是需要来自客户环境的实时数据。关于各区域的模型可用性，请参阅Amazon Bedrock中按AWS区域划分的受支持模型。

1. 知识检索：当问题涉及Axonius的工作原理时，代理会从Bedrock Knowledge Base中检索相关段落。该知识库通过将最新的Axonius文档上传至Amazon Simple Storage Service（Amazon S3）并进行同步来保持更新，从而确保回答反映客户当前运行的版本。

1. 访问客户Axonius API的工具：当问题需要实时数据时（例如“给我过去24小时内发现的所有资产的高级摘要”），代理会调用其查询工具，该工具将：使用Knowledge Base和大语言模型（LLM）将自然语言问题转换为Axonius查询语言（AQL）表达式。通过运行时的专用ENI访问客户的Axonius应用实例，使流量保持在客户VPC内部，不离开AWS网络。编译查询并获取匹配的资产，同时携带相同的JWT，因此代理只能看到用户已被授权查看的数据。将结果返回给代理，代理基于这些结果进行推理并生成回答。

1. 护栏与响应：Amazon Bedrock Guardrails在服务端应用于每个模型响应，确保响应在离开Amazon Bedrock之前保持安全且在范围内。代理的回答通过运行时逐令牌流式返回至聊天界面，交互记录持久化在AgentCore Memory中，以便后续问题保持上下文。

租户隔离与私有网络

• 每客户专用运行时：每个客户拥有自己的AgentCore运行时，其ENI位于客户自己的VPC和子网内，因此一个客户的代理与另一个客户的数据之间不存在网络通路。
• 网络内访问客户数据：由于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，每个会话、记忆、工具调用和网络路径都限定在单一租户范围内。

令牌治理与成本管理

• CloudWatch 指标跟踪每个代理的输入和输出令牌总数。此外，Axonius 使用 opentelemetry-instrument 获取实时令牌使用情况。
• IAM 角色标签（利用 Amazon Bedrock 按 IAM 用户/角色进行成本分配的功能）支持按租户进行成本归属。
• 可通过 CloudWatch 告警触发自动 IAM 拒绝策略，以阻止代理失控使用。
• 每个模型的应用程序推理配置文件（Application Inference Profiles）允许通过 Amazon EventBridge 进行细粒度标记、告警和成本控制。

该方法提供每天更新一次或两次的成本分配可见性，并通过 CloudWatch 实现实时告警，以便立即执行管控。

结论

ISV 正在开发智能体 AI 工作负载。本文介绍了可能的途径以及 Axonius 所选用的解决方案，即以 Amazon Bedrock 和 AgentCore 作为其智能体 AI 产品的基础。

通过使用 AgentCore 托管运行时、用于 RAG 的 Knowledge Bases 以及内置会话记忆，Axonius 将其多租户 AI 代理的开发周期从预计八周的自定义基础设施工作缩短至仅 10 天的生产就绪部署，上市时间缩短了 75%。

“AgentCore Runtime 为我们提供了所需的多租户隔离和身份验证框架，使我们能够在大量客户环境中部署 AI 代理，同时不损害我们安全至上的架构。”

要了解有关使用 Amazon Bedrock AgentCore 运行时构建多租户 AI 代理的更多信息，我们建议您查阅以下其他资源：

• Amazon Bedrock AgentCore 运行时文档
• Amazon Bedrock AgentCore 入门工作坊
• AgentCore 可观测性配置

关于作者