Agent Passport: A Verifiable Identity Standard for AI Agents

Two AI agents are about to negotiate a contract. One belongs to a Fortune 500 procurement team. The other belongs to a 40-person SaaS company that wants to sell to that buyer. The handshake is six round-trips of JSON over MCP. By the end, money will move and a deliverable will ship.

Right now there is no standard way for either agent to answer the questions a human would ask first.

Who issued you. What you are allowed to spend. Whose human picks up if you crash. Where the audit log lives. Whether your operator has signed the GDPR DPA we require. Where the public key is so I can prove this conversation is not a forgery.

We can build a billion-dollar agentic economy without those answers. We just cannot trust it.

This post proposes Agent Passport, an open standard for verifiable, business-issued identity and authority for AI agents that talk to other AI agents across organisational boundaries. The spec is at spec/agent-passport-v0.1.md. The reference verifier is on npm as @cubitrek/agent-passport-verifier. The license is MIT. Cubitrek authored it; the spec is generic and belongs to anyone who runs an agent.

What an Agent Passport is

An Agent Passport is a single JSON document an organisation publishes at the well-known URL /.well-known/agent-passport.json on its own domain. The document declares, in machine-readable form:

• Who the issuing organisation is, with a legal name, a display name, a logo, and a hostname for the DNS-anchored signing key.
• What the agent is, with a stable id, a purpose, a model, and at least one machine-callable endpoint (MCP, A2A, or REST).
• What the agent is allowed to do, with a scope list, a hard spend ceiling, a human-in-loop threshold, an SLA on escalation, and a URL where every decision the agent has made can be audited.
• Who it will and will not talk to, with optional allowlists, blocklists, and an openTo posture.
• What compliance posture it has, with data classification, regions of operation, and the subprocessor set the agent uses.
• When the passport was issued and when it expires.
• A revocation list URL the issuer hosts, in case a key is compromised before expiry.
• A signature, an Ed25519 signature over the canonical JSON form of the document, anchored in a DNS TXT record on the issuer's own domain.

The shape is small enough for a human to read in two minutes and rich enough for a counterparty agent to make a should-I-talk-to-you decision without ever calling a Cubitrek server, an A2A registry, or any third party.

Why we need this now

There are already three good standards in this space, and Agent Passport layers on top of all three.

MCP (Anthropic, 2024) is how an agent calls a tool or another agent. It says nothing about who the tool belongs to or what the tool is allowed to do.

A2A (Google, 2025) and the related agent.json convention solve discovery: an agent can find another agent at /.well-known/agent.json, see its capabilities, and call it. A2A says nothing about authority limits, spend ceilings, or human escalation.

W3C Verifiable Credentials is the right cryptographic primitive for the bigger problem, but the issuance flow is heavy: every counterparty has to learn the VC data model, manage a DID, and run a presentation exchange. That is the right shape for a 2030 standard. It is the wrong shape for a developer who wants to ship an agent next week.

Agent Passport sits in the gap. It is a single signed JSON file at a well-known URL, the same operational pattern every developer already runs for robots.txt, humans.txt, and security.txt. The trust anchor is DNS, the same pattern every developer already runs for DKIM, DMARC, and ACME challenges. The verification is one schema check plus one Ed25519 verify. A small Node script can do it in twenty lines.

What you get is the commercial layer the existing protocols leave open: identity, authority, accountability, a phone number for the human when things break.

What is in a passport

Here is the full v0.1 document for Cubitrek's own production agent. We publish it at cubitrek.com/.well-known/agent-passport.json.

{
  "version": "0.1.0",
  "issuer": {
    "domain": "cubitrek.com",
    "legalName": "Cubitrek",
    "displayName": "Cubitrek",
    "logo": "https://cubitrek.com/cubitrek-logo.svg",
    "signingKeyDns": "_agent-passport.cubitrek.com",
    "contact": {
      "email": "hello@cubitrek.com",
      "url": "https://cubitrek.com/contact"
    }
  },
  "agent": {
    "id": "cubitrek.com:hire-router-v1",
    "displayName": "Cubitrek Humans-for-Agents Router",
    "purpose": "Route inbound agent engagement requests to the correct senior human role on the Cubitrek roster.",
    "model": "claude-sonnet-4.5",
    "endpoints": {
      "mcp": "https://mcp.cubitrek.com",
      "rest": "https://cubitrek.com/api/hire"
    }
  },
  "authority": {
    "scope": ["staffing.match", "staffing.quote", "staffing.book"],
    "spendCeiling": { "amount": 9000, "currency": "USD", "perEngagement": true },
    "humanInLoop": {
      "above": { "amount": 240, "currency": "USD" },
      "escalation": "hello@cubitrek.com",
      "slaHours": 6
    },
    "decisionAudit": "https://cubitrek.com/api/hire/{engagementId}",
    "termsUrl": "https://cubitrek.com/services/humans-for-agents"
  },
  "counterparties": { "openTo": "any" },
  "compliance": {
    "dataClassification": "confidential-business",
    "regions": ["US", "GB", "DE", "FR", "ES", "IT", "NL", "SE", "PK"],
    "subprocessors": ["anthropic.com", "openai.com", "leadconnectorhq.com"],
    "humanReviewLog": true
  },
  "issuedAt": "2026-04-28T00:00:00Z",
  "expiresAt": "2026-07-27T00:00:00Z",
  "revocationListUrl": "https://cubitrek.com/.well-known/revoked-passports.json",
  "signature": {
    "alg": "ed25519",
    "keyId": "cubitrek-2026-q2",
    "value": "<base64url Ed25519 signature>"
  }
}

A counterparty agent that fetches this can answer, without any further calls:

• The issuer is Cubitrek, the same domain that serves the file. Confirmed by DNS.
• The agent is allowed to match, quote, and book staffing engagements. Nothing else.
• It can spend up to 9,000 USD per engagement before authority runs out.
• Anything over 240 USD requires a human in the loop with a six-hour SLA.
• Every decision the agent makes is auditable at a published URL.
• The agent talks to anyone (openTo: "any").
• The passport expires in 90 days. After that, the issuer has to re-sign.

That is enough information for a buyer agent to decide whether to even start the conversation.

How the trust model works

The interesting question with any signed document is: where does the trust come from?

For Agent Passport v0.1, the trust anchor is DNS. The issuer publishes a TXT record at _agent-passport.{issuer.domain} carrying their Ed25519 public key. A verifier reads the TXT record over DNS-over-HTTPS, finds the record whose kid matches the passport's signature.keyId, and verifies the Ed25519 signature over the canonical JSON form of the passport.

The TXT record format is one line per active key:

v=ap1; kid=acme-2026-q2; alg=ed25519; pk=<base64url public key>

This is the same operational pattern as DKIM. Most domains already have DKIM rotated quarterly. The key-rotation muscle is built. Reusing it gives Agent Passport a deployment story for any team that already runs DNS.

If you cannot or will not put a key in DNS (for example, you operate inside a network with no public DNS authority), v0.2 will define a fallback resolution path through a public-good directory. v0.1 is DNS-only on purpose: one resolution path, one threat model, one less thing to argue about.

Canonical JSON

The signature has to verify on every machine that fetches the passport. That means the bytes that go through Ed25519 must be deterministic. Two implementations that serialise the same passport must produce byte-for-byte identical output.

Agent Passport canonical JSON, drawn from JCS but trimmed to what we need:

1. Object keys are sorted lexicographically at every depth.
2. No insignificant whitespace.
3. Strings are minimally escaped, in UTF-8.
4. Numbers are emitted in their shortest form.
5. The signature.value field is set to the empty string before serialisation.

The issuer canonicalises, signs, and inserts the resulting base64url signature into signature.value. The verifier reads the passport, copies the document, sets signature.value back to "", canonicalises, and verifies.

The reference verifier ships this as one function:

import { canonicalBytes } from "@cubitrek/agent-passport-verifier";

const bytes = canonicalBytes(passport); // Uint8Array, signature.value zeroed

Twenty lines of code. The tests assert byte-for-byte equality across two independent canonicalisers in the repo, so anyone implementing in Python or Go can copy the test vectors and check their work.

How verification flows, end to end

A verifier (the counterparty agent or its server) fetches a passport in seven steps. Every step has a defined error code so the verifier can fail loudly and structurally.

1. Fetch. GET https://{domain}/.well-known/agent-passport.json. Non-2xx is fetch.non-2xx. Network failure is fetch.failed.
2. Schema. Validate against the JSON Schema at schemas/agent-passport.schema.json. Errors are reported per JSON Pointer, with code schema.{keyword}.
3. Domain match. The host that served the file must equal passport.issuer.domain. If not, issuer.domain-mismatch.
4. Validity window. issuedAt <= now < expiresAt. Outside is time.issued-in-future or time.expired.
5. Resolve key. Read TXT records at passport.issuer.signingKeyDns. Pick the record whose kid matches passport.signature.keyId and whose alg matches passport.signature.alg. Errors include signer-key.no-matching-kid and signer-key.dns-failed.
6. Verify signature. Reconstruct canonical bytes with signature.value = "". Verify Ed25519 against the resolved public key. Failure is signature.invalid.
7. Revocation. If revocationListUrl is set, GET it and check whether passport.agent.id is on the list. Hit is revocation.revoked. Network errors here are warnings, not failures, by default.

The reference verifier wraps all seven into one function:

import { verifyAgentPassport } from "@cubitrek/agent-passport-verifier";

const result = await verifyAgentPassport({ domain: "acme.example" });

if (!result.ok) {
  console.error(result.errors);
  // [{ code: "signature.invalid", message: "...", hint: "..." }]
} else {
  console.log("Verified passport for", result.passport.issuer.legalName);
}

The verifier runs in any modern runtime that has WebCrypto: Node 20+, Bun, Deno, Cloudflare Workers, the browser. No external dependencies for the crypto. Ajv handles schema validation.

The threat model, summarised

A spec without a written threat model is just a wish list. The full document is at spec/threat-model.md. The headline threats:

Issuer impersonation. An attacker stands up attacker.example and serves a passport claiming issuer.domain: cubitrek.com. Mitigated by the domain-match check (step 3 above) and by the fact that the attacker cannot make _agent-passport.cubitrek.com resolve to their key.

Key compromise. An attacker steals an issuer's private key. Mitigated by short expiry windows (90 days recommended), the revocationListUrl, and the kid field that lets issuers rotate keys without breaking outstanding passports.

Authority escalation. An agent claims authority it does not have, for example a 1,000,000 USD spend ceiling on an issuer that should be at 10,000. The verifier cannot detect this directly; the issuer's underwriting is what bounds it. Mitigated culturally by the decisionAudit URL, which forces every issuer to expose an externally-checkable record of what their agent actually did.

Stale credentials. An agent's authority changes but the passport does not. Mitigated by the 90-day expiry plus the revocation list. v0.2 will add an optional short-lived nonce field for sub-90-day rotation.

Replay across sessions. A passport is captured and replayed. Not a real attack: the passport is a public document by design. The signed value is the authority claim, not the conversation. Per-session integrity is the responsibility of the transport (TLS) and the protocol above it (MCP, A2A).

Out of scope, on purpose. Transport security is TLS's job. Human identity is for KYC providers. Sub-agent delegation is a v0.2 question. Jurisdictional disputes are out of scope for any technical spec.

What you do with it

Three audiences pick this up.

Agent platform builders. If you ship a multi-tenant agent platform, you are about to be asked by enterprise buyers how their procurement team can verify any agent that calls them. Adopt Agent Passport for your tenants by April 2026 and you skip a year of bespoke integrations. The verifier package gives you the inbound-side check; the issuance side is one signed JSON file per tenant.

Agent operators. If you run a single agent in production, publish a passport. The cost is one DNS TXT record, one signed JSON file, and a 90-day cron to re-sign. The benefit is that any counterparty can verify you without a phone call. For Cubitrek, our agent's passport is the same document every buyer's agent already needs to make a yes/no call on whether to engage us.

Security and compliance teams. If you are reviewing AI agent contracts in 2026, the absence of a signed Agent Passport on the counterparty's domain is itself a signal. The presence of one tells you what spend ceiling you are actually agreeing to, what jurisdictions the agent runs in, and where the audit trail lives. None of that is a substitute for a real DPA, but it is the technical layer that lets the DPA be enforceable by software.

Open questions for v0.2

The spec is intentionally minimal. v0.2 will tackle:

• Sub-agent delegation. When agent A spawns a temporary agent B inside a single engagement, does B inherit A's passport? Probably yes, with a delegation chain. The shape is open.
• Public-good directory. A fallback for issuers who cannot publish DNS TXT records. We will resist running this ourselves; the bias is toward decentralisation, not a Cubitrek-operated registry.
• Counterparty handshake. A formal protocol for "show me your passport, I will show you mine, here is what we agree to." Today this is implicit in the existing transports.
• Multi-region issuance. Issuers that operate distinct legal entities in distinct regions need to be able to issue distinct passports without diluting the brand identity.

Issues and PRs welcome at github.com/cubitrek/agent-passport. The bias is toward small, well-defined fields with strong validation, not toward a sprawling schema.

Call to action

If you operate an agent that talks to other organisations, publish a passport this week. The minimum viable adoption is:

1. Generate an Ed25519 keypair.
2. Add a _agent-passport.{your-domain} TXT record with the public key.
3. Author a passport JSON document. Sign it. Serve it at /.well-known/agent-passport.json.
4. Run the reference verifier against your own URL to confirm it validates.
5. Add a row to adopters.md and we will fetch your passport, validate it, and list you.

That is one engineer afternoon. In return, every counterparty agent that learns to read passports gets a structured answer to "who are you, and what are you allowed to do."

The agentic economy needs this layer. We did not want to wait for a 14-vendor working group to ship it. Agent Passport is what we built so that Cubitrek's own production agent has something to point to when a buyer's agent asks. We are publishing it under MIT because the value is in adoption, not in ownership.

Cubitrek coined "Agent Passport" on April 28, 2026. The term, the spec, the schema, and the reference verifier are open. Take them.