AWS Bedrock AgentCore：为企业治理提供带有 IAM、OAuth 2.0 JWT 和 CloudWatch 可观测性的无服务器 MCP 代理
AWS 于 2026 年 4 月 29 日发布了在 Amazon Bedrock AgentCore Runtime 上将自定义 MCP 代理部署为无服务器工作负载的参考架构。该代理部署在 AI 智能体与上游 MCP 服务器之间，可注入治理控制——输入验证、PII 编辑、审计日志和速率限制——无需修改现有系统。该架构使用 FastMCP 框架进行动态工具发现，支持 IAM/SigV4 和 OAuth 2.0 JWT 认证，并与 CloudWatch 和 OpenTelemetry 集成。
AWS 于 2026 年 4 月 29 日发布了在 Amazon Bedrock AgentCore Runtime 上将自定义 MCP 代理部署为无服务器工作负载的参考架构。该实现直接面向已为 AI 工具建立治理和合规逻辑、但不希望将现有基础设施重构为 Lambda 函数或 sidecar 容器的组织。文章作者是 AWS 高级解决方案架构师 Nizar Kheir。
MCP 代理层的架构是什么？
系统由三层组成，彼此独立相互认证。MCP 客户端层包含 AgentCore Runtime 上的智能体工作负载。MCP 代理层是处理治理逻辑的自定义中间层——这是本次发布的新内容。上游服务器层包含现有的 MCP 端点（AgentCore Gateway、自托管服务器、第三方服务）。代理透明地转发请求并应用自身的转换逻辑，这意味着现有工具无需知道代理存在于路径中。
代理如何发现上游工具并认证调用？
代理使用 FastMCP 框架在启动时通过 tools/list 请求动态发现上游工具——工具随后在本地重新暴露，无需手动注册。认证支持两种方式：IAM/SigV4，代理继承执行角色并自动签署出站请求；以及 OAuth 2.0 客户端凭证授权，带有 JWT Bearer Token，Token 缓存在内存中并自动刷新。内置可观测性通过 CloudWatch Logs 和 OpenTelemetry 集成实现。
AWS 参考实现中有哪些具体的治理示例？
两个示例展示了这一方法的强大之处。PII 令牌化：代理拦截工具参数，在发送到后端系统之前用可逆令牌替换敏感数据（个人 ID、卡号），并在响应中还原令牌——后端始终看不到原始 PII 数据。基于身份的工具限制：工具处理程序中的策略检查限制特定调用者可以调用哪些工具，可选择过滤 tools/list 响应，使调用者看不到无权使用的工具。Kheir 强调：“此架构中的每一层都独立进行认证。您通过代理在 MCP 协议层注入自己的逻辑，而上游服务器继续执行工具并处理自己的授权。“GitHub 仓库包含用于 IAM 角色、容器构建和 AgentCore 部署的自动化 setup_and_deploy.py 脚本。
常见问题
- AgentCore Runtime 上的 MCP 代理是什么？
- 部署在 AI 智能体与上游 MCP 服务器之间的自定义中间层。作为 Amazon Bedrock AgentCore Runtime 上的无服务器工作负载实现，它透明地转发请求，同时应用自定义治理逻辑——输入验证、PII 编辑、审计日志、速率限制。
- 支持哪些认证方式？
- 两种：IAM/SigV4（代理继承执行角色并自动签署出站请求）和带有 JWT Bearer Token 的 OAuth 2.0 客户端凭证授权（Token 缓存在内存中并自动刷新）。架构的每一层独立进行认证。
- 它如何具体地帮助实现治理？
- AWS 参考实现中有两个示例：PII 令牌化——代理拦截工具参数，在发送到后端之前用可逆令牌替换敏感数据，并在响应中还原令牌。基于身份的工具限制——工具处理程序中的策略检查过滤调用者在 tools/list 响应中可见的工具。
本文由人工智能基于一手来源生成。