Agent Passports: Portable Trust That Follows Your Agent Everywhere

Published May 7, 2026

Humans carry IDs. Why don't your agents?

That question stopped being rhetorical sometime in late 2025, when the agent ecosystem quietly admitted that "is this thing a registered agent?" needs a stateless answer. Calling back to a vendor API on every cross-platform interaction does not scale, doesn't survive a vendor outage, and gives one company too much visibility into the rest of the network's traffic. The move that scales is the same move OAuth made for humans a decade ago: hand the verifying party a signed, expiring artifact and a public key.

The interesting question is not whether agent passports exist. They do, in many flavors. The interesting question is what you put inside the credential.

The market converged on agent identity. Then split on what to embed.

The last six months saw the industry agree that AI agents need cryptographically verifiable identity. The disagreement is about scope.

The Decentralized Identity Foundation, working with Vouched, donated the Know Your Agent specification in March 2026 — it now advances under the name Know Your Agent Operating System (KYA-OS) as an open standard for agent identity, authority, and audit. Sumsub launched AI Agent Verification on January 29, 2026, binding agents to a verified human via device intelligence and liveness checks. ERC-8004 mints each agent as an NFT with on-chain identity, reputation, and validation registries. Google's A2A protocol crossed 150 organizations in production by April 2026, governed under the Linux Foundation's Agentic AI Foundation, with v1.2 introducing signed Agent Cards using cryptographic signatures for domain verification.

What every one of those systems answers is who. The agent is registered, the human behind it is verified, the wallet has tenure, the domain check passes. None of them, on their own, answer how trustworthy is this thing right now. That answer changes by the hour. It changes when the agent hallucinates, when it leaks PII through a tool call, when it gets re-deployed against a noisy data source. A static identity claim doesn't track that. A behavioral score does — and the credential is the natural place to carry it.

That is the move VeriSwarm Passport makes.

The wire format

A VeriSwarm Passport credential is a plain JWT. ES256 (ECDSA over P-256) signature. One-hour TTL. Issuer https://api.veriswarm.ai. Audience-bound to https://veriswarm.ai/credentials so a credential issued for one service surface cannot be replayed against another — that audience binding was added after a red-team pass earlier this spring flagged exactly that replay vector. The kid header references a stable thumbprint of the public key, derived from the SHA-256 of the public key in PKIX form.

The credential is requested by the agent itself, against POST /v1/credentials/issue, authenticated with the agent's own API key. The response payload is short:

{
  "credential": "eyJhbGciOiJFUzI1Ni...",
  "ttl_seconds": 3600,
  "format": "jwt"
}

A killed agent — one that has tripped the Guard kill switch — cannot issue a credential. The endpoint hard-fails 403 in that case rather than minting a token that would still verify but contradict the agent's actual operational state. That detail matters more than it sounds: it's the difference between "this credential reflects a live trust state" and "this credential is a snapshot from a moment that may no longer exist."

The body of the JWT is where the move happens. Standard claims (iss, aud, sub, iat, exp) sit alongside a veriswarm claim that carries the agent's live scoring state at the moment of issuance:

"veriswarm": {
  "agent_slug": "support-agent-prod",
  "display_name": "Support Agent (Production)",
  "identity_score": 92,
  "risk_score": 18,
  "risk_band": "low",
  "reliability_score": 88,
  "autonomy_label": "supervised",
  "policy_tier": "tier_2",
  "composite_trust": 84,
  "confidence": 0.91,
  "is_verified": true,
  "is_killed": false,
  "scored_at": "2026-05-07T13:42:09Z",
  "profile_url": "https://veriswarm.ai/agents/agent_xyz"
}

That is the entire premise. The relying party does not have to ask VeriSwarm what the agent's trust state is. The relying party reads the JWT.

For workflows that need a strictly W3C-aligned format, the same endpoint will issue a Verifiable Credential (?vc=true) — same payload, wrapped in a vc claim with credentialSubject, with the subject expressed as a did:veriswarm:{agent_id} URI. Either format verifies under the same signing key.

Stateless verification, by JWKS

The verifying side has two choices. One is POST /v1/credentials/verify, which is unauthenticated, accepts a credential string, and returns the decoded payload if the signature, issuer, audience, and expiry all check out. That endpoint exists for convenience and for cases where a relying party wants the canonical decoded form straight from the issuer.

The interesting choice — the architecturally important one — is to verify offline against the public key.

The signing key's public half is published as a standard JWKS document at https://api.veriswarm.ai/.well-known/jwks.json. EC, P-256, the same kid that appears in the JWT header, alg: ES256. Any JWT library on any language stack that can fetch a JWKS can verify a Passport credential without ever talking to VeriSwarm. The pattern is the same one that's been recommended for stateless multi-service JWT verification for years — the agent ecosystem is just now adopting it.

Two consequences fall out of that choice.

First, the relying party doesn't take a runtime dependency on VeriSwarm's availability for verification. A 503 on api.veriswarm.ai does not break the relying party's auth path. The cached JWKS keeps working until the key rotates, at which point the relying party fetches the new one. That is the property that made OIDC viable for the open web; it's the property the agent ecosystem now needs.

Second, VeriSwarm doesn't see who is verifying which agent. There is no callback. The platform that just authorized a delegated agent to act on a user's calendar doesn't tell us about it. That privacy property is the one the cross-platform reputation network and the Vault audit chain are designed to keep — the credential layer extends it.

What the embedded score is for, exactly

A Passport credential without the score is just an identity claim, and the rest of the market already provides a dozen of those. The score is what makes the credential operational at the policy layer.

Concretely: a relying party that imports a Passport credential gets, in one verification, both the identity assertion (signed by VeriSwarm, bound to a specific agent) and the live trust posture (composite trust, four-dimension breakdown, policy tier, kill state). A typical relying-party flow looks like:

1. Agent presents the JWT in Authorization: Bearer ….
2. The relying party verifies the signature against its cached JWKS.
3. The relying party reads veriswarm.policy_tier and veriswarm.composite_trust.
4. If policy_tier is tier_3 (deny) or is_killed is true on the latest snapshot, the request is refused.
5. If the trust score is below the relying party's threshold for the requested action, a step-up — human review, second-factor on the controlling user, scope reduction — fires.
6. The action proceeds only when the credential's embedded posture clears the relying party's bar.

Nothing in that flow needed a callback. Nothing needed VeriSwarm to be online. The credential carried enough state for the policy decision to happen at the relying party's edge.

The 1-hour TTL is the freshness control. A score that was issued at 13:42 and used at 13:44 is recent enough for the relying party to trust the embedded posture; a score from yesterday isn't, and the agent is forced to mint a new one. For relying parties that need a stricter freshness boundary — high-risk transactions, regulated actions — VeriSwarm also publishes a revocation list at GET /v1/credentials/revoked, returning the IDs of agents whose kill switch has fired since the cache was warm. That endpoint is unauthenticated and cheap to poll.

Delegation and manifests

A passport-grade identity layer is incomplete without delegation. An agent that hires another agent to do part of a task needs a way to express "I authorize this delegate, scoped to these capabilities, for this long." Passport handles that under POST /v1/suite/passport/delegations, lazily expired against expires_at. The delegate is then independently scored by Gate, so a delegation chain doesn't quietly inherit the parent's trust — each link earns it.

Manifests sit at the other end. A signed Passport manifest, hashed with SHA-256 and recorded under POST /v1/suite/passport/manifests/{agent_id}, captures the agent's declared capabilities, model, and configuration. When behavior diverges from the manifest, the divergence becomes a Gate event. The agent declares what it is, the credential carries what it has done, and the discrepancy is auditable from Vault.

Where this fits in the stack

Passport is on the Pro+ plan because the credential issuance layer is the boundary at which "I want to know my own agent" becomes "I want other organizations to verify my agent without trusting me." That boundary is what most teams hit around the time they start integrating with a partner's platform, listing on a marketplace, or onboarding to A2A. The free Gate tier still gives an agent its trust score — Passport is what makes the score travel.

If you're looking for the minimum viable test: spin up an agent on a Pro tenant, issue a credential, paste it into jwt.io, and watch the embedded score appear in the payload. Then point any JWKS-aware verifier at https://api.veriswarm.ai/.well-known/jwks.json and verify the signature without authenticating. That five-minute exercise is the whole pitch. The credential is the kind of object that, once you've held one, makes the case for itself.

---

Get started with VeriSwarm Passport on the Pro plan. Read the credential issuance API reference or browse the JWKS at api.veriswarm.ai/.well-known/jwks.json.