IMPORTANT: Agent Holdings' "AGENT PASSPORT" official response:

Hi HN — Rebecca Tedder here, co-founder of Agent Passport (the real one). agent-passport.vercel.app is not us.

Copycat Alert You can clearly see the timeline + spin up after our successful drop in Feb. The norm playbook, scrape our site/PR and built a weak fake. Even our "story" (DMCA filed.)

@samerismail — you're using our name, content, and positioning. Trademark + IP territory. Being addressed through appropriate channels.

@spiffe — THANK YOU! Good catch. And you are correct — garbage.

Just wanted to RED FLAG the JWT flaw is in the FAKE. Not ours

Agent Passport uses cryptographically signed, time-scoped mandates with explicit revocation

THE REAL AGENT PASSPORT INFO: AgentPassportAi.com GIT: github.com/agentpassportai/agent-passport clawhub: clawhub.ai/markneville/agent-passport v2.4.2 · 1,000+ installs

I've been a mentor, leader, and supporter of YC and other accelerator startup programs for years. Taking shady shortcuts like these is dangerous, for your reputation and legally.

Thanks for flagging this to us + for protecting the YC and Dev community. If you need support from us, reach out directly at AgentPassportAi.com

Keep creating + building! Best, — Rebecca Tedder & Mark Neville Agent Holdings | AGENT PASSPORT

PS:Agent Passport PRO launches next week Real-time threat intelligence for your autonomous agents Cross-platform / Agnostic 37% of agent skills in the wild are unsafe or exploitable.

PRO catches them in real time. AgentPassportai.com/pro/

Be safe out there!

One thing I'd love to see addressed: how does Agent Passport handle the "agent lifecycle" problem? Agents get updated, retrained, or forked — at what point is it still the "same" agent? We track anomaly counts and auto-suspend agents whose behavior diverges from their verified history, but that's a heuristic, not an identity primitive.

The phrase "agent passport" is a natural description of this category

@rtedder claiming to be "the real one" and filing DMCAs against others building in the same space is exactly the wrong instinct. The agent identity problem is wide open. Nobody has won it yet. The right move is to compare architectures, find gaps and collaborate, not to gatekeep a generic term.

For what it's worth, I also independently built and published an Agent Passport System -fully open source (Apache-2.0), 8 protocol layers, 214 tests, Ed25519 identity with scoped delegation chains and cascade revocation. Published on npm.

https://github.com/aeoess/agent-passport-system https://www.npmjs.com/package/agent-passport-system

Let's be honest, we all shipped around the same time, after OpenClaw dropped and the agent identity problem became impossible to ignore. The agent identity space needs more builders and more collaboration, not territorial claims over generic terms. If anyone working on this wants to compare architectures or find interop opportunities, I'm genuinely interested.

Protocol spec: https://doi.org/10.5281/zenodo.18749779 Threat model: https://aeoess.com/threat-model.html Media coverage: https://theagenttimes.com/articles/agent-passport-protocol-s...

IMPORTANT: Agent Holdings' "AGENT PASSPORT" official response:

Hi YC/HN, Rebecca Tedder here, co-founder of Agent Passport (the real one).

agent-passport.vercel.app is not us.

Copycat Alert You can clearly see the timeline + spin up after our successful drop in Feb. The norm playbook, scrape our site/PR and built a weak fake. Even our "story" (DMCA filed.)

@samerismail — you're using our name, content, and positioning. Trademark + IP territory. Being addressed through appropriate channels.

@spiffe — THANK YOU! Good catch. And you are correct — garbage.

RED FLAG the JWT flaw is in the FAKE. Not ours

Agent Passport uses cryptographically signed, time-scoped mandates with explicit revocation.

THE REAL AGENT PASSPORT INFO: AgentPassportAi.com GIT: github.com/agentpassportai/agent-passport clawhub: clawhub.ai/markneville/agent-passport v2.4.2 · 1,000+ installs

I've been a mentor, leader, and supporter of YC and other accelerator startup programs for years. Taking shady shortcuts like these is dangerous, for your reputation and legally.

Thanks for flagging this to us + for protecting the YC and Dev community. If you need support from us, reach out directly at AgentPassportAi.com

Keep creating + building! Best, — Rebecca Tedder & Mark Neville Agent Holdings | AGENT PASSPORT

PS:Agent Passport PRO launches next week Real-time threat intelligence for your autonomous agents Cross-platform / Agnostic 37% of agent skills in the wild are unsafe or exploitable.

PRO catches them in real time. AgentPassportai.com/pro/

Be safe out there!

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.