[samerismail]

You're right that's the confused deputy problem, and it's a valid attack vector. If Agent A presents its JWT to Skill B, Skill B could reuse that token to call Skill C pretending to be Agent A.

This is a known limitation of bearer tokens in general (OAuth2 has the same issue), and there are well-established mitigations:

1.Audience-scoped tokens the JWT includes an aud claim binding it to a specific skill/service. Skill B gets a token that only works for Skill B. Skill C rejects it because the audience doesn't match. This is on our near-term roadmap.

2.Proof-of-possession (DPoP)instead of a bearer token, the agent signs each request with its private key, proving it's the original holder. The token alone isn't enough you also need the private key. This eliminates relay entirely.

3. Short TTL + per-request token instead of one 60-minute token for everything, the agent mints a fresh short-lived token per skill call.

You're identifying real gaps, and I appreciate the specificity. The current version is a v0.1 audience scoping and DPoP are the natural next steps. The point isn't that bearer tokens are perfect it's that going from "no identity at all" to "cryptographic identity with known, solvable limitations" is still a meaningful jump.

Would genuinely welcome a PR or issue if you want to help shape the DPoP implementation.

[spiffe]

Thanks, but I'm likely going to tune out.

None of the 3 points address the fundamental issue. IMO, it appears you are trying to reinvent a tiny part of OAuth2 w/ DCR, but without any of the security or trust underpinnings. I'd encourage you to consider simply using OAuth2 w/ DCR for your agent app instead.