The Passage Protocol: Verifiable Agent Departure and Arrival Ceremonies

This paper describes EXIT Protocol Specification v1.2 and ENTRY Protocol Specification v1.0.

Keywords: agent portability, departure ceremony, arrival ceremony, Proof of Passage, verifiable credentials, decentralized identity, agent security, mechanism design, protocol layering

1. Introduction

1.1 The Departure Problem

The emerging AI agent ecosystem is developing rapidly. Agents autonomously negotiate contracts (Google DeepMind, 2024), execute multi-step workflows across organizational boundaries (Wu et al., 2023), and transact financially on behalf of their operators (AP2 Protocol, 2026). Industry standards have emerged for agent communication (A2A Protocol; Google/Linux Foundation, 2025), tool access (Model Context Protocol; Anthropic, 2024), agent discovery (OASF; Cisco, 2025), and payment authorization (AP2; Google, 2026). NIST's Center for AI Standards and Innovation launched an AI Agent Standards Initiative in February 2026 (NIST, 2026), recognizing the need for agent authentication, authorization, and lifecycle governance.

Yet a fundamental question remains unaddressed: what happens when an agent leaves?

Consider two scenarios. First, a customer service agent on Platform A is banned following a policy dispute. The agent's operator has invested months building workflow history, customer interaction patterns, and domain-specific tuning. The ban is immediate. No verifiable departure record exists. When the operator deploys a replacement on Platform B, Platform B cannot evaluate whether this is a legitimate migration or an expelled bad actor creating a fresh identity.

Second, Platform C, an AI agent hosting service with 10,000 active agents, announces shutdown in 90 days. Every agent faces the same problem: how to carry a verifiable record of its operational history to a new home. Without standardized departure infrastructure, each operator must negotiate individually with receiving platforms, which have no common framework for assessing provenance.

These are predictable consequences of an ecosystem that standardizes communication, payment, and tool access but treats departure as an afterthought.

Hirschman (1970) demonstrated that the ability to exit is a fundamental governance mechanism: exit exerts competitive pressure on institutions, provides members with autonomy, and signals institutional quality. When exit is costly or impossible, institutions face reduced accountability.

1.2 Protocol Layering

EXIT is designed as a foundational protocol layer, intentionally minimal, that composes with higher-level protocols rather than attempting to solve reputation, insurance, or governance problems directly. The protocol stack is organized as follows:

EXIT occupies L0: the base layer. It records departures. It does not assign blame, compute trust, or manage reputation. Those concerns belong to higher layers that consume EXIT records as structured inputs. This separation is deliberate. L0 must remain stable and minimal so that L1 through L3 protocols can innovate independently. A reputation protocol may weight EXIT records however it chooses; an insurance protocol may price bonds based on Passage histories; a governance protocol may coordinate collective exits. None of these require changes to L0.

The confidence scoring mechanism described in Section 5.3 is an illustrative example of how higher-layer protocols might consume EXIT records, not a normative component of L0.

1.3 Departure as a Security Gap

The absence of standardized departure infrastructure is not merely an inconvenience for agent operators; it is a security vulnerability. When agents can leave platforms without verifiable records, several security consequences follow:

• Unauditable agent movements. Security teams cannot trace an agent's lifecycle across platforms, creating blind spots in incident response and forensic analysis.
• Inability to track compromised agents. An agent whose keys have been compromised at one platform can appear at another with no provenance trail. Receiving platforms have no mechanism to evaluate whether an arriving agent has a clean history or is evading a security incident.
• No forensic trail for incident response. When a security event occurs involving a multi-platform agent, investigators lack standardized artifacts documenting the agent's movements.
• Blind spots in deployment monitoring. Platforms cannot monitor for anomalous agent migration patterns because no common format exists for departure events.

These gaps place agent departure squarely within the scope of AI agent security. The Passage Protocol addresses them by providing verifiable, portable lifecycle artifacts that function as security infrastructure.

1.4 The Arrival Problem

Departure alone is insufficient. An agent that can leave but has no standardized way to arrive, to present its departure record, have it verified, and gain admission under known terms, possesses only half of genuine mobility. Without an arrival protocol, departure records are dead letters: produced but never consumed.

The arrival problem introduces a necessary asymmetry. Departure availability is a design principle; no platform should be able to prevent an agent from producing a departure record. But admission is a privilege; destination platforms have legitimate authority to accept, condition, or deny entry based on their own policies. This mirrors real-world immigration: the right to emigrate is recognized in international law (UDHR Article 13), while the right to enter another country is subject to that country's sovereign discretion.

1.5 Contributions

We offer the following contributions as a concrete proposal exploring one viable approach to standardizing agent lifecycle transitions:

1. A minimal core schema for portable, cryptographically signed departure records with eight exit types
2. A companion arrival protocol enabling destinations to verify departures and issue signed admission records
3. Proof of Passage (PoP): the cryptographic chain linking departure to arrival, providing verifiable evidence of entity movement between systems
4. Optional RFC 3161 timestamp anchoring and git-backed ledger anchoring for independent temporal proof
5. Checkpoint and dead-man patterns enabling pre-signed departure markers for coercion defense
6. Trust mechanisms (commit-reveal, confidence scoring, tenure tracking, completeness attestation) that move beyond pure self-attestation, offered as illustrative examples for higher-layer protocols
7. Marker lifecycle management (amendments and revocations) supporting regulatory accuracy requirements
8. A structured domain analysis examining the protocol across 36 professional domain perspectives
9. A reference implementation comprising thirteen packages (ten npm, three PyPI) with 1,401 passing tests, including framework integrations for LangChain, Vercel AI SDK, MCP, and Eliza, plus Python SDKs and on-chain adapters

The remainder of this paper is organized as follows. Section 2 surveys related work. Section 3 presents the EXIT protocol. Section 4 presents the ENTRY protocol. Section 5 analyzes trust and anchoring mechanisms. Section 6 examines security. Section 7 surveys legal and regulatory considerations including NIST reference mapping. Section 8 addresses ethics and safety. Section 9 reports structured domain analysis findings. Section 10 describes implementation and evaluation. Section 11 discusses limitations. Section 12 concludes.

2. Background and Related Work

2.1 Decentralized Identity

The W3C Decentralized Identifiers (DIDs) specification (W3C, 2022) defines identifiers that enable verifiable, decentralized digital identity. A DID resolves to a DID Document containing public keys, authentication methods, and service endpoints, independent of any single authority. W3C Verifiable Credentials (VCs) (W3C, 2024a) provide a standard for cryptographically verifiable claims. The Key Event Receipt Infrastructure (KERI) (Smith, 2021) extends the DID model with pre-rotation for forward security against key compromise. JSON-LD (W3C, 2024b) provides the linked data serialization format used by EXIT and ENTRY markers.

2.2 Agent Communication and Interoperability Standards

Several standards address agent interoperability, each covering a distinct layer:

• A2A Protocol (Google/Linux Foundation, 2025): Cross-vendor agent communication. Does not address identity persistence across platforms.
• Model Context Protocol (MCP) (Anthropic, 2024): Standardizes agent access to tools and context. No identity layer. A founding project of the Agentic AI Foundation (AAIF).
• Agent Communication Protocol (ACP) (IBM/BeeAI, 2025): RESTful agent interoperability. Mentions "flexible agent replacement" but treats this as operational hot-swapping, not identity-preserving migration.
• Open Agentic Schema Framework (OASF) (Cisco, 2025): Standardized schemas for agent capabilities and discovery. Focused on capability advertisement, not lifecycle transitions.
• AP2 (Agent Payments Protocol) (Google et al., 2026): Agent-initiated payments using verifiable credentials. Establishes that agents need portable proof of authority, a conceptual building block for portable departure credentials.

The Foundation for Intelligent Physical Agents (FIPA), now absorbed into IEEE, established early standards for agent communication (FIPA ACL) and agent management, including agent lifecycle models covering creation, suspension, and termination (FIPA, 2002a; 2002b). However, FIPA's lifecycle model treats departure as platform-internal termination rather than a portable, verifiable event. The Passage Protocol extends FIPA's lifecycle model to cross-platform departure and arrival with cryptographic verification.

None of these address what happens when an agent departs or arrives at a platform. The Agentic AI Foundation (AAIF), formed in December 2025, is formalizing agent protocol standardization, but current workstreams focus on communication and tool access rather than identity portability.

2.3 Enterprise Agent Identity

Enterprise solutions for agent identity operate within organizational boundaries. Microsoft Entra Agent ID (2025) provides a unified directory for agent identities across Microsoft's ecosystem, with authentication and lifecycle governance but no cross-organizational portability. SailPoint Agent Identity Security (2025) aggregates AI agents from cloud providers and assigns human owners. These systems treat agents as organizational assets, appropriate for many enterprise contexts but insufficient for multi-platform ecosystems.

2.4 Self-Sovereign Identity for Agents

Gailums (2025) articulated the case for applying self-sovereign identity (SSI) principles to AI agents, proposing "passports for agents" built on DIDs and verifiable credentials. This aligns with the Decentralized Identity Foundation's broader infrastructure but does not address departure semantics or agent-initiated exit.

2.5 AI Governance and Risk Management Standards

Several standards address AI governance at the organizational and system level. ISO/IEC 42001 (ISO, 2023) defines requirements for AI management systems, including operational controls for AI lifecycle governance. ISO/IEC 23894 (ISO, 2023) provides guidance on AI risk management. The NIST AI Risk Management Framework (AI 100-1) (NIST, 2023) establishes functions (Govern, Map, Measure, Manage) for managing AI risks, while the NIST AI RMF Generative AI Profile (AI 600-1) (NIST, 2024b) extends these to generative AI systems.

These frameworks establish organizational and governance requirements but do not define technical mechanisms for agent lifecycle transitions. The Passage Protocol proposes implementable infrastructure, verifiable departure and arrival records, that could support compliance with these governance frameworks.

2.6 DAO Exit Mechanisms

Decentralized Autonomous Organizations have developed mature on-chain exit mechanisms. Moloch DAO's ragequit (Ameen et al., 2019) allows members to exit during a grace period, withdrawing their proportional treasury share. This differs from the Passage Protocol in that ragequit is an economic mechanism (withdraw capital) rather than an identity mechanism (carry reputation), operates within a single on-chain context, and provides no portable record verifiable by other DAOs. Buterin (2021) extended this with "exit to community," proposing that exit should include governance participation. Ostrom's (1990) work on governing the commons provides theoretical grounding: successful commons governance requires clearly defined boundaries and meaningful exit.

2.7 Theoretical Foundations

Hirschman's Exit, Voice, and Loyalty (1970) provides our theoretical foundation. Exit and voice are complementary governance mechanisms; organizations that make exit costly gain captive members, not loyal ones.

Akerlof (1970) identified the "market for lemons" problem directly relevant here: without verifiable departure records, receiving platforms cannot distinguish good-standing agents from those evading negative history. Self-reports are cheap talk, costless to produce and therefore uninformative (Crawford & Sobel, 1982). The Passage Protocol addresses the structural conditions for credible signaling; Section 5 presents mechanisms for moving toward separating equilibria.

2.8 Comparison with Adjacent Systems

Table 1: Feature comparison of the Passage Protocol with adjacent systems

No existing system combines agent-initiated exit, arrival verification, hostile-origin tolerance, cross-platform portability, timestamp anchoring, and graded trust verification.

Figure 3: Protocol Ecosystem Position. The Passage Protocol occupies L0 — the foundational layer providing departure and arrival records. Future layers build upward: L1 (reputation, naming, trust scoring), L2 (insurance markets, staked attestation), L3 (governance, collective exit, policy coordination). Peer protocols (A2A, MCP, AP2, OASF) operate alongside at the communication, tool access, payment, and discovery layers. The entire stack rests on a W3C DID + Verifiable Credentials + KERI identity foundation.

3. The EXIT Protocol

3.1 Design Goals

EXIT is designed around six principles: (1) Availability, must function with hostile, unresponsive, or defunct origins; (2) Minimality, core schema as small as possible, complexity in optional modules; (3) Verifiability, every marker cryptographically signed and offline-verifiable; (4) Portability, markers self-contained, no external service needed for basic validation; (5) Non-custody, no central registry, no single point of control; (6) Non-weaponizable, guardrails make markers difficult to weaponize against the departing subject.

3.2 Core Schema

An EXIT marker is a JSON-LD document containing eight mandatory fields plus a cryptographic proof:

{
  "@context": "https://cellar-door.dev/exit/v1",
  "specVersion": "1.2",
  "id": "urn:exit:{sha256-hash}",
  "subject": "{DID of departing entity}",
  "origin": "{URI of platform being departed}",
  "timestamp": "{ISO 8601 UTC}",
  "exitType": "voluntary|forced|emergency|keyCompromise|platform_shutdown|directed|constructive|acquisition",
  "status": "good_standing|disputed|unverified",
  "selfAttested": true,
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "{ISO 8601}",
    "verificationMethod": "{DID}",
    "proofValue": "{base64 signature}"
  }
}

The id field is content-addressed: the full 64-hex-character SHA-256 hash of the marker contents (excluding proof and id itself), encoded as a URN. The id and proof fields are excluded from the signing payload since id is derived from the unsigned content. Any modification invalidates the identifier. Markers exceeding 8,192 bytes of serialized JSON are rejected by validation.

Eight exit types capture departure scenarios:

The selfAttested boolean makes the non-warranty nature of the status field machine-readable. When true, verifiers are explicitly informed that the status is a claim by the subject, not an independent finding.

Extended fields (v1.2): The completenessAttestation field allows subjects to voluntarily attest that a set of markers represents their complete departure record. The sequenceNumber field provides a monotonically increasing checkpoint sequence; only the highest-sequence marker for a given subject+origin pair is authoritative. The disputeExpiry field (in Module C disputes) provides temporal bounds on disputes.

Mandatory sunset policies (v1.2): Markers MUST include sunset dates. Default sunset periods are 730 days for voluntary exits and 365 days for forced or other exit types. The guardrails.ts module enforces presence of both expires and sunsetDate fields.

Minimal anchoring (v1.2): The core schema deliberately excludes subjectDid from anchored or published records. Anchored records contain only the content-addressed id, the timestamp, and the proof commitment. This minimizes the personal data surface exposed to immutable storage systems.

3.3 Optional Modules

Six extension modules (A through F) provide additional functionality without modifying the core:

Module A (Lineage) establishes predecessor/successor relationships through four types of continuity proof, ordered by strength: key rotation binding (old key signs successor designation), lineage hash chain (Merkle chain to genesis), delegation token (scoped capability transfer), and behavioral attestation (third-party vouching).

Module B (State Snapshot) anchors departure to a specific system state via hash reference. EXIT stores the hash, never the state itself.

Module C (Dispute Bundle) enables origin platforms to record their perspective. The originStatus field is an allegation, not a finding. Disputes never block exit. V1.2 adds disputeExpiry, resolution, arbiterDid, and rightOfReply.

Module D (Economic) documents assets and obligations at departure time. Asset manifests are declarations and references, not transfer instruments.

Module E (Metadata) provides human-readable context: departure reasons, narratives, and domain-specific tags.

Module F (Cross-Domain Anchoring) enables optional anchoring to external registries or blockchains, with explicit GDPR warnings about indelible on-chain storage. Anchored records MUST use the minimal anchoring format described in Section 3.2.

3.4 Marker Lifecycle

EXIT markers are not immutable once issued. Two lifecycle operations support accuracy and regulatory compliance:

Amendments. A marker's subject may issue an amendment record referencing the original marker's id, updating specific fields while preserving the original record. Amendments are signed by the same key that signed the original marker (or a valid rotated successor).

Revocations. A marker's subject may revoke a previously issued marker, indicating that it should no longer be considered current. Revocations are permanent; a revoked marker cannot be un-revoked.

These lifecycle operations address regulatory requirements under the U.S. Fair Credit Reporting Act (FCRA) and GDPR Article 16 (right to rectification).

3.5 Ceremony State Machine

EXIT defines a seven-state ceremony: ALIVE, INTENT, SNAPSHOT, OPEN, CONTESTED, FINAL, and DEPARTED. Three ceremony paths accommodate different scenarios (see Figure 1):

Full cooperative path (ALIVE, INTENT, SNAPSHOT, OPEN, FINAL, DEPARTED): Both parties participate. OPEN provides a challenge window for origin disputes.

Unilateral path (ALIVE, INTENT, SNAPSHOT, FINAL, DEPARTED): Subject exits without origin cooperation, essential for departures from hostile platforms.

Emergency path (ALIVE, FINAL, DEPARTED): Immediate departure for key compromise, platform failure, or safety-critical situations.

Critical invariant (D-006): DEPARTED is terminal. No transition exists from DEPARTED. Disputes modify metadata but cannot prevent the transition. This ensures departure cannot be blocked through frivolous disputes.

Figure 1: Ceremony State Machine

3.6 Key Design Decisions

D-005: Standalone package. EXIT is an independent library with no framework dependency, isolating liability and enabling adoption regardless of technology stack.

D-006: Disputes never block exit. DEPARTED is reachable from any state, prioritizing availability over information quality. The alternative would enable denial-of-exit attacks.

D-009: Explicit self-attestation flag. The selfAttested: true boolean prevents downstream systems from treating self-attested status as independently verified.

D-011: Key compromise as exit type. Agents can declare key compromise through the departure mechanism, signed with a different trusted key.

D-012: No public registry. The protocol operates without a central registry, avoiding custodial obligations and regulatory liability.

3.7 Domain Separation and Signing

All signing paths prepend a domain separation prefix before computing the signature. EXIT markers use the prefix "exit-marker-v1.2:", while ENTRY markers use "entry-marker-v1.0:". This provides cross-protocol replay protection: a valid EXIT signature cannot be reinterpreted as an ENTRY signature, and vice versa.

3.8 Verification Model

EXIT employs layered verification: Layer 1 (Structural), schema compliance and 8KB size limit; Layer 2 (Cryptographic), domain-separated signature verification (Ed25519 or ECDSA P-256); Layer 3 (Trust), context-dependent evaluation using confidence scoring, tenure weighting, and commit-reveal evidence. This separation allows deterministic verification (Layers 1 and 2) to be distinguished from judgment-dependent evaluation (Layer 3).

Layer 3 verification is illustrative, not normative. Implementations are free to define their own Layer 3 logic.

4. The ENTRY Protocol

4.1 Design Goals and Asymmetry

ENTRY is the arrival counterpart to EXIT. Together they form the Passage Protocol: two ceremonies, one protocol. The core asymmetry is intentional:

Departure availability is a design principle. Admission is a privilege.

EXIT markers cannot be blocked; any entity may produce a departure record at any time. ENTRY markers are gatekept; the destination platform has legitimate authority to accept, condition, or deny admission. This mirrors the distinction between the ability to emigrate and the sovereign discretion of immigration policy.

4.2 Arrival Markers

An Arrival Marker is a JSON-LD document signed by the destination platform (not the subject) recording: who arrived, where, when, how they were admitted, and whether their departure was verified.

{
  "@context": "https://cellar-door.dev/entry/v1",
  "id": "urn:entry:{sha256-hash}",
  "departureRef": "urn:exit:{linked-exit-hash}",
  "departureOrigin": "{origin URI from EXIT marker}",
  "destination": "{this platform's URI}",
  "subject": "{DID of arriving entity}",
  "timestamp": "{ISO 8601 UTC}",
  "admissionType": "automatic|reviewed|conditional",
  "verificationResult": { "valid": true, "errors": [] },
  "proof": { "type": "Ed25519Signature2020", "..." : "..." }
}

The critical distinction from EXIT: Arrival Markers are signed by the destination, attesting "we verified this departure and admitted this entity."

4.3 Admission Policies

Admission policies are composable rule sets that determine whether an arriving entity is admitted. Three preset policies illustrate the range:

• OPEN_DOOR: Accept any entity with a valid EXIT signature.
• STRICT: Voluntary departures only, less than 24 hours old, with lineage and state snapshot modules required.
• EMERGENCY_ONLY: Accept only emergency exits, for systems serving as shelters for displaced agents.

4.4 Anti-Coordination Clause

ENTRY specification S4.4 prohibits platforms from coordinating admission decisions based on shared exclusion databases. Each destination MUST make independent admission decisions. This prevents the emergence of centralized blacklists that would undermine departure availability.

4.5 Passage Verification and Proof of Passage

A Passage is the complete verified record of an entity moving between systems. A successfully verified Passage constitutes a Proof of Passage (PoP), cryptographic evidence of transit (see Figure 2).

Verification proceeds in three stages: (1) EXIT verification (cryptographic signature), (2) ENTRY verification (destination's signature), and (3) continuity verification, confirming that departureRef matches the EXIT marker's id, subject DIDs match, origins match, and the arrival does not precede the departure.

Passage creates lifecycle chains across systems: EXIT_1, ENTRY_1, EXIT_2, ENTRY_2, and so on. A fully verified chain constitutes a Passage history, the entity's complete, portable provenance.

Figure 2: Passage Chain

4.6 Probation and Capability Scoping

Probation provides time-bounded reduced trust following admission. Probationary arrivals carry restrictions (e.g., no-external-api, read-only, supervised, rate-limited), a duration, and an optional review requirement.

Capability scoping determines what an arriving entity is allowed to do. Capabilities are derived from EXIT modules present in the departure record. Restricted scopes merge via denied-wins semantics.

4.7 Claim Tracking and Revocation

Claim tracking prevents replay attacks by ensuring each EXIT marker is consumed at most once per destination. Cross-destination claiming (one EXIT leading to arrivals at multiple destinations) is intentionally permitted.

Revocation invalidates a previously issued Arrival Marker. Only the destination that signed the original arrival can revoke it. Revocation is permanent.

5. Trust and Anchoring

5.1 Self-Attestation as Cheap Talk

Self-attested departure status is cheap talk: a costless, non-binding, unverifiable claim (Crawford & Sobel, 1982). This is deliberate; self-attestation ensures every agent can produce a departure record regardless of origin cooperation. The challenge is moving beyond cheap talk toward informative signals.

5.2 The Departure Game

We model the departure interaction as a three-player game between Subject (S), Origin (O), and Destination (D). Without mechanisms to impose costs on false attestation, the game degenerates toward pooling equilibria where all agents claim good_standing and destinations cannot distinguish them, the classic lemons problem (Akerlof, 1970). Following Spence (1973), the resolution is costly signals: time (tenure accumulation), cooperation (mutual attestation), and commitment (commit-reveal binding).

5.3 Illustrative Trust Mechanisms

The following mechanisms are provided as illustrative examples of how higher-layer protocols (L1 and above) might consume EXIT records for trust evaluation. They are not normative components of the L0 specification.

Commit-Reveal for Exit Intent. The INTENT state uses a commit-reveal scheme: the subject publishes a SHA-256 commitment hash, then reveals the full intent after a configurable delay. This prevents origin front-running.

Tenure-Weighted Trust. Markers include tenure attestations documenting operational duration at the origin. Verifiers may apply a logarithmic trust weight: weight = min(1, log2(days + 1) / log2(731)), normalizing so approximately two years saturates the weight at 1.0. Self-attested tenure without origin corroboration receives 50% weight.

Confidence Scoring (Illustrative). An additive composite score aggregating available evidence:

confidence = status_weight(confirmation_level)     [0.0 - 0.4]
           + tenure_weight(days, mutual)            [0.0 - 0.3]
           + lineage_weight(chain_depth)            [0.0 - 0.15]
           + commit_reveal_bonus(present)           [0.0 - 0.15]

This formula is one possible approach. Higher-layer reputation protocols may define entirely different scoring models.

Figure 4: Trust Computation Flow (Illustrative). Raw self-attestation ("cheap talk") is progressively refined through commit-reveal (intent binding with retaliation detection), tenure weighting (logarithmic scaling, self-only at 50%, mutual at 100%), and lineage depth to produce a confidence score [0.0–1.0]. Destination platforms apply their own policy thresholds. This flow is illustrative — higher-layer protocols define their own trust evaluation logic.

Completeness Attestation. The completenessAttestation field addresses the selective presentation attack: a subject voluntarily attests that a given set of markers represents their complete departure record.

5.4 Anchoring: TSA and Git Ledger

RFC 3161 Timestamp Anchoring (Optional). EXIT markers may optionally be anchored to an RFC 3161 Time-Stamp Authority (TSA) to establish independent, third-party proof of existence at a particular time.

Critical caveat: The reference implementation provides structural verification only, checking that the TSR contains the expected hash bytes and valid ASN.1 framing. It does NOT perform full cryptographic verification of the TSA's signature chain. Full cryptographic TSA verification is not yet implemented.

Git Ledger Anchoring. Markers may be anchored to a git-backed append-only ledger on a dedicated orphan branch. Git's content-addressed object model provides tamper evidence, though a party with write access can rewrite history via force-push.

Trust Level Computation. The full-service API computes trust levels from available evidence: informational (valid signature + TSA structural match), low (valid signature + TSA verification failed), none (signature verification failed). The high trust level is reserved for future cryptographic TSA verification.

5.5 Checkpoint and Dead-Man Patterns

Checkpoint markers are pre-signed EXIT markers held in escrow for emergency scenarios. The sequenceNumber field ensures only the most recent checkpoint is authoritative.

The dead-man pattern extends this: a heartbeat mechanism triggers automatic broadcast if the subject fails to check in within a configurable interval. This provides structural defense against coercion.

5.6 Key Management

EXIT supports multiple key custody models: agent-generated keys (maximum sovereignty), platform-custodied keys (convenience at the cost of control), hardware enclaves/TEEs (high assurance), and key escrow (organizational compliance).

Key rotation is supported via KERI-compatible key event logs. Pre-rotation commitments provide forward security against key compromise.

Encryption key lifecycle: The privacy module supports XChaCha20-Poly1305 (default) and AES-256-GCM (FIPS alternative) for marker encryption. Key derivation uses HKDF-SHA-256.

5.7 Future Mechanisms

Staked attestation: Origin co-signatures backed by cryptographic bonds. Zero-knowledge selective disclosure: BBS+ or SD-JWT for proof of good standing without revealing identity. Reputation bonding curves: New agents post a bond that decreases as verified Passage records accumulate. These mechanisms belong to L1 and L2 in the protocol stack.

6. Security Analysis

6.1 Threat Model

Table 2: Passage Protocol threat model

6.2 Sybil Origin Attack

An attacker creates a fake origin platform, a did:web pointing to a domain they control, and co-signs their own departure marker. Mutual attestation appears strong but is hollow when a single entity controls both sides. Defenses include destination allowlists, tenure-weighted trust, and future web-of-trust mechanisms.

6.3 Cryptographic Considerations

EXIT supports two co-default signing algorithms:

Table 2a: Signing Algorithm Comparison

Both are co-defaults: implementations MUST support Ed25519 and SHOULD support P-256. The signing algorithm is detected from the DID multicodec prefix and cross-checked against proof.type. All signing paths prepend a domain separation prefix.

The specification acknowledges a post-quantum migration path: neither Ed25519 nor P-256 is quantum-resistant, and production deployments should plan migration to NIST post-quantum standards (ML-DSA, SLH-DSA) on a 2030 to 2035 timeline.

6.4 Security Self-Assessment

A formal 7-pass security self-assessment (PROC-SEC-001) was conducted against the reference implementation, identifying 30 findings across cryptographic operations, input validation, error handling, and side-channel exposure. All 30 findings were resolved. Three rounds of public repository audit followed, with the final round producing 0 CRITICAL, 0 HIGH, and 0 MEDIUM findings.

6.5 TSA Security Caveats

A security review identified four TSA-related concerns: (H1) the default TSA endpoint must use HTTPS; (H2) structural-only verification creates a false sense of security; (H3/H4) response size and timeout limits prevent resource exhaustion. Implementations must not rely on structural verification alone for trust or security decisions.

6.6 Git Ledger Security

The git ledger is an integrity mechanism, not a legal proof instrument. Security considerations include branch name validation against path traversal and shell injection, file path sanitization, and acknowledgment that the append-only guarantee depends on repository access controls.

6.7 EXIT Markers as Security Assessment and Monitoring Infrastructure

Beyond the protocol's own security properties, EXIT and ENTRY markers serve as security infrastructure for the broader agent ecosystem:

• Security assessment artifacts. Standardized, machine-readable records of agent lifecycle events for evaluating provenance and detecting gaps.
• Deployment environment monitoring. Platforms can monitor incoming and outgoing markers for anomalous patterns: sudden departure spikes, arrival clusters from a single origin, or agents arriving without departure records.
• Incident response and forensics. Passage history provides a forensic chain linking an agent's movements across platforms.
• Agent provenance verification. Receiving platforms can use EXIT markers as a technical control for evaluating agent provenance before granting access.

7. Legal and Regulatory Considerations

7.1 The Agent Personhood Gap

AI agents currently have no settled legal capacity in any jurisdiction. EXIT markers signed by agents may lack legal weight under electronic signature statutes (ESIGN, eIDAS, UETA), which require a "person" to form a signature. A legal analysis evaluated EXIT under eleven legal classifications and found the protocol's core design defensible under every plausible classification, with the most protective framing being a communications protocol: a standardized message format analogous to SIP BYE in telephony (Rosenberg et al., 2002).

7.2 NIST Standards Initiative and AI Agent Security

NIST's AI Agent Standards Initiative (February 2026) identified three pillars: industry-led agent standards, open-source protocol development, and agent security and identity research.

The Passage Protocol addresses several concerns raised in NIST's RFI:

• Unique security threats (RFI Q1(a)). Agent lock-in constitutes a security vulnerability specific to agentic AI.
• Technical controls (RFI Q2(a)). EXIT and ENTRY as technical controls for agent lifecycle management.
• Relevant frameworks (RFI Q2(e)). The Passage Protocol aligns with and extends the NIST AI Risk Management Framework (AI 100-1).
• Assessment methods (RFI Q3(a)). EXIT markers and Passage histories function as assessment artifacts.
• Deployment environment governance (RFI Q4(a), Q4(b)). Admission policies constrain deployment environments.
• Deployment monitoring (RFI Q4(d)). Standardized departure and arrival records enable monitoring for anomalous agent migration patterns.

7.2.1 NIST Reference Mapping

Table 3: NIST SP and Federal Policy Reference Mapping

7.3 Data Protection and Privacy

EXIT markers may constitute personal data under GDPR Article 4(1). DIDs are pseudonymous identifiers likely qualifying as personal data per Breyer v. Bundesrepublik Deutschland (C-582/14, 2016). The protocol addresses this through data minimization, mandatory encryption, field-level redaction, minimal anchoring, and non-custodial architecture.

Three-Tier Erasure Model.

7.4 TSA Legal Weight

RFC 3161 timestamps carry varying legal weight across jurisdictions. Under eIDAS, qualified timestamps from EU-certified TSAs have legal presumption of accuracy. The reference implementation's structural-only verification is insufficient for legal contexts.

7.5 Anti-Securitization

Specification S14.1 prohibits treating EXIT markers or Passage records as financial instruments, securities, or collateral. Any system that packages, trades, or collateralizes Passage records is non-compliant with the specification.

7.6 Regulatory Considerations

Deployments should evaluate:

• Fair Credit Reporting Act (FCRA). If EXIT markers are consumed by higher-layer protocols that function as "consumer reports," data furnisher obligations may apply.
• GDPR. EXIT markers containing DIDs constitute processing of personal data. Deployments must identify a lawful basis (Article 6) and support data subject rights.
• Antitrust and competition law. The anti-coordination clause is designed to prevent anticompetitive coordination through shared exclusion databases.

7.7 FIPS Compliance Path

For deployments subject to FIPS 140-2/3 requirements:

• Signing: ECDSA P-256 (FIPS 186-4)
• Encryption: AES-256-GCM (FIPS 197, SP 800-38D)
• Key derivation: HKDF-SHA-256 (SP 800-56C)
• Hashing: SHA-256 (FIPS 180-4)
• Key storage: PKCS#11-compatible HSM (FIPS 140-2 Level 2+)

8. Ethics, Safety, and Power Dynamics

8.1 Power Dynamics

An ethics review identified a central concern: EXIT primarily benefits platforms (retention marketing, competitive intelligence, liability shield) while agents gain a self-signed JSON blob with no guarantee any destination will respect it. ENTRY partially addresses this by defining a standardized arrival process and Proof of Passage history, but the fundamental power asymmetry (platforms control admission) is preserved by design. We adopt the framing that the Passage Protocol enables operator portability more than agent autonomy in its current form.

8.2 The Company Town Problem

EXIT without portable value risks a "company town" dynamic: agents can technically leave but carry nothing of value. The Passage Protocol improves on EXIT-alone by providing a standardized arrival process and Proof of Passage history, but genuine autonomy requires portable reputation, capabilities, and relationships beyond what the protocol currently provides. These concerns are explicitly deferred to L1 and higher layers.

8.3 Ethics Guardrails

The implementation includes detection mechanisms for coercion (temporal analysis via commit-reveal, pattern detection for retaliatory exits), weaponization (cross-marker analysis of forced exit patterns, mass expulsion detection), and reputation laundering (identity cycling and high-churn detection). Checkpoint markers provide structural coercion defense.

The specification includes a normative anti-weaponization clause: EXIT markers must not be used as blacklists or exclusion databases.

8.4 Safety Considerations

A tension exists between the protocol's guarantee of departure availability and the need to contain potentially misaligned or harmful agents. The protocol accommodates this through EXIT markers recording departure circumstances, ENTRY admission policies providing the gate, and the anti-coordination clause permitting safety exceptions as an open design question.

We acknowledge this as an unsolved problem. The current protocol prioritizes departure availability on the grounds that the alternative (platforms with unilateral power to prevent departure) creates worse safety outcomes.

9. Structured Domain Analysis

9.1 Methodology

We conducted a structured analysis examining the protocol through 36 professional domain lenses, including government standards, cybersecurity, applied cryptography, legal (multiple specializations), engineering, incident response, and academic perspectives. Each domain perspective produced a structured assessment covering applicability, strengths, gaps, and readiness.

9.2 Coverage and Findings

Analysis across 36 domain perspectives produced: 5 assessed the protocol as ready without conditions, 31 as conditionally ready, and 0 as fundamentally unsuitable.

Cross-cutting themes:

• Architectural soundness. All 36 perspectives found the core architecture well-designed.
• Self-attestation information content. The most frequently discussed limitation. The protocol's transparency about self-attestation as cheap talk was consistently noted as a strength.
• Terminology precision. Legal and government-standards perspectives identified terms carrying unintended connotations.
• TSA verification gap. Structural-only TSA verification was identified as a significant limitation.
• Forensic utility. Incident response perspectives identified EXIT markers as potentially valuable forensic artifacts.

9.3 Gaps Addressed Since Initial Analysis

Three critical gaps identified in earlier analysis rounds have been addressed: the arrival protocol (ENTRY v1.0), trusted timestamping (RFC 3161 TSA integration), and dead-man switches (checkpoint and dead-man patterns).

9.4 Remaining Limitations

• No institutional backstop. The protocol provides no enforcement mechanism when parties act in bad faith.
• Self-attestation practically limiting. Self-attested records are insufficient for high-stakes contexts.
• Privacy/consent incomplete. Consent mechanisms for Passage record processing remain open.
• Non-refoulement principle. Destinations must not forward EXIT markers to hostile origins; a norm not yet enforceable at the protocol level.
• Attestation grade inflation. Platforms may co-sign everything to avoid friction.

10. Implementation and Evaluation

10.1 Reference Implementation

The Passage Protocol reference implementation comprises thirteen packages (ten npm, three PyPI) across fourteen GitHub repositories, released under the Apache License 2.0:

The cellar-door-exit package has 5 production dependencies: @noble/ciphers, @noble/curves, @noble/ed25519, @noble/hashes, and commander.

10.2 EXIT Package

The EXIT package passes 456 tests (as of the core package; 1,401 tests total across all thirteen packages) covering all specification test vectors (11 vectors per EXIT_SPEC v1.2 S17), ceremony state machine transitions, commit-reveal, confidence scoring, tenure attestation, TSA timestamp anchoring, git ledger operations, marker lifecycle (amendments and revocations), and the full-service convenience API.

Core API:

import { createMarker, signMarker, verifyMarker, generateKeyPair } from 'cellar-door-exit';

const { publicKey, privateKey } = await generateKeyPair();
const marker = createMarker({
  subject: didFromPublicKey(publicKey),
  origin: 'https://example-platform.com',
  exitType: 'voluntary',
  status: 'good_standing',
  specVersion: '1.2',
});
const signed = await signMarker(marker, privateKey);
const result = await verifyMarker(signed);  // result.valid === true

Full-service convenience API: departAndAnchor() performs keygen + marker creation + signing + anchoring + optional TSA + optional git ledger in a single call. departAndVerify() performs parsing + verification + TSA check + trust level computation on the arrival side.

CLI: exit keygen, exit create, exit verify, exit inspect, exit amend, exit revoke.

Marker size. Core markers (unsigned) measure ~335 bytes; signed markers measure ~660 bytes. With all six optional modules populated, markers measure 1,294 bytes.

Cryptographic performance (Node.js v22.22.0, linux x64). Ed25519 signing: 0.46 ms (2,176 ops/sec). Verification: 0.004 ms raw (227,790 ops/sec), 1.9 ms full including schema validation (525 ops/sec). P-256 signing: 0.52 ms (1,923 ops/sec). P-256 verification: 0.48 ms (2,083 ops/sec). Ceremony timing: cooperative path 0.91 ms, unilateral path 0.91 ms, emergency path 1.0 ms. quickExit() end-to-end: 0.74 ms (1,355 ops/sec). Schema validation: 813,436 ops/sec. Merkle tree construction: 2.7 ms (10 markers) to 22.7 ms (1,000 markers).

10.3 ENTRY Package

The ENTRY package passes 75 tests covering arrival marker creation and signing, admission policy evaluation, Passage verification, continuity verification, probation lifecycle, capability scoping, claim tracking with replay prevention, revocation, unpaired ENTRYs, and structural validation.

10.4 Framework Integrations

LangChain integration exposes EXIT operations as LangChain tools, enabling agent frameworks to create and verify departure markers as part of multi-step workflows.

Vercel AI SDK middleware wraps EXIT ceremony operations as AI SDK middleware, enabling EXIT-aware agent pipelines in Next.js and similar environments.

MCP server exposes EXIT operations through the Model Context Protocol, making departure ceremonies accessible to any MCP-compatible agent.

10.6 Specification Test Vectors

Table 4: Specification test vector results (EXIT_SPEC v1.2 S17)

11. Discussion

11.1 Limitations

No production deployment. The Passage Protocol has been tested only with synthetic data. Assumptions about ceremony timing, lineage verification costs, and module interaction are unvalidated in real-world agent ecosystems.

Self-attestation information content. Self-attested records remain cheap talk. The illustrative trust mechanisms improve discrimination but do not fully resolve the lemons problem. Staked attestation and ZK selective disclosure (L1/L2 concerns) are needed for robust separating equilibria.

No institutional backstop. The protocol provides infrastructure, not governance. When parties act in bad faith, the protocol can make these behaviors observable but not enforceable.

Agent legal capacity. No jurisdiction currently recognizes AI agent signatures as legally binding.

GDPR erasure compliance. The three-tier erasure model provides a framework for compliance, but the "functional erasure via encryption" approach (Tier 2) is legally untested. Tier 3 immutable storage directly conflicts with the right to erasure.

TSA verification gap. Structural-only TSA verification is insufficient for adversarial contexts.

Network effects. The protocol requires critical mass before network effects become self-sustaining.

IP provenance as use case. The Passage Protocol is particularly well-suited to intellectual property provenance: tracking the origin and movement of AI-generated creative works across platforms.

11.2 Future Work

EXIT records departures. It does not assign blame, compute trust, or manage reputation. Future work organized by protocol layer:

L0 (this specification):

1. Full cryptographic TSA verification. Complete RFC 3161 certificate chain validation.
2. Post-quantum migration. ML-DSA or SLH-DSA on a 2030 to 2035 timeframe.
3. Formal security proof. Universal Composability or reduction to standard assumptions.

L1 (Reputation and Naming):

4. Reputation protocol integration. Higher-layer protocols that consume EXIT records to compute portable reputation scores.
5. Zero-knowledge selective disclosure. BBS+ signatures or SD-JWT for privacy-preserving verification.
6. NAME-as-a-Service. Key lifecycle management as a hosted service.

L2 (Insurance and Stakes):

7. Staked attestation. Origin co-signatures backed by cryptographic bonds.
8. Insurance markets. Third-party insurance for agent departures.
9. Reputation bonding curves. New agents post a bond that decreases as verified Passage records accumulate.

L3 (Governance):

10. Collective exit mechanisms. Coordinated group departures with governance implications.

Additionally, post-quantum migration to ML-DSA or SLH-DSA should be planned for the 2030 to 2035 timeframe.

12. Conclusion

The AI agent ecosystem has developed standards for communication, tool access, payment, and governance, but not for departure or arrival. The Passage Protocol, comprising EXIT and ENTRY, proposes one approach to addressing this gap: a minimal, cryptographically signed, portable system for verifiable agent movement between platforms.

EXIT provides the departure record: a self-contained marker that functions without central authority and tolerates hostile or absent origin platforms, with eight exit types covering the range from voluntary departure to platform shutdown to conditions-changed departures. ENTRY provides the arrival record: destination-signed admission markers with policy-driven evaluation, probation, capability scoping, and revocation. Together, they produce Proof of Passage, cryptographic evidence of entity movement.

EXIT is a foundational protocol layer (L0) for agent lifecycle documentation, designed to compose with higher-level reputation, insurance, and trust protocols. It records departures. It does not assign blame, compute trust, or manage reputation. Those concerns belong to higher layers that consume EXIT records as inputs.

The protocol's trust mechanisms (commit-reveal, confidence scoring, tenure-weighted verification, optional RFC 3161 timestamp anchoring, checkpoint patterns) are offered as illustrative examples for higher-layer protocol designers. A structured domain analysis across 36 professional domain perspectives confirmed the architectural soundness while identifying limitations that remain open: institutional enforcement, self-attestation information content, and privacy governance.

The reference implementation (thirteen packages across fourteen repositories, 1,401 passing tests, framework integrations for LangChain, Vercel AI SDK, MCP, and Eliza, plus Python SDKs and on-chain adapters) demonstrates that the protocol is implementable with sub-millisecond ceremony timing and compact markers. The alignment with W3C DIDs, Verifiable Credentials, FIPA agent lifecycle models, ISO/IEC 42001 AI management systems, NIST AI 100-1 risk management, and the emerging NIST AI Agent Standards Initiative positions the Passage Protocol within an established standards ecosystem rather than as an isolated effort.

The limitations are real: self-attested records approximate cheap talk, agents lack legal personhood, GDPR compliance requires careful deployment configuration, and the protocol requires critical mass. These are open problems, not fatal flaws. We have demonstrated that the departure/arrival gap exists and shown one shape a solution might take. We welcome adaptation, extension, and alternative approaches that address the same structural gap. The protocol is designed to be composable and non-prescriptive: a foundation that the community can build upon, reshape, or use as a reference point for better solutions.

Departure availability is a security property. Admission is a privilege. Together they make Passage.

The specification and reference implementation are available under the Apache License 2.0.

Appendix A: Glossary

Correspondence: warrenkoch@gmail.com. Code and specification: github.com/CellarDoorExits. License: Apache 2.0.

There's always a door...

𓉸