对网络安全 SaaS 来说，让 AI Agent 服务多个客户，难点不只是调用模型。每个客户都有独立的数据、身份、工具权限和审计要求；一旦租户边界处理不严谨，一个 Agent 就可能成为跨客户访问的入口。
Axonius 采用 Amazon Bedrock AgentCore，在数百个客户环境中部署完全隔离的多租户 AI Agent。关键价值在于，团队不需要从零搭建计算隔离、身份认证和可观测性基础设施，而是把精力集中在 Agent 的业务能力和租户策略上。
多租户 Agent 的核心边界
多租户设计不能只依赖请求中的 tenant_id 字段。一个可靠的 Agent 请求至少需要同时绑定以下信息：
- 当前租户身份，以及发起请求的用户或服务主体
- 该租户允许使用的 Agent、工具和数据源
- 独立的运行环境或计算隔离边界
- 与租户关联的日志、指标和追踪上下文
- 任务完成后的数据保留和清理策略
这几层边界分别解决不同问题。身份认证回答“谁在调用”，授权回答“能做什么”，计算隔离回答“在哪里运行”，可观测性回答“发生了什么”。把它们混在一个应用层中，通常会导致某一层被遗漏。
AgentCore 的作用，是为这类部署提供相应的托管能力，让 Axonius 不必自行维护一套覆盖计算、认证和观测的底层平台。对于需要在大量客户环境中重复部署 Agent 的 SaaS 团队，这可以显著减少基础设施代码和运维负担。
从“共享 Agent”转向“租户专属运行上下文”
一个常见但风险较高的实现是：所有客户共享同一个 Agent 进程，只在 Prompt 或工具参数中附加租户 ID。这样的做法容易出现几类问题：
- 会话状态被错误复用
- 工具调用未强制携带租户范围
- 缓存键没有包含租户信息
- 日志无法准确区分客户数据
- 长时间运行任务在租户切换后继续使用旧上下文
更稳妥的方式是，把租户上下文作为运行时边界，而不是普通业务参数。每次执行都应该从经过验证的身份令牌中派生租户信息，再由运行环境、工具层和观测层共同使用这一上下文。
可以这样理解：tenant_id 不是用户可以随意修改的表单字段，而是授权结果的一部分。即使请求体中出现另一个租户 ID，也不能覆盖认证上下文。
一个可改造的租户上下文示例
下面的 Python 示例是一个可运行的最小实现，用于演示调用 Agent 前如何验证租户上下文。它不代表 Bedrock AgentCore 的具体 SDK 接口；实际接入时，应把 invoke_agent 替换为项目使用的 AgentCore 调用方法，并将 claims 换成经过验证的 JWT 或 IAM 身份信息。
from dataclasses import dataclass
from typing import Mapping
@dataclass(frozen=True)
class TenantContext:
tenant_id: str
subject: str
agent_id: str
def build_tenant_context(
claims: Mapping[str, str],
requested_agent_id: str,
) -> TenantContext:
tenant_id = claims.get("tenant_id")
subject = claims.get("sub")
allowed_agents = set(filter(None, claims.get("allowed_agents", "").split(",")))
if not tenant_id or not subject:
raise PermissionError("missing authenticated tenant context")
if requested_agent_id not in allowed_agents:
raise PermissionError("agent is not allowed for this tenant")
return TenantContext(
tenant_id=tenant_id,
subject=subject,
agent_id=requested_agent_id,
)
def invoke_agent(ctx: TenantContext, prompt: str) -> dict:
# 将 ctx.tenant_id 传入运行环境、工具授权和观测上下文。
return {
"agent_id": ctx.agent_id,
"tenant_id": ctx.tenant_id,
"subject": ctx.subject,
"prompt": prompt,
}
if __name__ == "__main__":
claims = {
"tenant_id": "customer-017",
"sub": "analyst@example.com",
"allowed_agents": "asset-inventory,exposure-review",
}
context = build_tenant_context(claims, "exposure-review")
print(invoke_agent(context, "Summarize newly discovered critical assets."))
运行方式：
python tenant_agent.py
在生产环境中，还应把这个检查扩展到工具调用层。例如，查询资产、创建工单或触发扫描时，由服务端根据 TenantContext 生成过滤条件和授权范围，而不是信任 Agent 生成的参数。
托管能力带来的工程取舍
使用托管 Agent 基础设施并不意味着安全问题自动消失。团队仍然需要明确以下策略：
身份和授权
认证系统应输出稳定的租户声明，并区分用户身份、服务身份和 Agent 身份。授权规则需要覆盖 Agent 本身以及 Agent 可以调用的每个工具。对于高风险操作，建议增加人工审批或二次授权。
数据与会话
会话、短期记忆、缓存和检索索引都必须使用租户隔离键。租户删除、停用或迁移时，应有明确的数据清理流程。不要因为 Agent 是无状态服务，就默认调用链中的所有组件都是无状态的。
可观测性
每条日志、指标和追踪记录都应包含租户、Agent、请求和操作者等维度，同时避免把敏感客户数据直接写入日志。多租户监控既要支持按租户排查故障，也要防止普通客户看到其他租户的运行信息。
成本和容量
数百个客户环境意味着并发、限流和成本归属都必须可测量。可以按租户记录调用次数、执行时长、模型消耗和工具失败率，并为异常租户设置配额或熔断策略。
落地清单
采用类似架构时，可以按下面的顺序检查：
- 租户身份是否来自可信认证结果，而不是请求参数。
- Agent、工具、会话、缓存和检索数据是否都具备租户边界。
- 每次工具调用是否重新执行服务端授权。
- 计算运行时是否能够为不同租户提供隔离上下文。
- 日志、指标和追踪是否可以按租户检索，同时避免泄露敏感内容。
- 是否有跨租户访问、越权工具调用和会话污染测试。
- 是否能单独统计每个租户的容量、成本和失败率。
Axonius 的实践说明，多租户 AI Agent 的关键不是简单地把 Agent 复制到更多客户，而是把隔离、身份和观测能力纳入运行平台。Amazon Bedrock AgentCore 可以减少底层基础设施建设工作，但租户模型、授权策略和数据生命周期仍然需要由产品团队清晰定义并持续验证。