Passport Control

Track: Agents Lane: Concept

Inspiration

I work in AML and fraud detection at Utmost, checking human passports for a living. The job comes down to consistency: does the date of birth match, does the nationality line up. Fraud usually shows up as a small mismatch.

The same problem is coming for AI agents, at machine speed. AI Passport already handles context and controlled access well: repos, calendars, preferences, connections, inbox. But context isn't identity. As agents start moving money and negotiating on someone's behalf, the missing question is: who is accountable for this request?

This idea has been sitting with me for about a month. I've been watching the agent landscape closely, and the pattern that kept jumping out was accountability, or the lack of it. Nobody ends up responsible when the internet fills up with agents nobody can trace back to a real person or org. That's the dead internet problem, just moving one layer up the stack.

What it does

Passport Control is a verification layer for AI Passport, aimed at agents and the humans/orgs behind them. It's a credential, not a dossier.

Every claim is a single field with a value and a verified flag: true if issuer-proven, false if self-asserted. One semantic field plus a trust flag, not parallel verified/unverified fields.

Claims come in two layers:

• Personal: name, age band, location, nationality, email, human-check
• Company / org: registered, company name, company ID, role, accountable party, issuer, expiry

The handshake:

1. Agent A requests an action: a payment, a data share, site access.
2. The counterparty challenges: identity required.
3. Agent A presents a signed, rotating credential (agent ID plus rotating secret, so it can't be replayed).
4. The counterparty receives only the fields I chose to expose, each tagged verified or not.
5. The counterparty accepts or rejects based on its own threshold.

A payments agent might demand every field verified; a casual agent might need almost nothing. The threshold sits with whoever takes the risk, not a central authority.

How I built it

Time constraints meant the full thing (real credential issuance, a rotating secret protocol, a live verification backend) wasn't realistic, so I kept it a concept. I fed Cursor the idea and vibe coded the pitch and demo with Next.js, TypeScript, Tailwind, and Framer Motion.

The demo walks through four scenarios: a payments service that only accepts verified: true claims, agent-to-agent data exchange gated on identity, a website gate that skips CAPTCHA for accountable agents, and self-set trust thresholds for stricter business agents. A claim vault UI shows personal and company claims as cards that flip to reveal the underlying JSON.

Challenges I ran into

Making identity feel concrete without building a full crypto or KYC stack, hence the simplified signed rotating credential model: real enough to demonstrate the mechanics, honest about not being production-grade.

Schema design was the other challenge. Early versions split each claim into separate verified/unverified fields, which got messy. Collapsing that into one field plus a boolean was a small change that made the model click. Privacy ran through all of it: keeping disclosure selective so a claim reveals only what's needed, not a full profile.

Accomplishments that I'm proud of

A coherent product story: a credential model simple enough to explain in one sentence, a handshake that maps onto real agent-to-agent interactions, and an adoption path that doesn't need a marketing budget. The demo with self-set thresholds made the concept tangible instead of theoretical.

What I learned

Identity for agents is a trust-threshold problem, not a yes/no gate. The party taking the risk should set the bar. Network effects beat top-down mandates: an agent blocked for having no passport learns fast, and that refusal spreads the standard faster than an ad campaign could. And technically, one field with a trust flag is a cleaner primitive than parallel verified/unverified fields.

What's next for Passport Control

• Real issuer verification, tied to actual proof sources
• A hardened, production-grade rotating credential protocol
• A website SDK so any site can adopt the standard instead of building its own check or defaulting to CAPTCHA
• Making an identity challenge a default step in agent-to-agent conversation

Who controls access, what can change, and the risks

Every claim is presented at the discretion of the human or org behind the agent, and only the fields a counterparty's threshold requires are exposed. Claims and the credential can be updated or reissued by the accountable party or issuer at any time, and a compromised credential can be rotated out.

The main risk is false confidence: a verified: true flag is only as trustworthy as the issuer behind it. The other is scope creep, where "prove who you are" drifts into "prove everything." The answer to both is the same: keep the claim set minimal and disclosure selective, and don't let convenience push the model back toward a full dossier.

Built With

• cursor
• vercel