用 Amazon Bedrock AgentCore Gateway 治理 AI 智能体工具访问

#用 Amazon Bedrock AgentCore Gateway 治理 AI 智能体工具访问

近几个月与客户的交流里，有一个模式反复出现。无论他们用的是编码智能体、自主智能体，还是与人交互的智能体，也不论工作负载成熟到哪一步，我们都会从同一个问题开始：“哪些 AI 智能体能访问客户数据，是谁授予的，如果今天有一份凭据泄漏，暴露面会是什么样？”如果组织里没有人能在一分钟内答上来，这篇文章就是写给你的。

当 AI 智能体在没有集中治理的情况下连接内部工具时，组织会遇到难以发现的访问风险。设想一名基础设施工程师打开同事的笔记本电脑调试构建。配置文件夹里有一个名为 mcp.json 的文件，其中以明文保存着生产数据库密码，旁边还有一条注释：TODO: rotate this。安全团队看不到哪些 AI 智能体正在访问内部工具、访问是谁授予的，以及这份凭据一旦无意暴露，暴露面会有多大。

所提出的方案使用支持模型上下文协议（Model Context Protocol，MCP）的助手，包括集成开发环境（IDE）辅助工具，例如 Kiro、Claude Code、Cursor，以及 Amazon Quick 这类 AI 工具。本文聚焦 AWS 托管服务 Amazon Bedrock AgentCore，这是一个可用任意框架或模型大规模构建、连接并优化智能体的平台。借助 AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力），你可以为智能体流量提供一个通往组织工具的单一安全入口。它依赖 AgentCore Identity（Amazon Bedrock AgentCore 的一项能力）完成安全的身份验证、授权和凭据管理。要为 AI 智能体与工具的交互定义并强制执行安全控制，你使用 AgentCore Policy。随后可以用 Amazon Bedrock Guardrails 为策略补充安全与隐私控制，并用 AWS Agent Registry 建立集中目录，用来组织、策展和发现工具。自托管选项（Kong Gateway、Open Policy Agent、NeMo Guardrails 和 LangFuse）同样存在，本文会在相关处点出它们。

问题

采用 MCP 部署的企业系统里，常见五种结构性失效模式：凭据蔓延（每个本地配置里都有密钥）、策略漂移（N×M 套配置在无人注意时分叉）、审计缺口（答不出“谁在何时调用了什么”）、成本不透明（支出无法归到团队），以及影子 IT（集成部署在评审之外）。

以策略漂移为例。每个 AI 助手都带着自己的 mcp.json，这是一份含后端凭据和工具端点的本地文件，且不受监督。一个团队有 10 个助手、连接 5 个内部 API，就要维护 50 套各自独立、手工配置的凭据。某个后端的策略一变，就必须在全部 50 处更新。

回到前面的问题：哪些助手能访问客户数据，是谁授予的？多数团队的反应是，在允许任何 AI 使用之前先建一个完整网关，这要花数月，而且交付的往往是错的东西。我们建议改为让控制措施匹配真实需求。

解决方案：四个范围的成熟度路径

受治理的网关提供一个受治理的端点，知道是谁在调用、依据何种权限，在工具和参数层面强制执行策略，并记录每一项决策。团队也可以不靠工单发布工具。每个范围都能单独交付价值，同时保留走向下一步的路径。

范围 1：连接（Connect）。 开一扇受治理的门，让 AI 智能体能够到达组织资源。当 MCP 凭据放在本地配置里、安全团队没有清单时，采用单点登录（Single Sign-On，SSO）身份验证，集中管理凭据，并启用 CloudTrail 审计。

范围 2：控制（Control）。 弄清谁做了什么，并在数据经过时擦除敏感信息。当你答不出“谁在何时、依据哪条策略调用了哪个工具”时，采用 Cedar 的基于角色的访问控制（Role-Based Access Control，RBAC）和基于属性的访问控制（Attribute-Based Access Control，ABAC）、个人身份信息（personally identifiable information，PII）脱敏、三方登录（three-legged OAuth，3LO）同意，以及动态客户端注册（Dynamic Client Registration，DCR）。

范围 3：目录（Catalog）。 让团队自己查找并发布工具，包括本地部署的工具。当工具注册必须走工单、本地系统一直被排除在外时，部署 Registry、Resources MCP、开放策略代理（Open Policy Agent，OPA），以及按工具的成本归属。

范围 4：加固（Harden）。 锁住边缘，监视一切，并为故障做计划。当用户超过 1,000、没有熔断器、使用公网 DNS、也没有故障转移时，增加专用连接、治理仪表盘、弃用工作流，以及多区域故障转移。

每个范围都能单独交付价值。只在下一种痛点出现时再前进。下图是范围决策的参照。

图 1：根据你面临的治理痛点选择范围的参照

方案演练

以下各节一次构建一个范围的网关。先从先决条件开始，再随着新的治理问题出现，逐个范围推进。

先决条件

要按本文操作，你需要一个 AWS 账户，并拥有创建 Amazon Bedrock AgentCore 和 Amazon Cognito 资源的权限；熟悉 OAuth 2.0 和 AWS Identity and Access Management（IAM）；具备基本的 AWS 命令行界面（AWS Command Line Interface，AWS CLI）经验；并理解 模型上下文协议（Model Context Protocol，MCP）。

范围 1：连接，最小的受治理网关

下图展示范围 1 的最小拓扑：

图 2：MCP 客户端连接到 AgentCore Gateway，Amazon Cognito 签发用于身份验证的 JSON Web 令牌（JSON Web Token，JWT），AgentCore Identity 管理出站凭据，一个已注册目标接收工具调用

何时需要这个范围：1–20 名试点用户、低风险工具、开始出现影子 MCP。

关键决策： 网关归属（基础设施工程、安全，或共享）。第一个工具选什么。是强制只走网关，还是与遗留的 mcp.json 并存。

会改变什么

你架起带 Cognito 支撑的 JWT 授权器的 AgentCore Gateway，并注册一个低风险的 Lambda 目标（例如只读的工单搜索）。授权保持粗粒度：任何已通过身份验证的客户端都可以调用任何已注册工具。mcp.json 在现有公开资源旁边新增一条记录，强调缓慢、增量式的变更。

你可以接入自己的身份提供者（identity provider，IdP），例如 Amazon Cognito，并与 AgentCore Identity 集成。AgentCore Identity 通过 OAuth 2.0 处理机器到机器（Machine-to-Machine，M2M）身份验证，也可以处理 AWS 资源的出站身份验证，或用 AWS Secrets Manager 做基于 API 密钥的身份验证。借助原生的 Amazon CloudWatch Logs 和 AWS CloudTrail，你现在可以知道何时、哪些组织资源被访问过。

客户端流程

1. 助手用预先配发的 client_id/client_secret 和网关 URL 完成引导。
2. 每个会话获取一个 Cognito 令牌，并把 bearer 附加到 tools/list 和 tools/call。
3. 网关校验 JWT，并路由到目标。
4. 后端凭据永不离开 AWS。

实现片段。

创建网关，把 JWT 授权器指向你的 IdP（例如 Cognito），并配置 allowedClients：

aws bedrock-agentcore-control create-gateway \
  --name pilot-gateway \
  --role-arn arn:aws:iam::<account-id>:role/GatewayRole \
  --protocol-type MCP \
  --authorizer-type CUSTOM_JWT \
  --authorizer-configuration '{
  "customJWTAuthorizer": {
    "discoveryUrl": "https://cognito-idp.<region>.amazonaws.com/<pool-id>/.well-known/openid-configuration",
    "allowedClients": ["pilot-gateway-client"]
  }
}'

这条命令把 Cognito 签发的 JWT 变成网关唯一接受的凭据。

然后注册一个 AWS Lambda 目标（例如只读的工单搜索）：

aws bedrock-agentcore-control create-gateway-target \
  --gateway-identifier pilot-gateway \
  --name TicketSearch \
  --target-configuration '{
  "mcp": { "lambda": { "lambdaArn": "arn:aws:lambda:<region>:<account-id>:function:ticket-search", "toolSchema": {"inlinePayload": "<tool-schema-json>"} } }
}'

Lambda 现在可以作为 MCP 工具被访问，无需在客户端接线。一份分发用的 mcp.json 替换本地服务器条目：

{
  "mcpServers": {
    "enterprise-tools-gateway": {
      "url": "https://<gateway-name>.gateway.bedrock-agentcore.<region>.amazonaws.com/mcp",
      "type": "http"
    }
  }
}

因为用户基数小，把这条记录分发到现有的 mcp.json 文件即可。

推出

阶段 1（第 1 天）： 配置 Cognito 用户池。部署网关。注册一个低风险 Lambda 目标。阶段 2（第 2–3 天）： 通过移动设备管理（Mobile Device Management，MDM）分发更新后的 mcp.json。端到端验证：获取令牌 → tools/list → tools/call。阶段 3（第 1 周）： 确认每次调用都出现 CloudWatch Logs 和 CloudTrail 记录。

结果。 端到端路径可以工作，mcp.json 现在包含一个能到达全组织资源的端点，管理层也能看到生产力和控制是一起交付的。

这一阶段之后，如果你开始遇到这样的问题：

• 用户是否在工具调用中传递了任何 PII？我们如何防止？
• 我们是否征求用户同意、以他们的名义执行操作？我们如何核验责任归属？
• 用户组对工具应有不同的访问权限。这做得到吗？

那么你就准备好扩大范围了。如果范围 2 已满足当前需要，直接跳到“考量”，阅读运维指导。

范围 2：控制，感知身份的授权与护栏

门打开之后，范围 2 要指出调用者是谁，并擦除流经的内容。

下图展示范围 2 中身份、策略和护栏如何集成：

图 3：Gateway、Identity 和 Policy 被带有 Amazon Bedrock Guardrails 的请求与响应拦截器包住；Identity 增加一个 DCR 接口（用 Lambda 和 Amazon API Gateway 提供 .well-known 端点）、AWS IAM 和 Amazon DynamoDB；3LO 征询把用户重定向到浏览器以取得同意

何时： 用户基数在增长，合规在问“谁在哪条策略下做了什么”。你需要一个答案，并且 PII 在落地前已被擦除。

关键决策： 身份提供者怎么选。过渡期的身份验证模型（授权码流程对比客户端凭据）。在 ENFORCE 之前保持 LOG_ONLY 多久。第一条 Cedar 拒绝规则是什么。

会改变什么

你把网关从机器级信任转到用户级信任。客户端现在通过 动态客户端注册（Dynamic Client Registration，DCR） 机制被动态加入 AgentCore Gateway 的 allowedClients。客户端第一次对网关调用 tools/list 时，会收到（RFC 9728/8414）元数据，用以调用一个 DCR 垫片。该垫片是 Amazon API Gateway 后面的 Lambda：在 POST /register 时创建 Cognito 应用客户端，并通过 UpdateGateway 把新的 client_id 追加到 AllowedClients。

用户使用 SSO 登录，完成授权码流程。现在访问令牌的 sub 声明就是真实用户。此后每个请求都携带该用户身份。第一道安全门 AgentCore Policy 在此介入：Cedar 规则依据 IdP 组声明、令牌声明和参数门控实施 RBAC。例如，可以把 DeployCI___invoke 限制为 context.input.environment == "staging"，从而允许或禁止某些用户访问。

若允许通过，AgentCore Policy 会通过其原生的 Amazon Bedrock Guardrails 集成评估请求。该集成在网关层应用 PII 过滤器、内容策略和提示攻击检测，无需自定义代码。对于护栏覆盖不到的结构变换或 ABAC 规则，由请求拦截器 Lambda 处理其余部分。当目标资源需要把用户身份带向 SaaS 系统（例如 GitHub 或 Figma）时，AgentCore Identity 凭据提供者处理 3LO 授权码流程。网关发出 MCP 征询（-32042 错误），以便助手引导用户在浏览器中完成同意。

在响应阶段，拦截器擦除无意带出的数据。每条日志都带有主体、匹配的策略 ID、护栏标志和延迟。

客户端流程：从 M2M 到用户委托。

1. MCP 客户端访问网关 URL，收到带 WWW-Authenticate 的 401。
2. 它按 RFC 9728 / 8414 / 7591 做发现，并调用你的 DCR 垫片，铸造一个限定到用户的客户端。
3. 用户通过授权码 + PKCE，对着托管 UI（背后是企业 SSO）登录。令牌的 sub 声明就是真实用户。
4. tools/list 返回由 AgentCore Policy 过滤后的目录。两个不同组的用户会收到不同的工具列表。
5. 调用顺序为：Policy，然后请求拦截器，然后 Guardrails，然后目标，然后响应拦截器，然后 Guardrails。
6. 当目标需要用户身份才能访问 SaaS（GitHub、Slack）时，网关发出带授权 URL 的 -32042 征询。对于共享入站身份链的目标，代表用户（On-Behalf-Of，OBO）令牌交换会完全取代浏览器重定向。助手打开浏览器，在用户同意后调用 CompleteResourceTokenAuth，然后重试。

实现

使用 update-gateway 命令，以 LOG_ONLY 模式挂上策略引擎。

下面的 Cedar 策略把 RBAC 和参数级 ABAC 组合在一起：

// Payments deployers can deploy, but only to staging
permit (
  principal,
  action == AgentCore::Action::"DeployCI___invoke",
  resource
)
when {
  principal.hasTag("groups") &&
  principal.getTag("groups").contains("repo-payments-service") /* Note: for Cognito, the claim is cognito:groups, not groups. Refer to your deployed Gateway Cedar schema for the precise tag names. */ &&
  context.input.environment == "staging"
};

// Read-only tools are open to any authenticated principal with a group
permit (
  principal,
  action in [
    AgentCore::Action::"TicketSearch___invoke",
    AgentCore::Action::"DocsSearch___invoke"
  ],
  resource
) when { principal.hasTag("groups") };

第一条规则把有风险的部署钉在 staging。第二条让低风险读取保持顺畅。下面这些 OpenTelemetry 跨度属性（发到 aws/spans 日志组）展示一次 Deny 决策：

{
  "principal": "user:alice@example.com",
  "action": "DeployCI___invoke",
  "resource": "gateway/pilot-gateway/target/DeployCI",
  "decision": "Deny",
  "matchedPolicy": "policy-payments-deploy-staging",
  "reason": "context.input.environment != 'staging'"
}

这条记录就是合规团队一直在要的审计轨迹。

AgentCore Policy 中的原生 Amazon Bedrock Guardrails 集成（2026 年 7 月交付）让护栏可以直接写进 Cedar 策略，使用 suppressOutput 效果和 when guardrails 条件。拦截器 Lambda 方案仍然可用于护栏覆盖不到的结构变换。下面展示用于 PII 过滤的原生 Cedar 做法：

{
  "contentPolicyConfig": {
    "filtersConfig": [{ "type": "PROMPT_ATTACK", "inputStrength": "HIGH", "outputStrength": "NONE" }]
  },
  "sensitiveInformationPolicyConfig": {
    "piiEntitiesConfig": [
      { "type": "EMAIL", "action": "ANONYMIZE" },
      { "type": "US_SOCIAL_SECURITY_NUMBER", "action": "BLOCK" },
      { "type": "CREDIT_DEBIT_CARD_NUMBER", "action": "BLOCK" }
    ]
  }
}

社会安全号码（SSN）和卡号永远到不了模型。电子邮件会被掩码。

部署 DCR 垫片：Amazon API Gateway 后面的 Lambda，在 POST /register 时创建 Cognito 应用客户端，并把新的 client_id 追加到 allowedClients。提供指向 Cognito 的 RFC 9728 .well-known/oauth-protected-resource 元数据。

创建 3LO 凭据提供者并把它挂到目标上。下面是客户端必须处理的最小 -32042 征询：

{
  "jsonrpc": "2.0", "id": 7,
  "error": {
    "code": -32042,
    "message": "authorization_required",
    "data": {
      "authorization_url": "https://oauth.example.com/auth?session_uri=urn:session:9f3a",
      "session_uri": "urn:session:9f3a"
    }
  }
}

当下游资源信任与入站令牌相同的身份链时（例如内部微服务，或受 Microsoft Entra ID 保护的 API），网关可以改用代表用户（On-Behalf-Of，OBO）令牌交换。OBO 把入站访问令牌换成一个新的、限定范围的令牌，同时携带用户身份和智能体身份，没有浏览器重定向，也没有额外的同意流程。在目标上现有的 OAuth 凭据提供者里加入 onBehalfOfTokenExchangeConfig 块，网关就会透明地完成交换（依你的 IdP，使用 RFC 8693 或 RFC 7523）。

推出

阶段 1（第 1–2 天）： 部署 DCR 垫片 Lambda 和 API Gateway 端点。更新网关授权器，使其接受动态注册的客户端。阶段 2（第 1–2 周）： 以 LOG_ONLY 模式接入 AgentCore Policy。以仅检测模式部署 Guardrails。监控 aws.agentcore.policy.log_only_decision_flipping_policies，找出一旦提升就会改变决策的策略。阶段 3（第 3 周及以后）： 把 Policy 切换到 ENFORCE。把 Guardrails 切换到主动拦截。向用户说明 SSO 同意提示。

结果。 审计人员得到答案：谁在何时、依据哪条策略调用了哪个工具。PII 在助手收到响应之前就被擦除。

这一阶段之后，如果你开始遇到这样的问题：

• 平台工程师是否被“请加上这个工具”的工单淹没？用户能否不提交工单就发现并订阅工具？
• 用户是否需要访问不在 AWS 上的系统，例如本地数据库、另一朵云或外部 SaaS？
• 财务能否把网关支出归到真正驱动这笔费用的团队？

那么你就准备好扩大范围了。如果范围 2 已满足当前需要，直接跳到“考量”，阅读运维指导。

范围 3：目录、自助、注册表与跨环境可达

现在把它做成自助，并到达 AWS 之外的系统。

下图展示范围 3 的扩展架构，包括跨环境连通：

图 4：组织资源包括经 AWS PrivateLink 或 AWS Direct Connect 到达的本地系统，以及经出站 OAuth 到达的外部 SaaS；发现块包含带 Resources MCP 服务器的 AWS Agent Registry；OPA 拦截器加入请求和响应路径；FinOps 块采集 AWS Budgets 和 AWS Cost Explorer

何时： “加上这个工具”的工单堆积，或者你需要到达另一家供应商或本地环境。超过 100 名用户之后，集中目录和 AWS 之外的可达性就不再是可选项。

关键决策： 自助发布加审批，还是工单门禁。第一个本地或多云目标是什么。组织级策略规则和复杂 ABAC 逻辑用 OPA，还是只用 Cedar。

会改变什么

你不再是工具接入的瓶颈，网关也延伸到 AWS 之外的系统。工具所有者现在创建一份 YAML 清单来申请新工具，并打开一个拉取请求，触发安全扫描和平台评审。合并之后，持续集成流水线调用 create-gateway-target，并自动更新 Cedar 策略。不需要工单，也不需要手工 UpdateGateway。

你现在可以集中 IDE 可能需要的技能：它查询 AWS Agent Registry（现位于 agent-registry 命名空间，已在九个 AWS 区域可用），列出技能并下载与任务相关的那些。管理员通过审批工作流治理可发现性，因此人们只拿到自己需要的内容，把无关技能挡在助手上下文之外，减少提示污染。

请求离开网关后，目标可以在任何地方：AWS Lambda；你通过网关 VPC 出口（使用 managedVpcResource 或 selfManagedLatticeResource 配置）到达、背后是 AWS Direct Connect 或 AWS Site-to-Site VPN 的本地数据库；或者你通过 NAT 出口加出站 OAuth 到达的 SaaS API。客户端看不出差别。

在请求路径内部，现有请求拦截器 Lambda 中加入开放策略代理（Open Policy Agent，OPA）评估，用来覆盖 Cedar 无法原生表达的规则：时间窗口、载荷内容检查、基于速率的访问，以及变更工单要求。第二条 MCP 连接（Resources MCP 服务器）在会话开始时自动拉取，并分发组织上下文，例如引导文件、编码标准、提示模板、发布检查清单和值班运行手册。组织里的每个助手都拿到同一份上下文，无需按开发者逐个配置。

在云成本运营（FinOps）方面，Amazon CloudWatch 指标过滤器和 AWS Cost Explorer 标签按工具、按组归属成本。财务终于能回答是谁推高了账单。mcp.json 现在集中管理，无法再自行添加公开配置，并通过 MDM 或中央 MCP 注册表分发。除网关之外，你还集中管理 IDE 管理配置，由它控制行为。

客户端流程。 引导与范围 2 相同，没有新的身份验证流程。Resources MCP 服务器在 mcp.json 里的第二条记录会在会话开始时自动拉取，提供组织标准和已批准的技能。调用仍然经过网关。目标可能在本地或 SaaS 中，客户端看不出来。范围 3 在客户端侧是增量的，因此推出风险低。

实现片段。

下面的 OPA Rego 策略处理一条 Cedar 无法原生表达的规则。db_write 只允许在工作日、UTC 09:00 到 17:00，并且附有变更工单：

package mcp.tools

import rego.v1

default allow := false

allow if {
  input.tool == "db_write"
  clock := time.clock(time.now_ns())
  clock[0] >= 9
  clock[0] < 17
  weekday := time.weekday(time.now_ns())
  not weekday in {"Saturday", "Sunday"}
  input.claims.change_ticket_id != ""
}

OPA 原生处理时钟和星期检查，补足 Cedar 基于身份和资源的策略。

下面是新工具的 Registry YAML 清单：

# registry/tools/payment-refund.yaml
name: PaymentRefund
owner: payments-platform@example.com
target:
  type: lambda
  arn: arn:aws:lambda:us-west-2:<account-id>:function:payment-refund
access:
  allowed_groups: [finance-ops, senior-support]
  environments: [staging] # prod requires separate approval
  risk_tier: high

工具所有权、访问权限和风险与其余基础设施一起放在版本控制里。持续集成流水线校验清单、运行安全扫描、打开拉取请求供评审，并在合并时调用 create-gateway-target、更新 Cedar 策略。

下面的 Resources MCP 服务器配置分发给每个助手，暴露 get_coding_standards、get_prompt_library、get_release_checklist 和 get_oncall_runbook 等工具：

{
  "mcpServers": {
    "resources-gateway": {
      "url": "https://<gateway-name>.gateway.bedrock-agentcore.<region>.amazonaws.com/mcp/resources",
      "type": "http"
    }
  }
}

组织里的每个助手现在都能访问同一套编码标准和运行手册，无需手工设置。

下面的命令从一台通过 AWS Direct Connect 与本地对等的虚拟私有云（virtual private cloud，VPC）创建进入网关的 PrivateLink 端点：

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0a1b2c3d4e5f67890 \
  --service-name com.amazonaws.<region>.bedrock-agentcore \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-0aaa1111 subnet-0bbb2222 \
  --security-group-ids sg-0ccc3333

网关流量现在留在 AWS 网络上。从那里起，由 AWS Direct Connect 处理到本地的那一跳。对于非 MCP 端点（A2A 智能体 URL、遗留 REST API），HTTP 透传目标直接路由流量，不做协议转换。

下面的 AWS Budgets 警报在某个工具超过月度调用成本阈值时触发：

{
  "BudgetName": "GatewayTool-PaymentRefund",
  "BudgetLimit": { "Amount": "250", "Unit": "USD" },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST",
  "CostFilters": { "TagKeyValue": ["user:AgentCoreTool$PaymentRefund"] }
}

按工具打标签意味着财务可以把支出归到拥有该工具的团队，而不是归到平台。

推出

阶段 1（第 1 周）： 建立 YAML 清单模式和 CI 流水线。把现有目标迁移到由清单驱动的注册。阶段 2（第 2–3 周）： 部署 OPA 拦截器。创建 Resources MCP 服务器。为本地目标建立 PrivateLink 或 Direct Connect。阶段 3（第 4 周及以后）： 配置成本分配标签和 Budgets 警报。分发更新后的 mcp.json。按组推出，从提交工具申请工单最多的团队开始。

结果。 范围 2 那种工单驱动的接入被取消。自然语言发现缩短上手时间，网关可以到达本地和多云，而无需搬迁工作负载。

这一阶段之后，如果你开始遇到这样的问题：

• 你的网关是否仍能从公共互联网到达，监管机构会接受吗？
• 如果主区域在营业时间故障，用户要遵循的、已写下来的恢复路径是什么？
• 上个季度有多少已注册工具的调用次数为零，又是谁在为把它们留在账上付钱？

那么你就准备好扩大范围了。如果范围 3 已满足当前需要，直接跳到“考量”，阅读运维指导。

范围 4：加固、韧性与治理

目录和可达性已经在工作。范围 4 加固边缘，并为中断做计划。

下图展示带专用入口和治理仪表盘的加固架构：

图 5：新的入口栈包含 Amazon CloudFront、公共子网中仅允许 CloudFront 的应用负载均衡器、私有子网中的 VPC 端点、PrivateLink 和网关；治理面板包含 Amazon Athena、自定义仪表盘，以及一个标记未使用资源的 Lambda 函数

何时：需要高可用和韧性的 AI 工作负载、受严格监管的行业，或有低延迟和灾难恢复（disaster recovery，DR）要求的全球用户群。

关键决策： 熔断器的爆炸半径。主主还是主备 DR。网关的服务级别目标（Service Level Objective，SLO）。弃用权限归谁。

会改变什么

你加固边界，并把治理变成监管机构一眼就能读懂的东西。请求现在从企业网络内部开始。IDE 不再解析公网网关主机名，而是经边缘的 Amazon CloudFront（靠近用户）路由。CloudFront 转发到公共子网中仅允许 CloudFront 的应用负载均衡器，使用共享密钥请求头，防止流量绕过 CloudFront。请求接着经过私有子网中的 VPC 端点，到 PrivateLink，最后到网关。公网 DNS 暴露消失，网关只能经你的专用路径到达。对于托管在 Runtime 上的智能体，启用仅入站强制，使 Runtime 拒绝任何并非来自网关的调用。这可以防止调用方绕过策略、护栏和审计。

请求仍走与范围 3 相同的路径，但现在每一项决策都流入 Amazon CloudWatch 和 AWS CloudTrail，由 Amazon Athena 查询回答合规级问题。例如：“上周哪些主体的拒绝率最高，又是哪些策略拒绝了他们？”自定义仪表盘呈现调用次数、延迟百分位、护栏介入率、每条策略的拒绝率、被拒绝最多的主体，以及带异常警报的管理层合规视图。

对全球用户，多可用区在一个区域内提供较强韧性。你再用带健康检查的 Amazon Route 53 故障转移，以及多区域主备部署来扩展；网关定义和注册表状态通过流水线复制。把工具设计成幂等，这样 DNS 故障转移后的第一次重试是安全的。

最后，一个夜间运行的弃用 Lambda 读取 Amazon CloudWatch 调用指标，对 30 天内零使用的任何工具打开一个拉取请求。通知所有者，注册表标记该工具，策略转到 LOG_ONLY，90 天后移除目标。网关不会积累僵尸。

客户端流程。 身份验证和发现与范围 3 保持不变。助手运行在企业网络上，有到网关 PrivateLink 端点的路由，主机名可能只在网内可解析。有了 Route 53 故障转移，失败的请求会触发 DNS 重新解析，并落到次区域。客户端现在还要额外处理展示给用户的弃用头（RFC 8594）、配额耗尽时带 Retry-After 的 429，以及可选地通过 traceparent 与网关跨度关联的 OpenTelemetry 追踪。

实现。

下面的 Amazon Route 53 故障转移记录集配置两个区域中的网关端点：

[
  {
    "Name": "gateway.example.com.", "Type": "CNAME", "SetIdentifier": "primary-us-west-2",
    "Failover": "PRIMARY", "TTL": 30,
    "HealthCheckId": "hc-0123456789abcdef0",
    "ResourceRecords": [{"Value": "dxxxxxxxxxxxxx.cloudfront.net"}]
  },
  {
    "Name": "gateway.example.com.", "Type": "CNAME", "SetIdentifier": "secondary-eu-west-1",
    "Failover": "SECONDARY", "TTL": 30,
    "ResourceRecords": [{"Value": "dyyyyyyyyyyyyy.cloudfront.net"}]
  }
]

主健康检查失败时，DNS 在一个 TTL 内切换到次区域。

下面这条针对 AWS CloudTrail 的 Amazon Athena 查询回答“上周哪些主体的拒绝率最高，又是哪些策略拒绝了他们？”：

SELECT attributes.`aws.agentcore.policy.determining_policies` as policies, COUNT(*) AS denies,
  DATE_TRUNC('day', from_iso8601_timestamp(event_time)) AS day
FROM aws_spans_export
WHERE attributes.`aws.agentcore.policy.authorization_decision` = 'DENY'
  AND from_iso8601_timestamp(event_time) > current_date - INTERVAL '7' DAY
GROUP BY principal, matched_policy, DATE_TRUNC('day', from_iso8601_timestamp(event_time))
ORDER BY denies DESC
LIMIT 25;

这条 CloudWatch Logs Insights 查询（在网关启用追踪后，针对 aws/spans 日志组运行）为仪表盘磁贴供数，在用户开始提工单之前暴露漂移。

下面的 AWS 云开发工具包（AWS Cloud Development Kit，AWS CDK）片段建立 CloudFront、仅允许 CloudFront 的应用负载均衡器，以及 VPC 端点栈：

distribution = cloudfront.Distribution(self, "GatewayEdge",
    default_behavior=cloudfront.BehaviorOptions(
        origin=origins.LoadBalancerV2Origin(alb,
            custom_headers={"X-Origin-Verify": origin_secret.secret_value.unsafe_unwrap()}),
        allowed_methods=cloudfront.AllowedMethods.ALLOW_ALL,
        viewer_protocol_policy=cloudfront.ViewerProtocolPolicy.HTTPS_ONLY,
    ),
    web_acl_id=waf_acl.attr_arn,)

ec2.InterfaceVpcEndpoint(self, "GatewayEndpoint",
    vpc=vpc, service=ec2.InterfaceVpcEndpointAwsService("bedrock-agentcore.gateway"),
    subnets=ec2.SubnetSelection(subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS))

共享密钥请求头确保流量只经 CloudFront 到达应用负载均衡器，而不是经直接 DNS。

下面的夜间弃用 Lambda（伪代码）读取 Amazon CloudWatch 指标并打开弃用拉取请求：

def handler(event, _ctx):
    for tool in list_registry_tools():
        datapoints = cw.get_metric_statistics(
            Namespace="AWS/BedrockAgentCore",
            MetricName="Invocations",
            Dimensions=[{"Name":"ToolName","Value":tool.name}],
            StartTime=now()-timedelta(days=30), EndTime=now(),
            Period=86400, Statistics=["Sum"],
        )["Datapoints"]
        if sum(p["Sum"] for p in datapoints) == 0:
            open_pr(f"deprecate/{tool.name}",
                body="No invocations in 30d; moving to LOG_ONLY, removal in 90d.")

僵尸工具通过当初创建它们的同一套代码评审流程被自动退役。

推出

阶段 1（第 1–2 周）： 部署 CloudFront + ALB + VPC 端点栈。更新 DNS。验证公网端点不再可解析。阶段 2（第 3–4 周）： 部署 Athena 表和治理仪表盘。设置 Route 53 健康检查和故障转移记录。把网关定义复制到次区域。阶段 3（第 2 个月）： 部署弃用 Lambda。做一次故障转移演练：禁用主健康检查，并验证 DNS 切换。

结果。 零信任网络控制、专用连接、边缘的全球低延迟访问，以及写下来的恢复路径。治理变成一个看得见的产品。

以上覆盖了完整的四范围构建，但多数团队并不需要每一个范围。本文其余部分帮助你决定在哪里停下，给出一个真实示例，并覆盖运维考量。

参照部署时间线

下面的时间线展示一家有代表性的金融服务机构如何在六个月内走完这四个范围。

范围 1（第 1 周）。 两名分析师让 Amazon Quick 对着一个 staging SQL 工具运行。AgentCore Gateway 用 Cognito M2M 身份验证挡在前面。基础设施工程从第一天起拥有这个网关。

范围 2（第 2–4 周）。 三个台席、三十名分析师。DCR 垫片、授权码 + PKCE、台席级 RBAC、针对 PII 的 Guardrails、CloudTrail。推出中途切换身份验证流程很别扭。合规的第一次审计查询在第一次尝试就返回了完整结果。

范围 3（第 2–3 个月）。 五个部门、两百名用户。Registry 让工具可被发现。交易系统经 Direct Connect 留在本地。Resources MCP 分发检查清单。工单队列在两周内下降约 40%。

范围 4（第 6 个月）。 全行 1,000 名用户。MiFID II 要求不可变审计和网络隔离。PrivateLink 去掉了公网 DNS。Route 53 故障转移满足了 4 小时恢复时间目标（Recovery Time Objective，RTO）。

结果。 监管机构可以追溯哪名分析师在哪条策略下查询了哪些头寸。每个范围的升级触发器是一个具体的组织问题，而不是预先排定的时间表。

考量

这些考量贯穿每一个范围。请注意，Amazon Bedrock AgentCore Gateway 和 Amazon Bedrock Guardrails 的可用性因 AWS 区域而异。当前的区域支持见 Amazon Bedrock AgentCore 文档。

网关运维。 从第一天起，就用与生产服务同等的运维实践对待网关。事后改动代价更高。开发、staging 和生产分属不同 AWS 账户、不同的 IdP 客户端 ID 和策略引擎，并通过基础设施即代码（Infrastructure as Code，IaC）提升。选择一个全组织网关，或按业务单元隔离。在接入时强制命名。按风险等级、数据分类、所有者服务级别协议（service level agreement，SLA）和身份验证模型契合度评估新工具。注册流程：申请、评审、扫描、staging、浸泡、生产。

安全。 明文凭据和未限定范围的出口会制造无意访问的机会。把凭据存在 AWS Secrets Manager 或 HashiCorp Vault 中并轮换，或者用私钥 JWT 客户端身份验证彻底取消共享密钥（私钥在 AWS KMS 中，每一次签名操作都记入 CloudTrail）。绝不要把凭据放在环境变量里。通过 MDM 分发集中管理的 mcp.json。在企业代理或端点检测与响应（endpoint detection and response，EDR）处阻断助手通往非网关 MCP 端点的流量。要求 TLS 1.2+，以及静态数据使用 AWS Key Management Service（AWS KMS）加密。使用带 aws:CalledViaAWSMCP 或 aws:ViaAWSMCPService 的 AWS IAM 服务控制策略（Service Control Policy，SCP），拒绝经 AWS 托管 MCP 服务器调用的破坏性操作（这些键不适用于经过你自己的 AgentCore Gateway 的流量。对你自己的网关，应改为限制目标执行角色）：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyDestructiveFromMCP",
    "Effect": "Deny",
    "Action": ["s3:DeleteBucket","kms:ScheduleKeyDeletion","dynamodb:DeleteTable"],
    "Resource": "*",
    "Condition": { "Bool": { "aws:ViaAWSMCPService": "true" } }
  }]
}

如果一条 Cedar 策略漏过了评审，SCP 这条后盾会挡住最坏的结果。

韧性。 网关宕机时，依赖它的所有助手都不可用。每一个网关、目标、策略和注册表条目都以代码形式交付。联邦的区域网关覆盖数据驻留（欧盟、中国、俄罗斯）。复制的是策略，不是数据。一个网关同时服务 Kiro、Claude Code、Amazon Quick 和 Glean。

成本。 成本意外来得比用量报告更快。按主体、按工具限速（网关可配置的速率限制原生支持，不额外收费，并可按 JWT 声明、目标和工具名做维度限定）。按组设置预算和配额，在硬停止之前先发软警报。对幂等的读取工具，在拦截器缓存响应，以减少重复调用。作为参考定价，大约 50 名开发者每月合计运行 572,000 次操作，Gateway 与 Policy 合计约 17 美元（Gateway InvokeTool 为每百万次 5 美元，加上 Policy 授权每百万次 25 美元；经 Gateway 消费时 Identity 费用为 0 美元）（当前费率见 Amazon Bedrock AgentCore 定价页）。

清理资源

如果你在按本文操作时部署了资源，请删除它们，以免持续产生费用。按创建的相反顺序删除资源，以避免依赖错误。

范围 4 的资源：

1. 删除 Amazon Route 53 故障转移记录和健康检查。
2. 删除 CloudFront 分配。
3. 删除应用负载均衡器、目标组和关联的安全组。
4. 删除 bedrock-agentcore 的 VPC 端点。
5. 移除弃用 Lambda 及其 CloudWatch Events 规则。
6. 删除 Amazon Athena 表和工作组。

范围 3 的资源：

1. 删除 AWS Budgets 警报和成本分配标签。
2. 移除用于本地连通的 PrivateLink VPC 端点。
3. 从网关删除 Resources MCP 服务器目标。
4. 移除由 YAML 清单创建的已注册工具目标。
5. 删除 OPA 拦截器 Lambda。

范围 2 的资源：

1. 删除 Guardrails 配置。
2. 删除请求拦截器和响应拦截器 Lambda。
3. 删除 DCR 垫片 Lambda 及其 Amazon API Gateway 端点。
4. 从 AgentCore Policy 移除 Cedar 策略。
5. 删除用于 ABAC 规则的 DynamoDB 表。

范围 1 的资源：

1. 使用 DeleteGatewayTarget 删除网关目标（例如 TicketSearch）。
2. 删除网关本身：aws bedrock-agentcore-control delete-gateway --gateway-identifier pilot-gateway（见 DeleteGateway）。
3. 删除 Cognito 用户池应用客户端；如果用户池是为此目的创建的，也一并删除。
4. 删除网关使用的 IAM 角色（GatewayRole）。

持续改进

治理是一个活的系统。

每季度。 审阅拒绝日志并调整策略，收紧过于宽松的规则，放宽那些制造摩擦却不降低风险的规则。审计 PrivateLink 端点和出口规则。移除任何未使用的东西。收窄网关执行角色。保持 Resources MCP 内容新鲜，并为引导文件做版本管理。强制执行弃用机制，使注册表里的僵尸工具为零。

每月。 审阅成本异常、护栏介入尖峰，以及被拒绝最多的主体。被拒绝最多的主体往往说明策略过紧。

持续。 每一次工具注册和策略变更都以拉取请求交付，并由安全和平台组评审。

结论

在本文中，我们演练了一个用于治理 AI 智能体工具访问的四范围成熟度模型，从单一受治理端点一直到企业级加固。用这种方法，团队把 AI 生产力与治理控制一起交付，只在真实痛点要求时才前进。

如果你刚刚开始，在一个开发账户里架起范围 1 网关，把一个助手指向它，并分发新的 mcp.json。

如果你需要合规，先以范围 1 为底座（它需要一天），再叠上范围 2：加入 DCR 垫片，以 LOG_ONLY 接入 Cedar，并以仅检测模式启用 Guardrails。两个范围可以在一个冲刺内一起部署。

如果你正在扩展生产，范围 3 的注册表和自助发布能立刻带来用户可见的收益。按工具打标签给财务提供归属。按组推出。

随着 IDE 驱动的助手成熟，同一个网关会成为自主智能体的控制平面。网关不仅提供工具访问，还提供智能体到智能体的任务委托，每一次调用都经过策略。

选择与今天的痛点匹配的范围，并用 Amazon Bedrock AgentCore Gateway 开发者指南 部署你的第一个网关。先把一个低风险工具放在网关后面，用身份提供者验证端到端令牌流，只在遇到下一个治理问题时才扩大范围。

本指南展示了一个示例实现，说明如何用 AgentCore Gateway 构建治理层和工具网关。

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/govern-ai-agent-tool-access-with-amazon-bedrock-agentcore-gateway