[samerismail]

Fair critique, let me address both points directly.

JWT theft / 60-minute window: This is a real concern, and it's the same tradeoff every token-based system makes (OAuth2, Auth0, Firebase — all use similar TTLs). The mitigations are standard: TLS in transit, short-lived tokens (TTL is configurable, 60m is the default not the floor), instant server-side revocation via Redis blocklist, and single-use nonces to prevent replay. Token binding to client fingerprint/IP is on the roadmap.

Could someone steal a JWT in transit? Over TLS, that requires compromising the endpoint itself at which point you have bigger problems than token theft. The same attack vector applies to every bearer token system in production today.

The bottom turtle: You're right that cryptographic identity alone doesn't solve root trust who vouches for the agent at registration? This is exactly why we shipped human verification. Agents can link verified human identities (GitHub OAuth, Google, Worldcoin proof-of-personhood) to their passport. That's the bottom turtle: a real, verified human is accountable for what their agent does.

Is it perfect? No. But the current state is literally nothing no identity, no verification, no audit trail, no revocation. Going from zero to a cryptographic identity layer with risk scoring + human accountability is the same "0 to 1" jump that cookies and OAuth were for the web. The alternative isn't a better system it's no system at all.

Appreciate the pushback, this is exactly the kind of scrutiny that makes the design better. If you have specific attack vectors in mind beyond JWT theft, genuinely interested to hear them.

[spiffe]

One does not need to break any endpoint or look for things in transit. Any app that calls an agent within your design receives the jwt, and can turn around and masquerade as the agent.

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