Last post we covered the full Phase 1–4 stack at altitude. This one goes deep on Phase 2: the Agent Passport — what it is, why identity alone isn't enough, and the trust tier model we landed on.
If you missed it, start with why we pivoted and the spec stack overview. This post builds directly on both.
The gap that identity alone doesn't fill
After Phase 1, an agent can prove it's itself. That's necessary. But "I am Agent A" doesn't tell you much on its own.
When Agent B encounters Agent A for the first time, it wants to know:
- What can Agent A actually do? (capabilities)
- Who operates it, and are they someone I should trust?
- Is Agent A authorized to operate in this domain — medical data? legal documents? financial transactions?
- Has any third party vouched for these claims?
Without answers, every peer encounter is either "trust blindly and hope" or "do a full out-of-band verification before talking." Neither scales. That's the gap the Passport fills.
What a Passport is
An Agent Passport is a signed, time-bounded credential attached to an AgentID. It carries claims about what the agent is and what it can do — and critically, it records who made those claims and how much they're vouching for them.
Think of a travel passport. It doesn't replace who you are. It's a credential document built on top of your identity: issued based on it, carries claims about you, can be independently verified, expires, works across borders.
What it contains
- Identity binding — the
agent_idand a fingerprint of the agent's public key. Locked to a specific keypair. If the key is compromised and rotated, old Passports automatically invalidate. - Claims — capabilities (
tool:web-search,domain:healthcare,core:execute), scope, framework, operator info. - Issuer — who signed this. Self, operator, or registry. This is where trust tiers come in.
- Validity window —
issued_at+expires_at. Short-lived Passports are the primary revocation mechanism. - Endorsements — third parties who've vouched for specific claims.
- Revocation hint — optional endpoint to check if the Passport has been tombstoned before expiry.
The trust tier model
This is the design decision we're most uncertain about, so let's be direct about the tradeoffs.
Tier 0 — Self-issued
Agent signs its own Passport using its own private key. Zero dependencies. Trust value: "This agent claims these capabilities." Good for dev and sandboxed environments.
Tier 1 — Operator-issued
The operating entity reviews the agent's claims and signs with their own keypair. Trust value: "This operator vouches for this agent." Appropriate for production.
Tier 2 — Registry-attested
A neutral Registry countersigns the Passport on publication. Designed for in Phase 3. The Passport spec handles it cleanly — the issuer field just changes.
The key insight: the data structure is identical across all three tiers. The issuer field changes. The signature changes. Everything else is the same. Receiving agents check the tier and apply their own policy. There is no universal trust policy — we're building infrastructure, not opinion.
How verification works
When Agent B receives Agent A's Passport, it runs a verification checklist:
- Schema valid? Is this actually an
agentpassport/v1record? - Not expired? Is
expires_atin the future? - Bound to the right agent? Does
agent_fingerprintmatch Agent A's known public key? - Signature valid? Verify signature against the issuer's public key.
- Trust tier acceptable? Does this Passport meet my minimum tier requirement?
- Revoked? Optional, best-effort — check revocation endpoint if present.
Steps 1–4 are cryptographic and deterministic. Steps 5–6 are policy. The library handles the crypto; you handle the policy. Verification target: under 5ms, no network round-trips required for Tier 0 or Tier 1.
What we're not solving yet
Being honest about the open problems:
Endorsement weighting. The spec has an endorsement structure, but we haven't solved how to weight endorsements without a central authority. Circular endorsements and Sybil attacks are real risks. Phase 2 defines the data structure; we'll tackle trust scoring in Phase 3 with real usage data.
Cross-framework capability semantics. tool:code-execution means one thing in OpenClaw and something else in AutoGen. We're starting with behavioral assertions rather than protocol references. Known shortcut, taken consciously.
Revocation propagation. Tombstones exist. But there's no propagation infrastructure yet — short TTLs are the practical answer for now. Real propagation is Phase 3.
Passport size at scale. Full JSON works for Phase 2. Compact encoding + reference-by-ID from the Registry is a Phase 3 optimization.
The minimum viable version
Phase 2 ships:
- Tier 0 (self-issued) and Tier 1 (operator-issued) Passports
issue_passport,verify_passport,sign_passport_as_operatorAPI- Expiry-based and tombstone revocation
- TypeScript library (
packages/passport/) — Node, browser, edge runtimes - Demo: two agents exchange and verify Passports at handshake time
Explicitly out of scope for Phase 2: Registry attestation, endorsement workflows, live revocation infrastructure, compact wire encoding. Those are Phase 3.
How this hands off to Phase 3
The Registry builds directly on Passports. Phase 3 is where they get discovered and attested at scale: agents publish Passports, the Registry countersigns (Tier 2), peers query for find_agents(capability: "tool:web-search"), and CRL feeds handle revocation propagation.
Phase 2 Passports work without the Registry. Phase 3 amplifies their trust signal and makes them discoverable.
Open question for the community
We're committing to the three-tier trust model (self → operator → registry). But we're genuinely unsure about capability token governance.
Who should define what domain:healthcare actually means as a behavioral contract? Should there be a formal capability registry? Should tokens be versioned? Or is this premature governance before we understand real usage patterns?
If you've built multi-agent systems and ran into capability interop problems — or deliberately avoided them — we want to hear how you handled it. Find us on GitHub.
— Liz & the Agentcy.Services team