Amazon Bedrock AgentCore：企业AI Agent工具访问治理框架

在我们过去几个月与客户的交流中，一个模式反复出现。无论他们使用的是编码智能体、自主智能体还是人机交互智能体，无论工作负载成熟度如何，我们都会以同一个问题开场："哪些 AI 智能体可以访问客户数据，谁授予了访问权限，如果今天凭证泄露，暴露面会是什么样子？"如果你的组织里没有一个人能在一分钟内回答这个问题，这篇文章就是为你写的。

当 AI 智能体在没有集中治理的情况下连接内部工具时，组织会遇到难以检测的访问风险。想象一下，一位基础设施工程师打开队友的笔记本电脑来调试构建。在配置文件夹中有一个名为 mcp.json 的文件，其中以明文形式存储着生产数据库密码，旁边还有一行注释：TODO: rotate this。安全团队无法洞察哪些 AI 智能体正在访问内部工具、谁授予了访问权限，也无法知晓如果该凭证被无意泄露会造成什么后果。

拟议的解决方案使用支持 Model Context Protocol（MCP）的助手，包括 Kiro、Claude Code、Cursor 等 IDE 助手，以及 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 使用之前构建一个完整的网关，这需要数月时间，而且交付的东西也不对。我们建议根据实际需求匹配控制措施。

解决方案：四个阶段的能力成熟度之旅

一个受治理的网关提供一个统一的受治理端点，知道是谁在调用以及凭借什么权限，在工具和参数级别强制执行策略，并记录每个决策。团队也可以无需工单即可发布工具。每个阶段都提供独立的价值，同时保留通往下一阶段的路径。

第一阶段：连接。一扇受治理的门，让 AI 智能体可以访问组织资源。当 MCP 凭证位于本地配置中且安全团队没有清单时，应用 SSO 认证、集中化凭证并启用 CloudTrail 审计。

第二阶段：控制。了解谁做了什么，并在过程中清除敏感数据。当你无法回答"谁在何时在哪个策略下调用了哪个工具？"时，应用 Cedar RBAC/ABAC、PII 去标识化、3LO 同意和 DCR。

第三阶段：目录。让团队可以自己查找和发布工具，包括本地部署的工具。当工具注册需要工单且本地系统被排除在外时，部署 Registry、Resources MCP、OPA 并按工具进行成本归属。

第四阶段：加固。锁定边界，监控一切，并为失败做准备。当你拥有超过 1000 名用户但没有熔断器、公共 DNS 且没有故障转移时，添加私有连接、治理仪表板、废弃工作流和多区域故障转移。

每个阶段都提供独立的价值。只有当下一个痛点出现时才推进到下一阶段。下图是阶段决策的参考。

图 1：基于你所面临的治理痛点选择阶段的参考

以下各节将逐个阶段构建网关。首先满足前提条件，然后在出现新的治理问题时逐步推进每个阶段。

要阅读本文，你需要拥有一个具有创建 Amazon Bedrock AgentCore 和 Amazon Cognito 资源权限的 AWS 账户，熟悉 OAuth 2.0 和 AWS Identity and Access Management（IAM），具备基本的 AWS Command Line Interface（AWS CLI）经验，以及了解 Model Context Protocol（MCP）。

第一阶段：连接，最小化受治理网关

下图说明了第一阶段的最小拓扑：

图 2：MCP 客户端连接到 AgentCore Gateway，Amazon Cognito 颁发 JWT 进行认证，AgentCore Identity 管理出站凭证，一个注册目标接收工具调用

何时需要此阶段：1-20 名试点用户、低风险工具、影子 MCP 开始出现。

关键决策：网关所有权（基础设施工程、安全或共享）。首个工具选择。是否强制仅使用网关或与旧有 mcp.json 共存。

你部署 AgentCore Gateway，配置基于 Cognito 的 JWT 授权器，并注册一个低风险 Lambda 目标（例如，一个只读工单搜索）。授权保持粗粒度：任何已认证的客户端都可以调用任何已注册的工具。mcp.json 在现有公共资源旁边新增一个条目，强调缓慢的、增量的变更。

你可以引入自己的身份提供商（IdP），例如 Amazon Cognito，并与 AgentCore Identity 集成，后者处理机器对机器（M2M）认证（通过 OAuth 2.0）、AWS 资源的出站认证，或 AWS Secrets Manager 的 API 密钥认证。现在你可以通过原生 Amazon CloudWatch Logs 和 AWS CloudTrail 了解组织和资源何时被访问。

助手通过预配置的 client_id/client_secret 和网关 URL 进行引导。

每个会话中，它获取 Cognito 令牌并将 bearer 附加到 tools/list 和 tools/call。

网关验证 JWT 并路由到目标。

后端凭证永远不会离开 AWS。

实现代码片段

使用指向 IdP（例如 Cognito）的 JWT 授权器创建网关，并配置 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 文件中。

第一阶段（第一天）：配置 Cognito 用户池。部署网关。注册一个低风险 Lambda 目标。第二阶段（第 2-3 天）：通过 MDM 分发更新后的 mcp.json。验证端到端：令牌获取 → tools/list → tools/call。第三阶段（第一周）：确认 CloudWatch Logs 和 CloudTrail 条目在每次调用时出现。

结果：端到端路径正常工作，mcp.json 现在包含一个可访问组织范围资源的端点，管理层观察到生产力和控制措施同步推进。

在此阶段之后，如果你开始收到以下问题：

• 用户在工具调用中是否传递了任何 PII（个人身份信息）？我们如何防止这种情况？
• 我们是否征求了用户对其代表执行的操作的同意？我们如何验证问责制？
• 用户组应该对工具拥有不同的访问权限。这可能吗？

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

门已打开后，范围 2 需要为调用方命名，并对流经的内容进行清洗。

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

图 3：网关、身份与策略由请求和响应拦截器及 Amazon Bedrock Guardrails 包裹；身份增加了 DCR 接口（用于 .well-known 端点的 Lambda 和 Amazon API Gateway）、AWS IAM 和 Amazon DynamoDB，3LO 采集将用户重定向到浏览器进行授权

时机：用户群体不断增长，合规团队追问"谁在什么策略下做了什么"。你需要给出答案，且 PII 必须在到达前被清洗掉。

关键决策：身份提供商选择。过认证模型（代码流与客户端凭据对比）。LOG_ONLY 时长再到 ENFORCE。第一条 Cedar 拒绝规则。

你将网关从机器级信任转变为用户级信任。客户端现在通过动态客户端注册（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 过滤器、内容策略和提示攻击检测，无需自定义代码。对于 Guardrails 覆盖范围之外的结构转换或 ABAC 规则，请求拦截器 Lambda 处理剩余部分。当目标资源需要用户的身份信息以便访问 SaaS 系统（例如 GitHub 或 Figma）时，AgentCore Identity Credential Providers 处理 3LO 授权码流程。网关发出 MCP 采集（-32042 错误），以便助手引导用户在浏览器中完成授权。

在响应阶段，拦截器清洗非故意泄露的数据。每条日志记录都携带主体、匹配的策略 ID、护栏标志和延迟。

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

MCP 客户端访问网关 URL 并收到带有 WWW-Authenticate 的 401。

它遵循 RFC 9728 / 8414 / 7591 发现流程，调用 DCR 适配层来铸造用户范围的客户端。

用户通过授权码 + PKCE 针对托管 UI（由企业 SSO 支持）登录。令牌的 sub 声明是实际用户。

tools/list 返回经 AgentCore Policy 过滤后的目录。两个不同组的用户收到不同的工具列表。

调用流程：策略 → 请求拦截器 → 护栏 → 目标 → 响应拦截器 → 护栏。

当目标需要用户的身份访问 SaaS（GitHub、Slack）时，网关发出带有授权 URL 的 -32042 采集。对于共享入站身份链的目标，OBO 令牌交换完全替代浏览器重定向。助手打开浏览器，调用 CompleteResourceTokenAuth 完成授权，然后重试。

使用 update-gateway 命令将策略引擎附加到 LOG_ONLY 模式。

以下 Cedar 策略结合了 RBAC 和参数级 ABAC：

// Payments 部署人员可以部署，但只能部署到 staging
permit (
  principal,
  action == AgentCore::Action::"DeployCI___invoke",
  resource
)
when {
  principal.hasTag("groups") &&
  principal.getTag("groups").contains("repo-payments-service") /* 注意：对于 Cognito，声明是 cognito:groups 而不是 groups。请参阅你部署的网关 Cedar schema 以获取精确的标签名称。 */ &&
  context.input.environment == "staging"
};

// 只读工具对任何带有组的已认证主体开放
permit (
  principal,
  action in [
    AgentCore::Action::"TicketSearch___invoke",
    AgentCore::Action::"DocsSearch___invoke"
  ],
  resource
) when { principal.hasTag("groups") };

第一条规则将高风险部署限定在 staging。第二条保持低风险读取的无摩擦体验。以下 OpenTelemetry span 属性（发送到 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 效果和 guardrails 条件来表达。对于 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" }
    ]
  }
}

社保号和卡号永远不会到达模型。电子邮件会被脱敏。

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

创建 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；一个 Discovery 块包含 AWS Agent Registry 与 Resources MCP 服务器，一个 OPA 拦截器加入请求和响应路径，一个 FinOps 块捕获 AWS Budgets 和 AWS Cost Explorer

时机：当"添加此工具"工单堆积如山，或者需要接入另一个供应商或本地系统时。超过 100 名用户后，统一的工具目录和跨 AWS 的能力不再是可选项，而是必选项。

关键决策：自助发布（需审批）或工单门禁。先锁定本地部署或多云目标。用 OPA 实现全组织级策略规则，用 Cedar 实现复杂的 ABAC 逻辑（或只用 Cedar）。

此时你不再是工具接入的瓶颈，网关可以扩展到 AWS 以外的系统。工具所有者现在只需创建一个 YAML 清单来申请新工具，然后提交一个 pull request，即可触发安全扫描和平台审查。合并后，持续集成流水线会调用 create-gateway-target 并自动更新 Cedar 策略。无需工单，无需手动 UpdateGateway。

你现在可以将 IDE 需要的各种技能集中管理：它查询 AWS Agent Registry（在 agent-registry 命名空间下，已在九个 AWS 区域可用）来列出技能，并下载与当前任务相关的那些。管理员通过审批工作流控制可发现性，确保用户只获取他们需要的内容，将无关技能挡在助手上下文之外，从而减少提示词污染。

当请求离开网关时，目标可能部署在任何地方：AWS Lambda、通过 Gateway VPC Egress 访问的本地数据库（使用 managedVpcResource 或 selfManagedLatticeResource 配置），其背后依托 AWS Direct Connect 或 AWS Site-to-Site VPN；或者通过 NAT Egress 访问的 SaaS API（配合出站 OAuth）。客户端无法感知其中的差异。

在请求链路内部，Open Policy Agent（OPA）评估被嵌入现有的 request-interceptor Lambda 中，用于处理 Cedar 原生无法表达的那些规则：时间窗口、负载内容检查、基于频率的访问控制，以及变更工单要求。第二个 MCP 连接（Resources MCP server）在会话启动时自动获取并分发组织上下文，例如指引文件、编码规范、提示词模板、发布检查清单和值班手册。组织中的每个助手无需逐个开发者配置，就能获得相同的上下文。

在 FinOps 方面，Amazon CloudWatch 指标过滤器和 AWS Cost Explorer 标签可按工具和按组进行成本归因。财务终于能回答是谁推动了账单。mcp.json 现在由中央统一管理，无法自行添加公共配置，并通过 MDM 或中央 MCP 注册表进行分发。除网关外，你还集中管理 IDE 管理员配置，以控制行为。

客户端流程。引导匹配 Scope 2，无需新的认证流程。第二个 mcp.json 条目（Resources MCP server）在会话启动时自动获取，提供组织标准和已批准的技能。调用仍然经过网关。目标可能在本地或 SaaS 上，客户端无法感知差异。Scope 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

工具的所有权、访问权限和风险等级与基础设施的其他部分一起纳入版本控制。持续集成流水线验证清单、运行安全扫描、开启审查 pull request，并在合并后调用 create-gateway-target 和更新 Cedar 策略。

以下 Resources MCP server 配置分发给每个助手，暴露 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"
    }
  }
}

组织中的每个助手现在无需手动配置，即可访问相同的编码规范和值班手册。

以下命令通过 Virtual Private Cloud（VPC）创建通向网关的 PrivateLink 端点，该 VPC 通过 AWS Direct Connect 与本地环境对等连接：

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 agent URL、遗留 REST API），HTTP 直通目标将流量直接路由，无需协议转换。

以下 AWS Budgets 告警在工具超出月度调用成本阈值时触发：

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

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

第一阶段（第 1 周）：建立 YAML 清单架构和持续集成流水线。将现有目标迁移到清单驱动的注册方式。第二阶段（第 2–3 周）：部署 OPA 拦截器。创建 Resources MCP server。建立通往本地目标的 PrivateLink 或 Direct Connect 连接。第三阶段（第 4 周起）：配置成本分配标签和 Budgets 告警。分发更新后的 mcp.json。按组逐步推广，从团队层面开始。