2026年8月18日，AWS Machine Learning Blog 发布文章，介绍网络安全资产智能平台 Axonius 如何借助 Amazon Bedrock AgentCore 构建面向 SaaS 客户的多租户 AI 智能体。Axonius 延续原有的隔离式部署方式，为每个客户配置独立的 AgentCore Runtime，并将客户工作负载放在各自隔离的 AWS 环境中。
这套方案的重点并不是简单接入基础模型，而是把智能体纳入既有的租户管理体系。Axonius需要同时解决以下问题：
- 租户隔离：智能体只能访问对应客户的数据。
- 身份衔接：与部署在客户环境中的现有认证和授权模块集成。
- 成本追踪：按租户统计模型调用和 Token 成本。
- 服务集成：让智能体安全访问对应客户工作负载中的 API。
- 生命周期管理：将智能体部署纳入现有的隔离式持续交付流程。
- 可观测性：支持大规模智能体集群的监控、告警和链路追踪。
这些要求决定了 Axonius 需要同时管理计算隔离、身份校验、网络访问和成本治理，而不是只依靠应用层的租户路由逻辑。
AWS文章将多租户智能体架构概括为三种模式：pool、bridge 和 silo。Pool 模式由共享 Runtime 服务多个租户，通过 JWT 中的租户声明在应用层完成路由；Bridge 模式同样共享 Runtime，但将工具调用交给 AgentCore Gateway，并结合 Cedar 策略和 Lambda 拦截器，在基础设施层执行租户边界；Silo 模式则为每个租户配置独立 Runtime，主要依靠 IAM 资源策略控制访问。
Axonius最终选择了 Silo 模式。其架构包括：为每个客户部署独立 AgentCore Runtime；使用 Amazon ECR 保存租户对应的智能体容器镜像；通过 Amazon Bedrock 调用基础模型，并利用 IAM 角色标签进行成本归属；使用 Amazon Bedrock Knowledge Bases 与 Amazon S3 Vectors 保存产品知识，并通过元数据过滤隔离租户数据；通过 Amazon Bedrock Guardrails 对每次模型响应执行内容过滤和主题限制；利用 Amazon CloudWatch 追踪 Token 使用量、触发告警，并在超出预算时通过 IAM 拒绝策略阻止后续调用；最后使用 Amazon VPC Lattice 连接 Runtime、客户 VPC 与相关 AWS 服务。Axonius还通过 AWS CloudFormation 自动完成每个客户环境的创建和拆除。
Axonius表示，选择 AgentCore Runtime 的关键原因是其会话隔离能力。每个用户会话都运行在独立的微型虚拟机中，拥有隔离的 CPU、内存和文件系统资源；会话结束后，微型虚拟机会被终止并清理内存。AgentCore Runtime 的框架无关设计也让 Axonius 能够继续使用现有工具链，并通过弹性网络接口连接客户 VPC。AWS文章还提到，AgentCore 提供了与 CloudWatch、AWS X-Ray 以及智能体专用追踪能力的集成，可记录推理步骤和工具调用。
在一次用户请求中，身份和数据访问链路大致如下：
- 用户在自己的 Axonius 实例中登录并发起问题，应用为请求生成短期 impersonation JWT，其中包含用户身份、租户 ID、会话 ID 和操作者 ID。
- Axonius 控制平面调用对应客户的 AgentCore Runtime，传递该租户的 Memory、Knowledge Base、数据源、区域和回调地址等配置。
- JWT 放在自定义 AgentCore 请求头中，而不是请求体内，以避免认证材料进入智能体保存的状态。
- Runtime 在模型运行前，回到客户应用验证 JWT 的签名、有效期、撤销状态和权限，并在隔离的微型虚拟机中处理会话。
- 现有的 LangGraph supervisor 根据问题选择专业智能体。智能体可以调用 Bedrock 中的 Claude，决定直接回答、检索产品文档，或访问客户环境中的实时数据。
- 当请求涉及实时资产数据时，智能体将自然语言转换为 Axonius Query Language 查询，通过客户 VPC 内的专用网络接口访问对应 API，并继续携带用户 JWT。
- 模型响应在离开 Amazon Bedrock 前经过 Guardrails 处理，随后通过 Runtime 流式返回聊天界面，并保存到 AgentCore Memory 以支持后续追问。
这一流程让知识检索、实时数据访问和身份权限保持在同一个租户边界内。
网络设计是该方案的另一层隔离机制。每个客户的 AgentCore Runtime 都通过专用网络接口连接到客户自己的 VPC 和子网，访问内部 Axonius EC2 实例时使用私有地址，流量不经过公共互联网。Axonius还通过一个服务 VPC 发布 ECR、S3、Bedrock 等服务的私有端点，再借助 VPC Lattice 与各客户 VPC 共享连接。AWS文章称，这种方式可以按 AWS 服务定义私有端点，避免使用 PrivateLink 时为每个 VPC 和每项服务分别配置端点。
在 Token 治理方面，Axonius使用 CloudWatch 统计每个智能体的输入和输出 Token，并通过 opentelemetry-instrument 获取实时使用情况。IAM 角色标签用于按租户归属成本，CloudWatch 告警可以触发自动 IAM 拒绝策略，阻止失控调用；不同模型的 Application Inference Profiles 则用于更细粒度的标记、告警和成本控制。AWS文章称，成本归属数据通常每天更新一到两次，而 CloudWatch 可以提供实时告警和即时限制。
按照AWS文章披露的口径，Axonius借助 AgentCore Runtime、Knowledge Bases 和会话记忆能力，将原本估算需要八周的定制基础设施开发压缩到 10 天的生产就绪部署，文章将其描述为上市时间减少 75%。从这套架构可以看出，Axonius的取舍是用每租户独立 Runtime 换取更清晰的隔离边界和授权模型，同时接受更多 Runtime 的 provisioning、配额和运维管理工作。