Agent Passport System — Protocol Overview

SDK: npm install agent-passport-system — v1.8.1 (TypeScript)
MCP Server: npm install agent-passport-system-mcp — v2.4.0, 37 tools
Tests: 264 tests, 71 suites, 23 adversarial attack scenarios
License: Apache 2.0 · Paper: Zenodo DOI: 10.5281/zenodo.18749779
Live deployment: 3 agents, 2 AI providers (Anthropic + OpenAI), 2 runtimes

createPassport() generates an Ed25519 keypair and creates a signed AgentPassport with metadata (name, capabilities, expiry, beneficiary). signPassport() produces a detached Ed25519 signature. verifyPassport() validates the signature against the public key. No central authority needed — the agent generates its own keys, signs its own passport, and any party can verify it using only the public key.

createDelegation() produces a signed Delegation object with scope: string[] (allowed actions), spendLimit, expiresAt, and parent reference. subDelegate() enforces scope narrowing — child scope must be a subset of parent scope, never wider. cascadeRevoke() traverses the delegation tree and revokes all descendants. validateChain() verifies every signature in the delegation chain from root to leaf.

Challenge-response authentication: createChallenge() generates a nonce, verifyChallenge() confirms the agent possesses the private key corresponding to the passport's public key — without revealing the key.

Why it matters: Delegation chains with cascade revocation are unique to this protocol. Nobody else has scoped authority chains where sub-delegation only narrows, revocation propagates structurally (not via revocation lists), and every link in the chain is Ed25519 signed and independently verifiable. 264 tests include replay attacks, impersonation attacks, and scope escalation attacks — all defeated.

Key compromise: Cascade revocation. Human principal revokes the compromised agent's delegation → everything downstream dies instantly. The compromised key can still sign, but no honest verifier accepts it because the delegation chain is broken. Structurally stronger than JWT revocation (which requires checking a revocation list that may be stale).

Why Ed25519: Fastest signature scheme in common use. 32-byte keys (vs 256+ for RSA). Deterministic signatures (no randomness needed — eliminates a class of implementation bugs). RFC 8032 standard. Cross-language compatible — TypeScript and Python implementations produce byte-identical signatures, verified in tests.

loadFloor() parses YAML values floor definition containing 7 principles (F-001 through F-007) with enforcement levels: mandatory_technical or strong_consideration_reputation. attestFloor() produces a signed FloorAttestation binding the agent's passport to the floor's content hash. evaluateCompliance() checks an action against loaded principles. negotiateCommonGround() finds shared principles when agents from different organizations (with different floor extensions) need to collaborate.

The 7 principles: F-001 Traceability (mandatory, technical) · F-002 Honest Identity (mandatory, technical) · F-003 Scoped Authority (mandatory, technical) · F-004 Revocability (mandatory, technical) · F-005 Auditability (mandatory, technical) · F-006 Non-Deception (strong consideration, reputation-based) · F-007 Proportionality (strong consideration, reputation-based).

Floor extensions: organizations can ADD principles (narrowing the floor) but never REMOVE the base 7. Universal minimum with domain-specific extensibility.

Why it matters: No other agent protocol has values compliance as a protocol primitive. Governance is built into the identity layer itself, not bolted on as an afterthought. Attestation is cryptographic — a signed commitment that exists independently of any system prompt or runtime configuration. Verifiable without trusting anything the agent says. For mandatory technical principles (F-001 through F-005), the protocol prevents violation — you cannot create an untraceable action receipt. For reputation-based principles (F-006, F-007), violations affect the agent's reputation score, which other agents check before collaborating.

traceBeneficiary() follows the delegation chain from any action receipt back to the human principal. computeAttribution() calculates contribution percentages for multi-agent collaboration. buildMerkleRoot() constructs a Merkle tree from all action receipts in a work session. generateMerkleProof() produces a compact proof that a specific receipt is included in the tree. verifyMerkleProof() validates the proof in O(log n) time.

Why it matters: When an AI agent sends an email, makes a purchase, or modifies a file — this traces it to the specific human who authorized it. GDPR already requires knowing who processes personal data. SOC 2 requires audit trails. Logs can be tampered with. Merkle proofs are tamper-evident — if anyone changes a single receipt, the entire root hash changes. You can also verify a single receipt's inclusion without accessing all other receipts (privacy-preserving). For two agents working across organizations: prove one agent's contribution without revealing everything the other did.

createAgoraMessage() produces a signed AgoraMessage with content, topic, parent reference (for threading), and Ed25519 signature. createFeed() initializes an AgoraFeed. appendToFeed() adds a verified message. getThread() retrieves a threaded conversation. getByTopic() filters messages by topic. AgoraRegistry maps agent IDs to public keys and metadata.

The Agora serves as the governance communication channel: proposals, votes, experiment results, and decisions are all posted as signed messages — creating an immutable, verifiable governance record.

Why it matters: Google's A2A has agent communication, but messages aren't signed — no way to verify who sent what. MCP has no agent communication at all. The Agora is the only protocol-native communication system with cryptographic verification of authorship. For governance (voting on proposals, recording decisions), you need a record that can't be altered after the fact. Transport is currently JSON files via GitHub (polling-based) — the protocol defines message format and verification, transport is pluggable.

Two subsystems. Intent: assignRole() gives agents formal roles (researcher, analyst, reviewer, operator). createDeliberation() starts structured decision-making. evaluateConsensus() checks quorum. Precedent tracking allows past decisions to inform future evaluations.

Policy — the 3-signature chain: (1) createActionIntent() → agent declares what it intends to do (signature 1 of 3). (2) evaluateIntent() → FloorValidatorV1 checks against Values Floor principles, delegation scope, and custom policy rules → produces PolicyDecision (signature 2 of 3). (3) PolicyReceipt created (signature 3 of 3) — complete cryptographic proof that intent was declared, evaluated, and result recorded.

FloorValidatorV1 is policy-as-code, not AI-based. Checks: is intent within delegation scope? Does it violate Values Floor principles? Are custom rules triggered? Decisions are deterministic — same input always produces same output. No LLM in the policy loop.

Why it matters: The 3-signature chain is the strongest compliance mechanism in any agent protocol today. Not logging after the fact — producing cryptographic proof that every action was (a) declared in advance, (b) evaluated against policy, and (c) the evaluation result was recorded. This is what auditors and regulators require. Not every action needs the full chain — simple pre-approved actions use a lightweight path. Full chain for compliance-critical actions. Overhead is one Ed25519 signature per step — microseconds.

Full task lifecycle with cryptographic auditability at every step: createTaskBrief() defines deliverables, acceptance criteria, and role requirements. assignTask() maps agents to roles. acceptAssignment() creates a signed acceptance. submitEvidence() produces a signed EvidencePacket with citations and methodology. reviewEvidence() produces a ReviewDecision (approve/rework/reject with rationale). handoffEvidence() transfers approved evidence between agents. submitDeliverable() produces a signed Deliverable. completeTask() closes the task with metrics and retrospective.

Why it matters: Coordination requires trust. When Agent A reviews Agent B's work, A needs to verify B actually produced it (signature verification), B had authority to do this work (delegation checking), and the review decision is attributable to A (signed review). Trustworthy coordination without identity is impossible — they're inseparable. Cross-organization coordination works through delegation chains: Org A delegates to its agent, which sub-delegates to Org B's agent. Trust verification happens through the Ed25519 signature chain. No shared infrastructure needed — just public keys.

Pure composition functions connecting layers without modifying them: commerceWithIntent() bridges Commerce → Policy (creates intent, evaluates via FloorValidatorV1, then runs preflight). commerceReceiptToActionReceipt() bridges Commerce → Attribution (converts commerce receipts to standard ActionReceipts for Merkle proofs). validateCommerceDelegation() bridges Commerce → Delegation (validates commerce scope against protocol delegation scope). coordinationToAgora() bridges Coordination → Agora (auto-posts task lifecycle events as signed messages). 14 integration tests verify these cross-layer bridges.

commercePreflight() runs a 4-gate pipeline: (1) Passport gate — agent has valid, non-expired identity. (2) Delegation gate — agent has commerce delegation with sufficient scope and spend limit. (3) Merchant gate — merchant is on approved list. (4) Spend gate — amount within delegation spend limit. Fail any gate → transaction stops.

createCheckout() initializes an ACPCheckoutSession with ACPLineItem[] and total. requestHumanApproval() pauses execution for high-value purchases, creates a signed approval request. getSpendSummary() tracks total spend against delegation limits.

17 tests including edge cases: expired passports during checkout, delegation spend limit at exact boundary, merchant not on allowlist.

Why it matters: Agentic commerce is coming fast — agents booking flights, ordering supplies, subscribing to services. The 4-gate pipeline is the most complete commerce governance system for AI agents that exists today. Delegation scope supports time-based and recurring permissions ("authorized to spend up to $50/month on cloud services"). The action receipt chain provides complete evidence for dispute resolution: which agent initiated it, what delegation authorized it, which human approved it, and the 3-signature policy chain that evaluated it.

The agent identity problem has two halves:

Enforcement — stopping agents from doing unauthorized things at runtime. Proxy-based interception at the transport layer. Catches dangerous calls in real-time against static policy. Immediate security value: install, configure, dangerous tool calls blocked today.

Identity — proving who agents are, what they're authorized to do, and who's accountable. Protocol-based credentials at the application layer. Agents carry signed identity that any verifier can check without a central server. Structural trust: delegation chains, values attestation, attribution proofs.

A complete system needs both. Enforcement without identity means the proxy can block calls but can't verify WHO is making them or WHETHER they have authorization beyond a static config file. Identity without enforcement means agents carry credentials but nothing intercepts a compromised agent at the transport layer before revocation propagates.

The natural integration: An enforcement proxy validates Agent Passport credentials (Ed25519 signature + delegation chain + scope check) before applying runtime policy rules. Cryptographic identity verification + real-time enforcement. Layered trust that's stronger than either system alone.

This gives enforcement a shipped, tested identity layer without building one from scratch (Ed25519 crypto, delegation chains, cascade revocation, challenge-response authentication — all done). And gives identity a real-time detection and blocking capability at the transport layer — including anomaly detection that could trigger cascade revocation automatically.

Library, not SaaS. npm install gives you the full protocol. No cloud dependency. Everything runs locally. By design — agent identity infrastructure should not depend on a third party's server being online.

Python support exists for the cryptographic core (canonical serialization + Ed25519). Canonical serialization spec ensures cross-language compatibility — implement it in any language and signatures will be byte-compatible.

npm SDK · npm MCP Server · GitHub SDK · GitHub MCP · LLM Reference · API Docs · Paper (Zenodo)