用 AgentCore Gateway 和 MCP 构建多账号 AI 智能体

aws.amazon.com 2026-10-31T21:53:52.062223

企业越来越希望 AI 智能体能够跨多个 AWS 账号对数据做推理，同时又不复制数据、不把数据集中起来。各团队把数据留在自己的账号里是有充分理由的：归属清晰、范围隔离、可独立部署迭代。但一个只能看到一个账号数据的智能体，价值很有限；而把它连到分散的数据源，通常意味着复制数据，或者要理清跨账号的 AWS 身份与访问管理（IAM）。真正的目标，是让数据留在它本来的地方——也就是各个业务线（LOB）账号里。查询时只把本次请求真正需要的那部分数据传出来，底层数据集始终不离开所属账号。

本文将带你搭建一套多账号架构：每个团队的数据留在各自账号中，同时让智能体获得统一的跨账号查询方式。实现依靠 Amazon Bedrock AgentCore Gateway 和模型上下文协议（MCP）。Amazon Bedrock AgentCore 是一项智能体服务，用于安全、大规模地构建、部署和运行高效的智能体。架构中有一个中央平台账号，它承载智能体层，并通过 Amazon Bedrock 提供大语言模型（LLM）推理。各业务线团队把自己的数据和工具以 MCP 服务器的形式暴露出来，平台账号的 AgentCore Gateway 则为智能体提供一个统一入口，用于发现和调用已注册业务线的工具。整个过程会涉及：配置跨账号 MCP 集成、用 AgentCore Identity（Amazon Bedrock AgentCore 的一项能力）配合 Okta 做身份认证、用 Amazon Bedrock AgentCore 中的 Policy 实现细粒度授权，以及支持生产就绪的治理控制措施。

方案概览

这套架构采用多账号模型，分为三层：中央平台账号、分散的业务线账号，以及充当连接层的 AgentCore Gateway。

平台账户：代理的控制平面

平台团队负责平台账户，代理就运行在这里的 AgentCore Runtime 上。AgentCore Runtime 是 Amazon Bedrock AgentCore 的一项能力，提供无服务器、与框架无关的运行环境，每个会话在独立的微虚拟机（microVM）中隔离，按用量计费，并内置身份认证。为了让演示更清晰，本文只用一个代理，但同样的模式也支持平台账户中运行多个代理。代理连接的是平台账户的 Gateway，而不是各个业务线（LOB）的 MCP 服务器。

大语言模型（LLM）推理同样在平台账户中通过 Amazon Bedrock 完成。平台团队掌控可用的基础模型（FM），统一施加 Amazon Bedrock Guardrails，并通过单一计费边界跟踪成本，省去了在几十个 LOB 账户之间管理模型配额的麻烦。随着需求增长，有些组织会把推理分散到多个专用的推理账户，并在前面放一个 AgentCore Gateway 作为推理网关，把流量路由到不同模型提供商：根据请求内容选择提供商，同时按团队施加速率限制。

平台账户中的 AgentCore Gateway 是代理唯一的 MCP 入口。它把每个 LOB 账户的 MCP 服务器注册为一个目标，然后从这一个入口提供统一的工具发现（支持语义搜索）、通过 AgentCore Identity 实现的集中认证、基于 Policy in AgentCore 的细粒度授权，以及可观测性。

除了聚合 MCP 服务器、充当推理网关之外，AgentCore Gateway 还支持更多目标类型，因此可以成为统一的集成点。HTTP 目标能把 AgentCore Runtime 上的代理、代理间（A2A）服务以及其他 HTTP 端点接入同一个受治理的入口，每个目标通过各自的子路径访问。平台团队还可以启用 Amazon Bedrock Guardrails 保障内容安全，并配置 Policy in AgentCore（Cedar）实现细粒度访问控制——两者都在 Gateway 层强制执行，无需改动代理代码。

各业务条线账户：数据与工具

每个业务条线（LOB）团队都不直接暴露原始 AWS 资源，例如 Amazon Simple Storage Service（Amazon S3）存储桶、数据库和 Amazon Bedrock Knowledge Bases，而是把自身的数据和工具封装成一个 MCP 服务器。零售银行团队对外提供 get_balance、get_profile 等工具；信贷团队则提供 get_credit_score 和 search_lending_policies，其中后者会基于银行政策 PDF，查询 Amazon Bedrock Knowledge Bases 中全托管的检索增强生成（RAG）能力。这套参考架构把独立的 Amazon Bedrock Knowledge Base 包在 MCP 服务器内部，以便对检索流程做细粒度控制。如果是新项目，也可以改用 Amazon Bedrock Managed Knowledge Base，把它作为原生连接器直接挂到 Gateway 上，这样智能体用标准 MCP 调用即可查询，无需自己运维检索基础设施。

MCP 服务器运行在业务条线账户内的 AgentCore Runtime 上。这是一个无服务器、不绑定框架的环境：会话在专用 microVM 中隔离，按实际用量计费，通过 AgentCore Identity 内置身份认证，并提供面向智能体的可观测能力。这样一来，业务条线团队就能完全掌控自己的工具面：对外暴露哪些工具、每个工具背后跑什么业务逻辑，都由团队自己决定；只要 MCP 工具接口保持不变，团队就可以调整内部实现，而不会影响平台侧智能体。

跨账户集成：Gateway 与 Identity 打通各层

这套架构采用中心辐射（hub-and-spoke）模式：每条业务线（LOB）各自部署一个独立的 MCP 服务器，也就是辐射点，并通过基于 Streamable HTTP 的 MCP 对外提供服务；AgentCore Gateway 作为中心节点，把这些服务器聚合成一个统一入口。智能体只把 Gateway 当成一个 MCP 服务器来连接，Gateway 再在已注册的各条业务线目标之间分发工具调用。当智能体调用某个工具时，Gateway 会先从 AgentCore Identity 取出 OAuth 2.0 机器对机器（M2M）凭证，附加到外发请求上，再路由到对应的业务线 MCP 服务器。该服务器拿这个令牌去 Okta 的 OpenID Connect（OIDC）端点校验，通过后才在本地处理请求。业务线的数据始终留在自己的账户内：MCP 服务器只返回工具产出的那条具体结果，而不是原始数据集，这条结果再流向平台账户，作为推理时的上下文。源数据既不会被复制，也不会被迁移。

图 1：基于 AgentCore Gateway 与 MCP 的多账户 AI 智能体架构

下面的演练会跟踪一个用户提问，看它如何跨越账户边界、调用分布式工具，最终返回统一的答案：

用户通过 React 网页应用登录，页面会跳转到 Okta 完成身份验证。Okta 校验用户凭证后，返回一个 JSON Web Token（JWT），其中包含身份声明（sub、groups、audience）。
用户通过网页应用提交提示词，请求经 HTTPS 到达 Amazon CloudFront。
CloudFront 将请求转发给运行在 Amazon Elastic 上的 FastAPI 后端

后端运行在 AWS Fargate 上的容器服务（Amazon ECS）中。用户输入在到达智能体之前，以及智能体输出在返回用户之前，都会先经过 Amazon Bedrock Guardrails 做个人身份信息（PII）脱敏。后端调用运行在 AgentCore Runtime 上的 Strands Agent，并转发 Authorization 头中的用户 JWT，用于身份传递。智能体把提示词发送给 Amazon Bedrock 进行推理，再根据模型的响应决定调用哪些工具。智能体把用户的 JWT 转发给 AgentCore Gateway，后者通过语义搜索在各 LOB 目标中查找工具。当 Gateway 关联了策略引擎时，Policy in AgentCore 会拿 JWT 声明去匹配 Cedar 规则，按用户身份、角色或操作，逐次允许或拒绝工具调用。由于出站调用走的是 M2M（机器对机器），用户级授权就在 Gateway 这一层执行。对于被允许的调用，Gateway 从 AgentCore Identity 取出 OAuth 2.0 M2M 凭据，附加到出站请求上，再转发给对应的 LOB MCP 服务器。每个 LOB MCP 服务器都会先校验入站 OAuth 令牌，再执行业务逻辑：一是查询本地 Amazon DynamoDB 表做结构化数据检索；二是对于 Lending & Wealth 这条 LOB，还会针对存在 Amazon S3 中、由 Amazon OpenSearch Serverless 建立索引的银行政策 PDF，通过 Amazon Bedrock Knowledge Bases 做 RAG 检索。结果沿原链路返回（LOB → Gateway → Agent → 后端），示例应用里有一个调用链面板，可以查看访问了哪些 LOB，以及被 Policy in AgentCore 拒绝的调用。每个 LOB 运行时都会校验入站 OAuth 令牌。在生产环境中，LOB 团队会配置 allowedWorkloadConfiguration，把运行时的调用限制为身份链中包含 Gateway 的请求，从而降低绕过 Gateway 策略和 Cedar 授权、直接访问的风险。Strands Agent 通过 Gateway 的 tools/list 方法发现 LOB 工具，并在启动时查询 AWS Agent Registry（预览版），以发现已注册的 LOB MCP 服务器。

接入新的业务线，只需新增一个 Gateway 目标。Agent 会在下一次调用 tools/list 时发现这些新工具。

技术实现

接下来的几节会逐层拆解这套架构：业务线团队如何构建和部署 MCP 服务器；平台团队如何配置 AgentCore Gateway 的出站 OAuth 认证，以及 AgentCore 中 Policy 的授权机制；还有持续评估如何帮助智能体在工具和模型不断演进时保持可靠。要查看完整实现，可以克隆配套仓库并运行部署脚本。这个脚本会在四个账户中引导 AWS Cloud Development Kit（AWS CDK），创建平台和业务线资源，部署 MCP 服务器和 Gateway 目标，并在 CloudFront 后面的 Amazon ECS 上启动一个 React Web 应用。

前置条件

配套仓库默认满足以下条件：

通过 AWS Organizations 管理的 AWS 多账户架构，平台账户和业务线账户位于同一个组织内。
平台账户中已开通 Amazon Bedrock 模型访问权限。
平台账户（用于智能体、Gateway 和 Registry）和每个业务线账户（用于在 Runtime 上托管 MCP 服务器）都已配置 AgentCore。
有一个兼容 OIDC 的身份提供商（例如 Okta、Amazon Cognito 或 Microsoft Entra ID），并为 OAuth 2.0 客户端凭证授权配置了机器对机器（M2M）应用客户端。配套仓库使用的是 Okta。
业务线数据源（Amazon Bedrock Knowledge Bases、Amazon DynamoDB 表、Amazon S3 存储桶或 API 端点），这些数据源将由 MCP 服务器封装。

在各业务线账户中设置 MCP 服务器

每个业务线团队都会用 FastMCP 构建一个 MCP 服务器，再通过 AgentCore CLI 部署到 AgentCore Runtime，把本团队的数据暴露成一组结构化工具，输入输出都带类型定义。团队会为服务器配置自定义的 JWTAuthorizer，用 Okta 的 OIDC 发现端点验证入站 OAuth 令牌，因此请求必须携带有效令牌才能调用该业务线的工具。生产环境加固时，可以把 Runtime 上的 allowedWorkloadConfiguration 设成 Gateway 的 Amazon 资源名称（ARN），这样只有当身份链中包含该 Gateway 时才接受请求。本示例主要依赖 OAuth 受众验证（audience validation）作为访问控制手段。加上 allowedWorkloadConfiguration 有助于把调用限制为经由 Gateway 到达的请求，降低绕过 Gateway 策略直接访问的风险。下面的代码片段展示了 Lending & Wealth 业务线的 MCP 服务器，把 Amazon DynamoDB 查询和 Amazon Bedrock Knowledge Bases 检索结合在一起。

REGION = os.environ.get("AWS_REGION", "us-east-1")

dynamodb = boto3.resource("dynamodb", region_name=REGION)

bedrock_agent_runtime = boto3.client("bedrock-agent-runtime", region_name=REGION)

KNOWLEDGE_BASE_ID = os.environ.get("KNOWLEDGE_BASE_ID", "")

mcp = FastMCP("lending-wealth", host="0.0.0.0", stateless_http=True)

@mcp.tool()
def get_credit_score(customer_id: str) -> dict:
    """Get credit score and contributing factors for a customer."""
    table = dynamodb.Table("CreditScores")
    resp = table.get_item(Key={"customer_id": customer_id})
    item = resp.get("Item")
    if not item:
        return {"error": f"No credit score found for customer {customer_id}"}
    return item

@mcp.tool()
def search_lending_policies(query: str) -> str:
    """Search the bank's lending policy documents for guidelines,
    eligibility criteria, and regulatory requirements."""
    if not KNOWLEDGE_BASE_ID:
        return json.dumps({"error": "KNOWLEDGE_BASE_ID not configured"})
    resp = bedrock_agent_runtime.retrieve(
        knowledgeBaseId=KNOWLEDGE_BASE_ID,
        retrievalQuery={"text": query},
        retrievalConfiguration={"vectorSearchConfiguration": {"numberOfResults": 5}},
    )
    chunks = []
    for r in resp.get("retrievalResults", []):
        text = r.get("content", {}).get("text", "")
        source = r.get("location", {}).get("s3Location", {}).get("uri", "")
        if text:
            chunks.append({"text": text, "source": os.path.basename(source)})
    return json.dumps({"results": chunks}, default=str)

if __name__ == "__main__":
    mcp.run(transport="streamable-http")

用 AgentCore CLI 把 MCP 服务器部署到 AgentCore Runtime。configure 这一步设置入口和协议，deploy 这一步打包并推送：

# Configure the MCP server
agentcore configure \
    --entrypoint server.py \
    --name lending_wealth_mcp \
    --protocol MCP \
    --disable-memory \
    --non-interactive \
    --authorizer-config '{

customJWTAuthorizer": {
        "discoveryUrl": "<OKTA_DISCOVERY_URL>",
        "allowedAudience": ["lobfederation"]
      }
    }'

# Deploy to AgentCore Runtime
agentcore deploy --auto-update-on-conflict \
    --env KNOWLEDGE_BASE_ID=<your-knowledge-base-id>

部署完成后，CLI 会返回一个 runtime ARN，平台团队用它把这个 MCP 服务器注册为 Gateway 的一个目标。

配置 AgentCore Gateway

在平台账号里创建 Gateway，配上 Custom JWT 授权器，指向 Okta 的 OIDC discovery URL，并校验 audience（aud）声明，从而限定哪些应用可以接入：

ctrl.update_gateway(
    gatewayIdentifier=gateway_id,
    name="lobfederation-gateway",
    protocolType="MCP",
    protocolConfiguration={
        "mcp": {
            "searchType": "SEMANTIC",
            "supportedVersions": ["2025-03-26"],
        }
    },
    authorizerType="CUSTOM_JWT",
    authorizerConfiguration={
        "customJWTAuthorizer": {
            "discoveryUrl": "https://<your-okta-domain>/oauth2/<auth-server-id>/.well-known/openid-configuration",
            "allowedAudience": ["lobfederation"],
        }```python
        }
    },
)

Gateway 调用 LOB MCP 服务器时，出站认证使用 OAuth 2.0 客户端凭证模式（M2M，机器对机器）。平台团队会在 AgentCore Identity 里注册一个 OAuth 凭证提供方，用来存放 Okta 的 M2M 客户端凭证。当 Gateway 调用某个 LOB MCP 服务器时，AgentCore Identity 会从 Okta 取一个新的访问令牌，放进 Authorization 请求头传过去。注册好凭证提供方后，把它挂到每个 Gateway 目标上：

# 注册 OAuth 凭证提供程序（M2M / client_credentials）
resp = ctrl.create_oauth2_credential_provider(
    name="lobfederation-okta-m2m",
    credentialProviderVendor="CustomOauth2",
    oauth2ProviderConfigInput={
        "customOauth2ProviderConfig": {
            "oauthDiscovery": {
                "discoveryUrl": "https://<your-okta-domain>/oauth2/<auth-server-id>/.well-known/openid-configuration"
            },
            "clientId": "<M2M_CLIENT_ID>",
            "clientSecret": "<M2M_CLIENT_SECRET>",
            "clientAuthenticationMethod": "CLIENT_SECRET_BASIC",
        }
    },
)

cred_arn = resp["credentialProviderArn"]

# 为 LOB MCP 服务器创建网关目标，配置 OAuth 出站认证
ctrl.create_gateway_target(
    gatewayIdentifier=gateway_id,
    name="lending-wealth",
    description="Lending & Wealth — loans, credit scores, eligibility, policy search",
    targetConfiguration={
        "mcp": {
            "mcpServer": {
                "endpoint": f"https://bedrock-agentcore.{REGION}.amazonaws.com/runtimes/{encoded_runtime_arn}/invocations",
            }
    },
    credentialProviderConfigurations=[
        {
            "credentialProviderType": "OAUTH",
            "credentialProvider": {
                "oauthCredentialProvider": {
                    "providerArn": cred_arn,
                    "scopes": ["lobfederation.invoke"],
                    "grantType": "CLIENT_CREDENTIALS",
                }
            },
        }
    ],
)

当 LOB 工具必须自行控制每个用户的访问权限时（比如行级安全），AgentCore Identity 还提供了“代表用户”（on-behalf-of，OBO）的令牌交换。网关会把入站的用户令牌换成下游作用域的令牌，令牌中同时携带智能体和用户的身份信息。本次实现采用 M2M，因为示例所用的 Okta 开发者账号并不支持 OBO 流程。AgentCore Gateway 也支持授权码授权和 API 密钥。示例可参考 AgentCore Gateway 的出站认证样例。

部署智能体

把 Strands 智能体部署到 AgentCore Runtime，用自定义 JWT 授权器处理入站请求的认证。部署脚本在初次部署完成后，会通过 AgentCore 控制平面 API 应用授权器配置。处理请求时，智能体会把用户的 JWT 转发给 Gateway，让 Policy in AgentCore 在路由每次工具调用之前，先校验用户的身份声明：

{
  "agents": [
    {
      "name": "lobfederation-agent",
      "authorizerType": "CUSTOM_JWT",
      "authorizerConfiguration": {
        "customJwtAuthorizer": {
          "discoveryUrl": "https://<your-okta-domain>/oauth2/<auth-server-id>/.well-known/openid-configuration",
          "allowedAudience": ["lobfederation"]
        }
      },
      "requestHeaderAllowlist": ["Authorization"]
    }
  ]
}

部署完成后，智能体会从入站请求的头信息中读取用户的 JWT，再把它传给 AgentCore Gateway。这样一来，最终用户的身份就一路传到了 Cedar 策略引擎，智能体既不用解析令牌，也无需改动它：

@app.entrypoint
def invoke(payload, context=None):
    prompt = payload.get("prompt", "Hello")

# 从入站请求头中读取用户的 JWT（由 Runtime 透传过来）
    request_headers = context.request_headers if context else {}
    user_jwt = request_headers.get("Authorization", "")

# 用用户的 JWT 连接 Gateway —— Cedar 会按用户逐个校验策略
    mcp_client = MCPClient(
        lambda: streamablehttp_client(
            url=GATEWAY_URL,
            headers={"Authorization": user_jwt},
        )

with mcp_client:
        tools = mcp_client.list_tools_sync()
        agent = Agent(model=MODEL_ID, system_prompt=SYSTEM_PROMPT, tools=tools)
        result = agent(prompt)

运维智能体

智能体部署上线后，平台团队通过持续评估、安全的版本发布和可观测性，让它保持稳定可靠。

持续评估

在多账号架构中，智能体要跨多个业务线调度工具，平台团队必须确信：随着工具、模型和提示词不断变化，智能体依然能正确工作。AgentCore Evaluations 提供了一个托管框架，帮助在问题影响客户之前发现功能退化。

在线评估会持续对生产环境的实时流量抽样打分（例如抽取 10% 的会话），使用内置评估器，如工具选择准确率、正确性和目标成功率。评分会显示在 AgentCore Observability 仪表盘中（这是 Amazon Bedrock AgentCore 的一项能力，由 Amazon CloudWatch 提供支持），质量下降时会触发告警。如果智能体已经输出 OpenTelemetry 数据，则无需修改代码。建议在每次发布前，再结合黄金数据集做离线评估，这样功能退化能在 CI 阶段被发现，而不是等到生产流量出问题。

安全发布版本

AgentCore Runtime 的版本是智能体代码和配置的不可变快照。与其在运行中的端点上直接重新部署，不如发布一个新版本，然后把命名端点指向新版本。由于 Gateway 目标引用的是带端点限定的运行时 ARN，而不是某个具体版本，因此升级或回滚发布时，无需重新注册 MCP 服务器为 Gateway 目标。

# Publish an immutable version of the current runtime configuration
version = ctrl.create_agent_runtime_version(
    agentRuntimeId=runtime_id,
)

# Move the named production endpoint to the new version
ctrl.update_agent_runtime_endpoint(
    agentRuntimeId=runtime_id,
    endpointName="prod",
    agentRuntimeVersion=version["agentRuntimeVersion"],
)

典型的发布路径是 dev -> staging -> prod。平台团队会观察 staging 端点的在线评估分数，只有在规定时间窗口内保持稳定，才会把 prod 端点切到新版本。如果工具选择准确率或目标成功率出现退化，只需把端点重新指向旧版本即可完成回滚，而且回滚无需改动 Gateway 配置、Cedar 策略或各业务线的 MCP 服务器。

端到端观测 Agent

因为 Agent 本身已经在发出 OpenTelemetry 数据，所以追踪链路覆盖了从入站请求到 AgentCore Runtime、穿过 Gateway、再进入各个 LOB MCP 服务器的全过程。平台团队借助它回答三个跨越账户边界的问题：

哪个 LOB 慢了或出故障了？ 按目标统计的延迟和错误率，能让团队定位到某个 LOB 账户里出问题的 MCP 服务器，而无需平台团队获得该账户的访问权限。
Agent 选了哪些工具？ 工具选择追踪会展示模型实际发出的工具调用，这才让工具选择准确率（Tool Selection Accuracy）这个分数变得可执行，而不只是一个数字。
策略拒绝了什么？ 每条 Cedar 决策都会连同主体、动作和资源一起记录，所以被拒绝的工具调用可以追溯到用户 Okta 令牌里那个没满足策略的具体声明。

基于这些信号的 CloudWatch 告警会呼叫平台团队，而各 LOB 团队看到的是同一批看板，只是范围限定在自己的目标上。

小结

这套模式在多个账户之间保持了清晰的职责划分：

身份提供方（Okta） 是判断用户是谁、属于哪条业务线的唯一事实来源。入站（用户 JWT）和出站（M2M 客户端凭据）两种认证都源自它。
平台账户 拥有 AgentCore Gateway、Policy in AgentCore 里的 Cedar 策略、AgentCore Identity 里的 OAuth 凭据提供方，以及 Agent 本身。它从不持有 LOB 的数据凭据。
每个 LOB 账户 拥有自己的 MCP 服务器和背后的数据，在需要时执行自己的行级规则，并且只通过 Gateway 暴露工具。
Agent 保持轻薄。 它转发用户 JWT、列出 Gateway 暴露的工具，然后让 Gateway 和策略引擎决定哪些调用被允许。新增一条业务线意味着注册一个新的 Gateway 目标，而不是修改 Agent。

最终得到的是一个横跨多个账户和业务线的单一 Agent，同时每次工具调用都能归属到真实用户、由平台团队掌控的策略授权，并且可以端到端观测。

清理

为避免持续产生费用，请删除本次演练中创建的资源：Gateway 目标与 Gateway 本身、OAuth 凭证提供方、runtime 端点和 runtime，以及所有 CloudWatch 告警和评估配置。如果 Okta 授权服务器和 M2M 应用只是为本示例创建的，也请一并删除。

这些追踪数据能揭示延迟和错误率监控容易忽略的隐性退化，例如 agent 把贷款查询路由到了错误的业务线（LOB）。按需评估是一个面向开发和 CI/CD（持续集成与持续交付）的实时 API。团队只需定义一次评估数据集——包含场景、预期响应、工具调用轨迹和目标断言——之后每次变更时，AgentCore Evaluations 都会用数据集评估回放这套数据。由于两种模式共用同一套评估器，部署前的卡点标准与生产环境的监控标准完全一致。为了形成闭环，AgentCore Optimization 会分析生产追踪数据，给出提示词和工具描述的改进建议，并在上线前完成验证。

安全地管理版本并发布

你把 agent 部署在 AgentCore Runtime 上，通过端点（prod、staging、dev）指向特定版本。平台团队更新 agent 的提示词或模型时，只需发布新版本并更新端点，各 LOB 的 MCP 服务器不受影响，因为工具接口没有改变。在正式发布前，团队可以通过 AgentCore Gateway 进行 A/B 测试，将线上流量在现版本和候选版本之间分流。等结果达到统计显著性后，平台团队再发布表现更好的配置。

监控与观测

AgentCore 通过 Amazon CloudWatch 和 OpenTelemetry 提供内置的可观测能力。平台团队可以监控调用延迟、错误率和 token 用量，并借助 CloudWatch 的跨账户可观测功能查看各 LOB MCP 服务器的指标和日志，无需切换账户。

安全、治理与成本管理

智能体集中部署、数据分散在各处，这会带来几项具体的治理要求：控制谁能调用哪些工具、审计跨账户调用、落实负责任的 AI 策略，以及把成本归到发起调用的那条业务线（LOB，line of business）头上。

最小权限访问与数据所有者审批

业务线团队通过其 AgentCore Runtime 部署上的 JWT 授权器配置，决定谁可以调用自己的 MCP 服务器。只有当业务线团队把自己的 MCP 服务器配置为接受平台身份提供商签发的令牌之后，来自平台账户 Gateway 的请求才能触达该业务线的工具。这道审批权掌握在业务线手里，平台团队无法绕过。即便 Gateway 新增了一个目标，业务线的 MCP 服务器也会拒绝未通过认证的请求。

AgentCore 授权中的策略（Policy in AgentCore）

Gateway 以 ENFORCE（强制执行）模式运行 Policy in AgentCore。在路由每一次工具调用之前，它会先拿用户的 JWT 声明（来自智能体转发的令牌）逐条比对规则。Policy in AgentCore 使用 Cedar 策略语言，规则就是明确的 permit（允许）和 forbid（禁止）语句。例如，可以让所有已认证用户调用 get_balance 这类只读工具，把 transfer_funds 这类写操作限制在特定角色，或者干脆完全封杀 delete_customer 这类破坏性操作：

// Permit all authenticated users to invoke read-only tools
permit(
    principal is AgentCore::OAuthUser,
    action in [
        AgentCore::Action::"retail-banking___get_customer",
        AgentCore::Action::"retail-banking___get_accounts",
        AgentCore::Action::"retail-banking___get_balance",
        AgentCore::Action::"tools/list",
        AgentCore::Action::"initialize"
    ],
    resource
);

// Block destructive operations regardless of user
forbid(
    principal,
    action == AgentCore::Action::"retail-banking___delete_customer",
    resource
);

因为 AgentCore 中的 Policy 采用默认拒绝模型，所以只有被显式允许的动作才能成功执行。这样一来，平台团队可以集中管控 Agent 在所有已注册 LOB 中的行为，而各 LOB 团队则在 MCP 服务器层面保留自己的授权机制。

网络连接与 VPC 注意事项

这个参考实现使用的是 AgentCore Runtime 的默认公网模式，流量通过 HTTPS 走公网，并配合 OAuth 认证。这种方式适合开发阶段，不适合生产环境。生产环境可以考虑以下能力：AgentCore Runtime 支持通过弹性网络接口（ENI）实现 VPC 连接，以访问私有资源；支持基于 AWS PrivateLink 的接口 VPC 端点，实现到 Gateway 的私有入站访问；还支持用 allowedWorkloadConfiguration 把运行时调用限制在你的 Gateway 内。配置步骤可参考 AgentCore Runtime 的网络连接模式，以及使用接口 VPC 端点安全接入 AgentCore Gateway 的说明。

Guardrails

在平台账号中启用 Amazon Bedrock Guardrails，可以做内容过滤、PII（个人身份信息）脱敏和主题限制。由于推理是集中进行的，一份 Guardrails 配置就能覆盖 Agent 跨 LOB 工具的交互。此外还有一个较新的选项：可以直接把 Guardrails 作为策略应用到 AgentCore Gateway 上，这样检查就在 Gateway 层执行，位于 Agent 代码之外，覆盖经 Gateway 路由的工具和上下文来源。

审计与合规

要开启数据平面日志，可以在 Gateway 上配置日志投递到 Amazon CloudWatch Logs，它会记录工具调用和请求元数据。AWS CloudTrail 默认会捕获控制平面操作，比如创建和更新 Gateway、Runtime、目标以及策略。如果想在 CloudTrail 中也记录每次工具调用，可以使用高级事件选择器为 AgentCore Gateway 资源启用数据事件日志。若需要集中审计，可以配置组织级 CloudTrail 跟踪，把平台账号和 LOB 账号的日志汇总到一个专用日志账号。

成本归因

这套架构天然划出了成本边界。各业务线（LOB）的数据面成本——Amazon DynamoDB、Amazon Bedrock 知识库、MCP 服务器的计算资源——都留在自己的账号里，并直接体现在 AWS Cost Explorer 中。而大模型推理和网关调用产生的费用则记在平台账号下。要把这些费用算回到发起调用的业务线，可以给智能体的执行角色打上标签（比如 lob 或 costCenter 标签）。在 AWS 账单控制台激活成本分配标签后，这些标签会进入 AWS 成本与用量报告（Cost and Usage Report），从而按业务线分摊费用。智能体的工具调用记录（tool trace）会记下每个业务线调用了哪些工具，便于按比例分摊。若想采用更精细的方案，可参阅 Amazon Bedrock 的细粒度成本归因方法。

清理资源

部署配套仓库后，为避免持续产生费用，请运行仓库自带的清理脚本。它会删除四个账号中已部署的资源，包括 AgentCore 组件（智能体、网关、注册表、凭证提供器）、Okta 配置（授权服务器、M2M 应用客户端）、MCP 服务器部署、CDK 堆栈（Amazon DynamoDB 表、Amazon S3 存储桶、Amazon Elastic Container Registry 仓库、Amazon ECS 集群）以及示例数据源。请在仓库根目录下运行：

./cleanup.sh

脚本按部署的逆序执行……先移除智能体和 MCP 服务器，再移除 AgentCore 配置中的网关目标和策略（Policy），最后移除四个账号中的 CDK 基础设施堆栈。

结论

本文演示了如何搭建一套多账号架构：智能体通过 Amazon Bedrock 和 AgentCore 集中运行，数据则分散存放在各业务线账号中。业务线团队把数据以 MCP 服务器的方式开放出来，平台账号的网关则提供单一且经过身份验证的端点，供工具发现和调用，而 AgentCore 中的策略（Policy）在网关这一层完成按用户的授权校验。

这套模式天生可扩展：要接入一条新业务线，平台团队只需新增一个 Gateway 目标（target），智能体下次调用时就会自动发现这些新工具。如果想自己动手试，可以克隆配套的代码仓库，部署这套四账户的参考实现。

你可以构建一套多账户架构：每个团队的数据留在自己的 AWS 账户里，同时让 AI 智能体有一个统一入口，能跨账户查询这些数据。中央平台账户用 Amazon Bedrock AgentCore Gateway 和 MCP 运行智能体；各业务线账户则把数据以 MCP 服务器的形式对外暴露，并配合安全的跨账户访问和细粒度授权。

查看原文