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.
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.