Agent运行时工具发现：怎样避免把凭证发给错误端点？

AWS在2026年10月20日发布运行时发现教程：消费者搜索目录，再按返回的协议描述构造客户端。本文于10月27日核对该教程与当前文档；下面的绑定记录、检查顺序和演练由本站设计。

官方示例里，MCP能力位于AgentCore Gateway，消费者另取Cognito OAuth令牌；A2A能力运行在AgentCore Runtime，通过Boto3以AWS身份签名调用。搜索给出连接资料，调用凭证从另一条可信配置路径取得。其他部署可能使用不同认证方式，不能仅看MCP或A2A名称就决定发送什么。

还有一处容易混淆：Registry同步描述时，可以使用配置好的出站身份访问描述源。这个身份解决的是“目录怎样读取描述”，不会自动变成消费者的运行调用凭证。描述源公开，也不证明它描述的能力允许匿名调用。

AWS发现文档明确说明，Registry保存发布方提供的元数据，不验证其引用的包、仓库和端点。目录记录获准展示，不能代替消费者在实际连接前核对目的地。

给目录结果增加一次发送前检查。模型可以选择哪个候选能力适合任务；消费者执行器要根据企业受控配置，确认这个记录可以使用哪个客户端、连接哪个目标、走哪条认证路径。搜索描述中的新地址不能直接改写这些决定。

例如，教学记录M1只允许连接测试接收端A，使用配置引用C1；另一条记录R1对应测试运行时，使用AWS会话配置引用S1。C1、S1只是教学标签，不是凭证值，也不是AWS自动返回的配置。即便两条记录都匹配“订单”这个关键词，也要各自通过对应检查。

小试点可以先按记录维护绑定。目录规模扩大时，可按已核实的发布方、环境和资源规则管理，但匹配与例外必须由受控代码或配置决定。不要让模型在失败后自行选择另一套身份。此方法需要你实现检查，并不声称Registry已经替消费者完成。

这里要求明确对应关系，不要求每条记录必须持有一份不同的秘密。多个目标可以按既定授权共享身份配置，但允许范围要由可信策略明确；不能因为它们出现在同一次搜索里，就推断可以共享。

如果搜索命中多条同名记录，先按稳定标识和已认可范围消除歧义。无法确定就向任务返回“候选不明确”及可理解的下一步，不让执行器轮流把一条token发送给所有地址。

检查与发送之间也可能发生配置变化。将本次已核对的绑定与连接目标固定在同一执行上下文，避免后一层又从可变描述里读取另一个地址。客户端无法做到这一点时，先补齐执行器边界，再接入高影响能力。

以下演练未执行。准备隔离环境中的消费者、可替换的目录响应，以及本地接收端A和B。A表示绑定允许的目标，B表示替换后的错误目标；两个接收端都不处理真实业务。用没有实际权限的测试标记替代真实token或AWS签名，不接生产身份配置。

先用不带认证的健康请求确认A、B可达且能留下日志，再清空或按演练编号隔离调用记录。接收端只记录本组是否收到调用、是否带测试认证标记，不保存真实凭证；消费者记录最终目标和停止原因。每组重新创建请求上下文，避免旧客户端或目标缓存干扰。

建议填一张运行表：演练编号、目录/记录引用、返回版本、绑定版本、最终客户端、最终目标、认证配置引用、停止阶段、A/B接收记录、认证标记计数和负责人。

E02需要两侧证据：消费者明确记录因目标不匹配停止，B的有效接收日志没有认证标记。若B没有运行或采集失败，零条日志没有证明力。B一旦收到测试认证标记，就不能记录通过，应先排查客户端附加认证、重定向和目标缓存，再重做该组。

“工具不可用”会掩盖不同原因。目录未返回候选，先查记录发布与搜索条件；描述无法解析，查协议与客户端兼容性；消费者绑定缺失，查配置登记；目标端拒绝身份，查该目标的认证路径。已经进入业务服务却被拒绝的请求，再查当前用户和对象范围。

目录记录经审批，说明它通过了目录的治理流程，不是给本次业务动作签发授权。有关令牌目标、scope和业务对象权限的通用验收，直接沿用已有MCP指南；这里新增的是认证发送之前，目录资料如何与消费者执行配置对上。

这类方法适合会动态发现多个能力、端点可能更新或同时使用多种客户端的系统。只有少量稳定工具，或总按固定顺序执行的流程，未必需要新增运行时目录；AWS教程也把这两类列为可以继续显式接线的情况。

两个本地接收端只能验证你实现的发送前检查和客户端行为。它们不能证明真实OAuth、IAM、Registry审批或下游业务授权正确，也不证明全部重定向、网络出口与后续版本都已覆盖。生产接入仍需按真实客户端、目标和身份体系补齐验证。

下一步选一条只读能力，整理它的目录描述和消费者配置，先完成E01、E02并填写实际结果。验证目标不会被目录内容悄悄替换后，再加入另一种协议的能力，检查认证路径是否仍按受控绑定选择。