看懂 AgentCore Runtime：入站鉴权、执行身份与出站网络
部署 AgentCore Runtime 时，最容易混淆的是调用者权限、运行时角色和网络连通性。把三条链路拆开，403、AccessDenied 和连接超时就容易定位了。
一个 Agent 部署到 Amazon Bedrock AgentCore Runtime 后，可能出现几种看起来很像、实际完全不同的故障：
- 客户端调用 endpoint，直接收到 401 或 403；
- 请求已经进入容器，调用 Bedrock、S3 或 Secrets Manager 时收到
AccessDenied； - IAM 权限看上去都对，但访问数据库或外部 API 一直超时。
如果把这些问题统称为“权限没配好”，排查很快会乱。AgentCore Runtime 至少有三条相互独立的链路：谁能调用 Runtime，Runtime 里的代码以什么 AWS 身份执行，以及代码发出的网络包从哪里出去。
先把这三条线画开，再看策略、角色和子网，效率会高很多。
第一条链路：谁能把请求送进 Runtime
入站链路的起点是调用方，终点是 AgentCore Runtime endpoint。它解决的问题很单纯：这个请求有没有资格进入运行环境。
截至 2026 年 7 月，AWS 文档列出的 Runtime 入站认证方式包括 IAM SigV4 和 JWT bearer token。前者适合 AWS 内部的服务间调用，调用方用 AWS 凭证签名；后者适合终端用户先在 Cognito、Okta、Microsoft Entra ID 等身份提供方登录，再把 token 交给 Runtime 校验。一个 Runtime 版本使用哪种方式，要以它的 authorizer 配置为准，不能拿 IAM 签名去调用只接受 JWT 的版本。
这里还有一层经常被忽略的授权。Runtime 和 endpoint 是两个资源，跨账号调用或使用资源策略时，相关资源都要允许相应操作。调用者自己拥有一条 IAM Allow，不代表资源一侧一定放行；任何显式 Deny 仍然优先。
runtimeSessionId 也不等于用户身份。它用来维持会话上下文，AgentCore 不会替业务系统保证“这个 session 只能属于这个用户”。后端仍要保存用户与 session 的映射，防止用户拿到别人的 session ID 后继续调用。
因此，入站 401/403 的排查顺序应该是：
- 调用的 endpoint 和版本是否正确；
- 该版本要求 SigV4 还是 JWT；
- token 的 issuer、audience、client、scope 等条件是否匹配；
- 调用者的 IAM 策略以及 Runtime/endpoint 的资源策略是否同时允许；
- 如果前面放了 Gateway，调用者是否还能绕过 Gateway 直达 Runtime。
如果调用方本身位于 VPC，还可以通过 AgentCore 的 VPC endpoint 和 AWS PrivateLink 发起私网调用。这个配置改变的是“请求经过哪里”，不会替代 SigV4 或 JWT。私网可达和身份获准，始终是两回事。
第二条链路：容器里的代码以谁的身份执行
请求通过入站校验后，代码开始在 Runtime 中运行。此时它访问 AWS 服务所使用的身份，不是最初的调用者，而是 Runtime 的 execution role。
这个角色有两面。
信任策略决定“谁可以扮演它”。AWS 当前给出的 Runtime trust policy 以 bedrock-agentcore.amazonaws.com 为服务主体，并建议用 aws:SourceAccount 和 aws:SourceArn 限制来源，降低 confused deputy 风险。
权限策略决定“扮演以后能做什么”。拉取容器、写 CloudWatch Logs、调用指定的 Bedrock 模型、读取某个 S3 bucket、解密某把 KMS key，都要在这里分别授权。开发工具自动生成的宽权限策略方便起步，但不适合作为生产配置长期保留。
这条边界尤其重要。假设一个前端用户只被允许向 Agent 提问，而 execution role 却能读取整个账号的 Secrets Manager，那么用户可能通过提示注入间接扩大能力。AWS 的安全文档还说明，Runtime 内的代码可以通过 MicroVM Metadata Service 取得 execution role 凭证。因此，容器里任何能执行的代码，都应被视为拥有这份角色权限。
比较稳妥的做法是按 Runtime 或用途拆角色：
- 只授权确实会调用的模型和资源；
- 尽量使用完整 ARN，少用
Resource: "*"； - 将读、写、管理权限分开；
- 用
SourceAccount、SourceArn和条件键约束信任关系； - 容器以非 root 用户运行，并减少不必要的工具和依赖；
- 第三方 OAuth token 或 API key 交给 AgentCore Identity 或专门的密钥系统管理，不写进镜像和日志。
看到容器日志里的 AWS AccessDenied 时，应优先检查 execution role、目标资源策略、KMS key policy 和 VPC endpoint policy，而不是继续修改调用者的权限。
第三条链路：Runtime 的网络包从哪里出去
身份允许一次 API 调用，并不保证网络包能够到达目标。
当 Runtime 配置为 VPC 模式时，AgentCore 会通过服务相关角色在指定子网创建 ENI，并给 ENI 分配私网 IP。安全组控制它能与哪些地址和端口通信。访问 VPC 内的数据库、缓存或内部 API 时，需要同时满足路由、DNS、安全组和目标端监听条件。
有一个很容易踩的坑：把 ENI 放进“公有子网”，不会让它自动获得公网访问能力。AWS 当前文档明确要求，VPC 模式下若要访问互联网，应把 Runtime 放在私有子网，让默认路由指向公有子网中的 NAT Gateway，再由 Internet Gateway 出网。
如果运行环境只访问 AWS 服务，可以尽量使用 VPC endpoint，减少流量绕行 NAT。当前 AgentCore 文档特别列出了 ECR DKR、ECR API、S3 Gateway 和 CloudWatch Logs 等 endpoint。具体需要哪些，取决于部署方式和代码访问的服务，不能照抄一张固定清单。
VPC endpoint 本身还有一层策略。即使路由、DNS 和安全组都正常，endpoint policy 也可能把请求挡住；反过来，endpoint policy 放行也不会覆盖目标资源的 IAM 策略。一次成功调用往往同时要求网络可达、角色有权、资源和 endpoint 都没有拒绝，缺一层就会失败。
网络链路通常按下面的顺序查：
- AgentCore 是否已经在目标子网创建 ENI；
- 子网所在可用区是否受当前区域支持；
- DNS 解析是否启用，解析结果是否符合预期；
- 路由表是通向目标 VPC、VPC endpoint、Transit Gateway，还是 NAT；
- Runtime 安全组出站和目标安全组入站是否成对开放；
- 目标端口是否真的在监听；
- VPC endpoint policy 是否允许 execution role 访问对应资源。
如果第三方 API 返回 401，这通常是出站认证问题；如果 TCP 超时或 DNS 失败，才更像网络问题。把二者混在一起，很容易出现“安全组越开越大，token 还是无效”的情况。
用故障表现反推链路
实际排障时，可以先看错误发生在哪里。
客户端还没看到 Runtime 日志就收到 401/403，先查入站鉴权。容器已经启动，调用 AWS API 报 AccessDenied，查 execution role 与资源策略。请求卡在连接、DNS 或 TLS 握手，查出站网络。第三方服务明确返回 token 无效，则查 AgentCore Identity、OAuth 授权或 API key。
这套分法也适用于架构评审。评审一套 AgentCore 部署时，不要只问“IAM 配了吗”，而要分别回答：
- 哪些人或服务能调用哪个 endpoint；
- Runtime 中的代码最多能访问哪些 AWS 资源；
- 网络层能到哪些私网地址、AWS 服务和公网目的地；
- 用户身份如何传到下游，服务身份又如何与用户委托分开；
- 日志、指标和 VPC Flow Logs 能否还原三条链路。
Agent 的行为不完全可预测，安全边界就更不该依赖“代码正常情况下不会这么做”。入站、身份和网络各自收紧，出了问题也能迅速判断故障落在哪一层。