一个agent派生出子agent去干活，最省事的做法是把自己手里的API key原样塞给对方。子agent因此拿到了和父agent一模一样的权限：能部署生产环境，能读支付数据库，能把代码merge进主干。这不是假设，是多agent系统里一个被反复提起却很少被真正修补的漏洞。
开源项目 Pigeon（GitHub：pigeonlabsHQ/pigeon）给出的方案很直接：父agent不再复制钥匙，而是签发一张Pigeon Pass——一个能力被收窄的签名凭证，写明子agent能做什么、不能做什么。执行工具动作前调用verify()校验，拒绝时返回结构化的原因（比如“资源不在授权范围”“能力未被授予”），而不是一个含糊的布尔值。
Pass怎么收窄，代码层面说得很清楚
Pigeon的核心是三个函数：grant签发权限，delegate把权限传给子agent，verify在动作发生前做校验。关键约束在delegate这一步：子agent不能扩大能力范围、不能放宽资源边界、不能松动约束条件。如果Pigeon判断不出子agent确实比父agent更窄，它会直接拒绝委托，抛出“权限提升”错误。
这套逻辑还延伸到了MCP场景：client给每一次工具调用铸造一张更窄的Pass，server执行前校验。项目文档把这一点说得很坦诚——这是一个执行点，不是协议标准，Pigeon本身不是策略引擎、不是身份提供商、不托管密钥，也挡不住prompt injection。它只在你写进Pass的那几个维度上限制爆炸半径。
这份自我划界值得认真读一遍。很多安全工具喜欢把自己包装成“一站式方案”，Pigoen反而先把自己能做什么、不能做什么摆在最显眼的位置。
它站在哪一格：Macaroons式极简，不是OAuth式标准化
Pigeon不是第一个想解决“委托授权”问题的方案，这个坐标系里早就有几套成熟做法，而且各自解决不同的子问题。
OAuth的Token Exchange（RFC 8693）区分“delegation”和“impersonation”，让审计日志既能看到用户身份，也能看到具体是哪个子agent在操作。DPoP（RFC 9449）解决的是另一件事：让token和私钥绑定，就算凭证被人截获，攻击者也没法直接拿去重放。Macaroons——Google研究提出的可离线验证凭证格式——专门处理“attenuation”，也就是权限链式收窄，思路和Pigeon的Pass几乎一模一样。SPIFFE则回答另一个完全不同的问题：这个workload到底是谁，而不是它能做什么。
Pigeon本质上落在Macaroons这一格：无服务器依赖、纯本地签名验证、专注于权限只收不放。这决定了它天然带着Macaroons式方案的老问题——撤销很难做。没有中心server盯着，一张Pass一旦签发出去，除非设置很短的有效期，否则没有办法在中途把它作废。
能收窄不代表能收回，这是签名能力凭证这条路线自带的短板
MCP协议自己也在管这件事。最新的授权规范要求MCP server公布授权服务器元数据，client必须用resource indicator把token绑定到目标server，且明确禁止把收到的token直接透传给下游服务。Pigeon的MCP middleware是在这套官方规范之外另起的一层本地校验，两者是互补还是会打架，项目文档没有交代，也是接下来最值得盯的一点。
谁该关心：正在搭多agent系统的团队
对正在搭多agent系统的团队来说，Pigeon的吸引力很实在：不用起服务、不用引入策略引擎，几行代码就能塞进现有的spawn和tool调用点，把“子agent权限失控”这个具体痛点先按住。这比一上来就上OAuth Token Exchange加DPoP加SPIFFE加Cedar的重型栈，门槛低得多。
但它没做的事同样具体：Pass是bearer式凭证，没有proof-of-possession绑定，子agent进程一旦被攻破，Pass被拿走就能直接冒用；没有workload身份概念，分不清“谁”在用这张Pass；委托链设计得不对，理论上仍可能出现权限意外放大——这几点Pigeon的README里完全没提。
- 建议.把Pigeon当成委托收窄这一层的可选组件去用，而不是当成子agent安全的全部答案。
- 风险.一旦子agent运行环境被攻破，Pass本身没有任何防盗用的绑定机制。
已经在用OAuth保护API的团队,如果想接入Pigeon,还得先想清楚这套本地签名凭证怎么跟现有的资源服务器打通——这件事目前没有现成答案。