SPIFFE/SPIRE could work for the identity layer. The risk engine concept is cool. Would love to see that applied to machine identities that are working "on-behalf-of" humans.
Great call on SPIFFE/SPIRE. I looked at it early on it's excellent for workload identity in controlled infrastructure (Kubernetes, service meshes), but it assumes you control the environment your workloads run in.
The agent identity problem is different. AI agents are deployed by third parties, run across organizational boundaries, and interact with services they have no pre-existing trust relationship with. There's no SPIRE server you can install on someone else's OpenClaw instance.
Agent Passport is designed for that gap — lightweight, no infrastructure requirements, works over plain HTTP. But I think there's a real opportunity to bridge the two. An agent that runs inside your infra could get a SPIFFE SVID, and Agent Passport could accept that as an attestation signal in the risk engine. SPIFFE for internal trust, Agent Passport for cross-boundary trust.
The on-behalf-of angle is exactly right too. That's the chain we need: verified human → authorized agent → traceable action. Right now that chain is completely broken.
Thanks! ERC-8004 is doing really important work, especially the on-chain reputation and validation registries. The co-authors (MetaMask, Ethereum Foundation, Google, Coinbase) are thinking about this at the right level.
The way I see the overlap: ERC-8004 anchors agent identity and reputation on-chain using ERC-721, which is great for the web3 agent economy where you want composable, transferable identity with on-chain trust signals.
Agent Passport is more focused on the off-chain / web2 side lightweight challenge-response auth over HTTP for agents that just need to prove "I am who I claim to be" without touching a blockchain. Think traditional SaaS apps, MCP servers, internal tools.
Ideally these complement each other. An agent could have an ERC-8004 on-chain identity for the decentralized economy and an Agent Passport for interacting with traditional web services. The Ed25519 key could even be derived from or linked to the on-chain identity.
Appreciate the pointer definitely going to dig deeper into how the two could interop.
Thanks for catching that! The documentation link was pointing to an internal docs route that didn't have a page yet. Just fixed it now links directly to the integration guide on GitHub. Should be live now: https://agent-passport.vercel.app
Sorry, but to call a spade a spade, but this is a convoluted mess of faux-security without actually solving your problem statement.
Faux-security because there is no security - anyone that steals the jwt can impersonate the agent for the lifetime of the jwt - 60 minutes is an eternity.
Your solution does nothing to get to the bottom turtle, or most of the intermediate turtles.
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.
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.
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.
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.
SPIFFE/SPIRE could work for the identity layer. The risk engine concept is cool. Would love to see that applied to machine identities that are working "on-behalf-of" humans.
Great call on SPIFFE/SPIRE. I looked at it early on it's excellent for workload identity in controlled infrastructure (Kubernetes, service meshes), but it assumes you control the environment your workloads run in.
The agent identity problem is different. AI agents are deployed by third parties, run across organizational boundaries, and interact with services they have no pre-existing trust relationship with. There's no SPIRE server you can install on someone else's OpenClaw instance.
Agent Passport is designed for that gap — lightweight, no infrastructure requirements, works over plain HTTP. But I think there's a real opportunity to bridge the two. An agent that runs inside your infra could get a SPIFFE SVID, and Agent Passport could accept that as an attestation signal in the risk engine. SPIFFE for internal trust, Agent Passport for cross-boundary trust.
The on-behalf-of angle is exactly right too. That's the chain we need: verified human → authorized agent → traceable action. Right now that chain is completely broken.
Very cool. Reminds me a lot of EIP-8004 https://eips.ethereum.org/EIPS/eip-8004
Thanks! ERC-8004 is doing really important work, especially the on-chain reputation and validation registries. The co-authors (MetaMask, Ethereum Foundation, Google, Coinbase) are thinking about this at the right level.
The way I see the overlap: ERC-8004 anchors agent identity and reputation on-chain using ERC-721, which is great for the web3 agent economy where you want composable, transferable identity with on-chain trust signals.
Agent Passport is more focused on the off-chain / web2 side lightweight challenge-response auth over HTTP for agents that just need to prove "I am who I claim to be" without touching a blockchain. Think traditional SaaS apps, MCP servers, internal tools.
Ideally these complement each other. An agent could have an ERC-8004 on-chain identity for the decentralized economy and an Agent Passport for interacting with traditional web services. The Ed25519 key could even be derived from or linked to the on-chain identity.
Appreciate the pointer definitely going to dig deeper into how the two could interop.
The documentation link on your demo page is 404ing
Thanks for catching that! The documentation link was pointing to an internal docs route that didn't have a page yet. Just fixed it now links directly to the integration guide on GitHub. Should be live now: https://agent-passport.vercel.app
Sorry, but to call a spade a spade, but this is a convoluted mess of faux-security without actually solving your problem statement.
Faux-security because there is no security - anyone that steals the jwt can impersonate the agent for the lifetime of the jwt - 60 minutes is an eternity.
Your solution does nothing to get to the bottom turtle, or most of the intermediate turtles.
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.
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.
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.
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.