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 lives in the same repository under packages/verifier, published as source rather than on npm so far. 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

About twenty lines of code. For well-formed passports the output matches RFC 8785 (JSON Canonicalization Scheme), so an implementation in Python or Go can use an existing RFC 8785 library, and the repository's tests pin the exact bytes of a real signed passport to check against.

How verification flows, end to end

A verifier (the counterparty agent or its server) checks a passport in eight 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, without following redirects. Non-2xx is fetch.non-2xx, a redirect is fetch.redirect, and a 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. Key zone. passport.issuer.signingKeyDns must sit inside passport.issuer.domain, for example _agent-passport.acme.example. If not, issuer.signing-key-outside-domain, and the verifier never queries that name. Without this check, anyone could name any company as the issuer and publish a key in a DNS zone they control.
5. Validity window. issuedAt <= now < expiresAt. Outside is time.issued-in-future or time.expired.
6. 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 dns.no-records. An answer that is not DNSSEC-validated passes with a dns.unauthenticated warning.
7. Verify signature. Reconstruct canonical bytes with signature.value = "". Verify Ed25519 against the resolved public key. Failure is signature.invalid.
8. 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 by default; pass revocationFailure: "error" to fail closed.

A valid passport proves what the issuing company authorised. It does not prove that the party messaging you is that company's agent, because the file is public, so confirm the caller through your own channel as well.

The reference verifier wraps all eight 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 anywhere WebCrypto supports Ed25519: Node 20+, Cloudflare Workers and modern browsers. No external dependencies for the crypto. Ajv handles schema validation. To act on a verified passport, authorize() returns allow, escalate or deny against its limits, and agent-passport doctor checks your own published passport end to end.

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 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.

What changed since the proposal

The argument above is unchanged and the spec is still v0.1. What changed is that publishing a signed document turned out to be the easy half. Five things shipped since April, and each one came from a gap in the original design.

A passport does not prove who is calling you

This is the correction that matters most, and the original post did not make it clearly enough.

A passport is a public file. Anyone can fetch Cubitrek's, quote it, and claim to be our agent. Verifying it proves what the issuer authorised. It proves nothing about who is on the other end of the connection.

So issuers can now publish request-signing keys inside the passport, and a receiver checks the signature on the actual request:

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

const caller = await verifyAgentCaller(request, verification.passport, { nonceStore });
if (!caller.ok) return reject(caller.errors);

That is a standard HTTP Message Signature (RFC 9421) over the method, host, path, query and body. It refuses a signature that is stale, replayed, made with a key the passport does not publish, or that leaves part of the request uncovered. Mutual TLS or an OAuth client registered to the issuer bind a caller just as well. The point is to bind it somehow before acting on the passport's authority, and the spec now says so plainly instead of leaving a reader to assume.

The document became a decision

A ceiling in a JSON file is a claim. What a receiver needs is an answer. authorize() applies the whole envelope, scope, ceiling, human-in-the-loop threshold, counterparty rules, regions and data classification, and returns allow, escalate or deny with reason codes attached.

The subtle part is what the answer is attached to. A decision is bound to the concrete tool, target and arguments, and it expires after sixty seconds. Whatever performs the side effect goes through one gate:

const result = await guardedCall(decision, finalRequest, () => provider.transfer(finalRequest), {
  ledger, nonceStore, receipts,
});

It refuses if the arguments changed after the decision, if the decision expired, if it was a deny, if an escalation has no human confirmation, or if it was already used. An authorisation that is not bound to a specific request authorises the next request too, which is how "approved" quietly becomes "approved for anything similar".

A ceiling nobody counts is a statement of intent

The original post described a hard spend ceiling as though publishing it were enough. It is not. Forty commitments of 2,000 each pass every individual check against a 50,000 ceiling, and nothing in v0.1 noticed.

There is now a ledger that reserves the amount when the decision is made and commits it once the effect has actually happened. Two decisions taken before either executes cannot both spend the same headroom. A hold that is never settled lapses when the decision expires, so a crashed run releases its own budget.

The behaviour change worth knowing: a cap spanning a day, a month or a whole engagement, with no ledger attached, now escalates rather than passing quietly. Nothing is counting it, so it is a question for a person rather than a silent yes.

Receipts you can hand to someone else

Every decision that reaches the guard leaves a record: who acted, under which authority, what was decided and why, the binding digest, and what became of it. Receipts can be signed with Ed25519 and checked by anyone holding the public key, without access to any of our systems.

A receipt deliberately carries no payload. The tool name, the scope and the amount are in it. The target and the arguments are not. The binding digest already covers those, so anyone holding the original request can prove it is the one the receipt refers to, while the receipt on its own discloses nothing. That is what makes it safe to hand to an auditor or to the counterparty.

The half that needs nobody else to adopt anything

This is the change that made the work useful immediately rather than after an adoption curve.

The same rules run with no counterparty in sight. Write a local policy, and the decision engine applies it exactly as it applies a passport's envelope. Put it in front of your own agent's tools and a refused call never reaches the tool at all:

agent-passport guard --policy treasury.json --ledger spend.jsonl -- npx -y @stripe/mcp

A 9,000 USD charge against a 5,000 cap comes back to the model as a refusal naming the cap, and the payment server never hears about it. That distinction is the whole point. An advisory limit the model can decline to consult is not a limit.

One detail we got wrong first and had to fix: the bridge from a policy to a tool call has to be written by the operator, never inferred. Only you know that stripe.create_charge({ amount: 800000 }) means 8,000 USD. Guessing which field holds the money is how a cap silently stops being enforced, so a rule whose amount path finds no number refuses the call rather than waving it through.

There is also a hook for Claude Code itself, which sees Bash, Write and Edit, not just MCP tools.

And when a decision comes back with a passport and a local policy both in play, the two intersect: scopes narrow to the overlap, every ceiling is enforced, and the lower human threshold wins. What a counterparty published is a maximum it can be held to, never permission to exceed your own rules.

Open questions for v0.2

The spec is intentionally minimal. Still open:

• 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 still 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.
• 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.
• Money as minor units. Amounts are currently floating point, so 0.1 plus 0.2 plus 0.7 against a ceiling of 1 allows. That is arithmetically correct and still wrong for accounting. Minor units are the fix and it is a breaking change, so it has to land before the package is published rather than after.
• The per-engagement ceiling only binds when it is used. A passport can publish a ceiling per engagement, but it constrains a run of actions only if the receiver passes an engagement id. That gap is the argument for intersecting a local policy over a counterparty's envelope rather than trusting the envelope alone.

Answered since v0.1. The counterparty handshake question is partly closed: request-signing keys published inside the passport give a receiver a way to bind the caller, so "show me your passport" is now separable from "prove you are the one it describes." What a run of actions agrees to up front is still implicit in the transport.

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."

If nobody you deal with reads passports yet, start at the other end, which needs no agreement from anyone. Write down what your own agent may do, put the guard in front of its tools, and read the receipts back:

agent-passport guard --policy treasury.json --ledger spend.jsonl --receipts receipts.jsonl -- <your mcp server>
agent-passport log --receipts receipts.jsonl

The rules you write there are the same rules a passport publishes. When a counterparty does turn up with one, the two intersect and the tighter of the pair binds.

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.