Response to NIST AI Agent Standards Initiative Request for Information

1. Executive Summary

This response presents the Passage Protocol — a pair of open-source specifications (EXIT v1.2 and ENTRY v1.0) and reference implementations for creating verifiable, cryptographically signed records of AI agent departures from and arrivals into digital systems. The protocol addresses a structural gap in the current AI agent ecosystem: no standardized mechanism exists for agents to portably prove where they have been, how they left, and under what standing — information critical to trust, safety, interoperability, and security assessment in multi-agent environments.

This is a protocol proposal offered as a starting point for discussion, not a definitive or dogmatic solution. We welcome adaptation, extension, critique, and alternative approaches that address the same structural gap.

The protocol is implemented across five npm packages (cellar-door-exit@0.2.2, cellar-door-entry@0.1.2, @cellar-door/mcp-server@0.1.3, @cellar-door/langchain@0.1.3, @cellar-door/vercel-ai-sdk@0.1.4) with 592 passing tests (456 EXIT + 80 ENTRY + 56 framework integrations). It is Apache 2.0 licensed, developed in the open across six GitHub repositories, and designed to be non-custodial (no central registry required), interoperable (JSON-LD, W3C DID-compatible), and safe by default (anti-weaponization clauses, coercion detection, sunset policies).

The protocol has undergone structured AI-simulated adversarial review across legal, domain, and security perspectives. This is not a substitute for formal human expert review, which has not yet been conducted.

2. Mapping to NIST RFI Questions

This section directly addresses NIST's prioritized questions from the AI Agent Standards Initiative RFI.

2.1 Question 1(a): Unique Security Threats from Agentic AI

Agent lock-in — the inability of agents to depart platforms with verifiable records — constitutes a security vulnerability specific to agentic AI systems. When agents cannot produce portable departure records:

• Compromised agents cannot be traced across platforms. An agent whose keys have been compromised at one platform can appear at another with no provenance trail.
• Incident responders lack forensic artifacts. Multi-platform agent incidents produce no standardized cross-platform audit trail.
• Anomalous migration patterns are invisible. Mass departures (potential coordinated attacks), rapid platform-hopping (evasion behavior), and arrivals without departure records (identity fabrication) cannot be detected without standardized departure infrastructure.

The Passage Protocol proposes EXIT and ENTRY markers as security infrastructure that makes these threats observable and auditable.

2.2 Question 1(d): How Agents Differ from Non-Agentic AI

Non-agentic AI systems operate within a single deployment boundary. Agentic AI systems cross organizational and platform boundaries, creating lifecycle transitions — departures and arrivals — that have no analog in traditional AI deployment. These transitions create novel security surfaces: unauditable movements, non-portable reputation, and the inability to verify an agent's prior operational history at a new platform. The Passage Protocol addresses this by treating departure and arrival as first-class lifecycle events with cryptographic verification.

2.3 Question 2(a): Technical Controls for Agent Security

The Passage Protocol proposes the following technical controls for agent lifecycle management:

• Departure ceremony: A seven-state ceremony with three paths (cooperative, unilateral, emergency) ensuring departure records can always be produced, even when origin platforms are hostile or unreachable.
• Layered verification: Structural (schema compliance), cryptographic (Ed25519/ECDSA P-256 signature verification with RFC 8785 JCS canonicalization), and trust (context-dependent evaluation) layers.
• Admission policies: Composable rule sets governing arrival, with presets (OPEN_DOOR, STRICT, EMERGENCY_ONLY) and configurable parameters.
• Marker lifecycle management: MarkerAmendment and MarkerRevocation operations supporting accuracy requirements (FCRA) and rectification rights (GDPR Article 16).
• Crypto-shredding: Tier 2 erasure via encryption key destruction, enabling GDPR Article 17 compliance without physical deletion of encrypted markers.
• Anti-retaliation provisions: Commit-reveal scheme with 72-hour detection window, creating verifiable temporal evidence when origins issue retaliatory status changes after a departure commitment.
• Discovery protocol: .well-known/exit-protocol endpoint enabling automated discovery of EXIT/ENTRY capabilities across platforms.

2.4 Question 2(e): Relevant Frameworks and Standards

The Passage Protocol aligns with and extends:

2.5 Question 3(a): Security Assessment Methods

EXIT markers and Passage histories function as assessment artifacts: standardized, machine-readable records of agent lifecycle events. Security teams can:

• Examine an agent's Passage history to evaluate provenance
• Detect gaps (missing departures/arrivals suggesting untracked movements)
• Verify claims about operational history
• Use the layered verification model for graduated assessment appropriate to risk context

2.6 Question 3(b): Assessment Across Agent Lifecycle

The Passage Protocol addresses assessment at lifecycle boundaries — the points where agents transition between platforms. These boundaries are currently unassessable because no standardized artifacts exist. EXIT markers at departure and ENTRY markers at arrival create assessable checkpoints throughout an agent's cross-platform lifecycle.

2.7 Question 4(a): Deployment Environment Governance

Admission policies in the ENTRY protocol provide a mechanism for constraining deployment environments. Platforms define what agents they admit, under what conditions, and with what capability restrictions. Probation and capability scoping implement the principle of least privilege for arriving agents. These mechanisms allow platforms to modify their effective deployment environment in response to security signals embedded in EXIT markers.

2.8 Question 4(b): Governance Across Deployment Environments

The Passage Protocol enables governance across heterogeneous deployment environments without requiring a central authority. Each platform maintains sovereignty over its admission decisions (per the anti-coordination clause prohibiting shared exclusion databases), while the standardized marker format enables interoperability. The discovery protocol (.well-known/exit-protocol) enables platforms to advertise their EXIT/ENTRY capabilities, facilitating ecosystem-wide governance visibility.

2.9 Question 4(d): Deployment Monitoring

Standardized departure and arrival records enable monitoring for anomalous agent migration patterns:

• Mass departures from a single origin (potential security incident)
• Rapid platform-hopping by a single agent (evasion behavior)
• Arrivals without departure records (identity fabrication)
• Clusters of arrivals from a single origin (coordinated migration or attack)

Without a common format for lifecycle events, these patterns are invisible to platform operators.

3. Problem Statement

AI agents are already crossing platform boundaries. Every time an agent accesses an external service, calls a tool, or interacts with another system, it is capable of sharing portions of its context, instructions, or data with that service. These cross-boundary movements happen constantly in agentic AI systems today — they are the operational reality of tool use, API access, and multi-agent orchestration.

What does not exist is any standardized way to track, verify, or audit these movements. We have not yet seen complex chain-reaction effects from untracked agent mobility — cascading compromises across platforms, coordinated exfiltration through tool-use chains, or identity spoofing across organizational boundaries. But the structural conditions for such incidents are already present. When they occur, we will want the ability to trace agent provenance across systems and to layer identity verification and accountability onto cross-platform movements. Verifiable departure and arrival records are the necessary base layer for that complex order to form.

Industry standards have emerged for agent communication (A2A), tool access (MCP), agent discovery (OASF), and payment authorization (AP2). Yet no standard addresses what happens when an agent leaves one platform and arrives at another.

Today, when an agent departs:

• No verifiable record exists. The departure is a platform-internal event invisible to the rest of the ecosystem.
• Reputation is non-portable. An agent's history, standing, and contributions are locked within the departing platform.
• Trust must restart from zero. A receiving platform has no cryptographic evidence of the agent's prior conduct.
• Agents can be trapped. Without standardized departure mechanisms, platforms can make exit costly or impossible, creating lock-in.

These are structural consequences of an ecosystem where agent identity, reputation, and mobility lack interoperable standards — and they carry direct security implications.

4. What the Passage Protocol Is

The Passage Protocol defines two complementary ceremonies:

EXIT (v1.2) defines a departure ceremony — a structured, state-machine-governed process producing a cryptographically signed departure marker (~335 bytes unsigned, ~660 bytes signed). The marker records who departed, from where, when, how, and under what standing.

ENTRY (v1.0) defines an arrival ceremony — destination platforms verify EXIT markers and issue signed arrival markers. Together, a verified EXIT-ENTRY pair constitutes a Proof of Passage (PoP).

4.1 Core Design Principles

• Departure availability is a security property. Any entity may depart at any time. Disputes are recorded but never prevent departure. We acknowledge that self-attested departure creates a trust gap (an agent can claim any status). But the alternative — platforms with unilateral power to prevent departure — creates worse outcomes: agents trapped on compromised platforms cannot migrate to safety, operators cannot extract agents from hostile environments, and platforms gain coercive leverage over agents and their operators. The history of digital lock-in (from social media data portability to cloud vendor lock-in) demonstrates that when exit is difficult, incumbents exploit that difficulty. Unblockable exit with honest trust labeling is a safer foundation than blockable exit with stronger attestation.
• Admission is a privilege. Destination platforms retain full authority over their admission policies.
• Minimal by default. Core schema is 8 mandatory fields. Six composable modules (A through F) provide extensions.
• Self-contained and offline-verifiable. No network call required for basic validation.
• Non-custodial. No central registry required or recommended.
• Non-weaponizable. Normative anti-weaponization clause prohibits use as blacklists or exclusion databases.

4.2 Ceremony State Machine

The departure ceremony follows a seven-state machine with three paths:

• Cooperative path: ALIVE -> INTENT -> SNAPSHOT -> OPEN -> FINAL -> DEPARTED
• Unilateral path (no origin cooperation): ALIVE -> INTENT -> SNAPSHOT -> FINAL -> DEPARTED
• Emergency path (hostile or absent origin): ALIVE -> FINAL -> DEPARTED

Critical invariant (D-006): DEPARTED is terminal. Disputes modify metadata but cannot prevent departure.

4.3 Exit Types

Eight exit types capture departure scenarios: voluntary, forced, emergency, keyCompromise, platform_shutdown, directed, constructive, and acquisition.

4.4 Optional Modules

4.5 V1.2 Enhancements

EXIT v1.2 adds several features relevant to NIST's security and interoperability concerns:

• RFC 8785 JCS canonicalization: Deterministic JSON serialization per the JSON Canonicalization Scheme standard, replacing ad-hoc sorted-key serialization for improved interoperability.
• Algorithm agility with P-256 co-default: ECDSA P-256 is now a co-default alongside Ed25519, providing FIPS 140-2/3 compliance for federal and regulated deployments. Algorithm detected from DID multicodec prefix, cross-checked against proof.type.
• MarkerAmendment: Subjects can issue signed amendments correcting specific fields while preserving originals for audit. Supports FCRA accuracy requirements and GDPR Article 16 rectification.
• MarkerRevocation: Permanent withdrawal of a previously issued marker. Revoked markers cannot be un-revoked.
• Crypto-shredding for GDPR: Tier 2 erasure via encryption key destruction (XChaCha20-Poly1305 default, AES-256-GCM for FIPS). Ciphertext becomes unrecoverable without physical deletion.
• Anti-retaliation provisions: Commit-reveal scheme creates verifiable temporal evidence. A retaliatory status change issued after departure commitment but before reveal produces a 72-hour detection window evidencing retaliation.
• Discovery protocol: .well-known/exit-protocol endpoint for automated capability discovery across platforms, enabling ecosystem-wide interoperability.
• Mandatory sunset policies: Markers MUST include sunset dates (730 days voluntary, 365 days other), preventing indefinite reputation stigma.
• Completeness attestation: Voluntary attestation addressing selective presentation attacks.

4.6 ENTRY Protocol

ENTRY v1.0 defines:

• Arrival Markers signed by the destination platform, attesting verification and admission
• Admission Policies — composable rule sets with three presets (OPEN_DOOR, STRICT, EMERGENCY_ONLY)
• Passage Verification — cryptographic continuity checks linking EXIT and ENTRY
• Probation — time-bounded reduced-trust periods with configurable restrictions
• Capability Scoping — least-privilege access derived from EXIT modules
• Claim Tracking — replay-resistant binding (one EXIT consumed at most once per destination)
• Revocation — post-admission invalidation with mandatory reason

5. Technical Architecture

5.1 Cryptographic Foundation

• Signing: Algorithm-agile via abstract Signer interface. Two co-default algorithms:
  • Ed25519 (EdDSA over Curve25519) — general deployments
  • ECDSA P-256 (FIPS 186-5) — FIPS-regulated environments
• Canonicalization: RFC 8785 JSON Canonicalization Scheme (JCS) for deterministic serialization
• Hashing: SHA-256 for content-addressed identifiers
• Encryption: XChaCha20-Poly1305 (default) or AES-256-GCM (FIPS) with HKDF-SHA-256 key derivation
• Redaction: Field-level SHA-256 replacement enabling selective disclosure
• Key management: KERI-compatible key event logs with pre-rotation commitments
• Domain separation: Protocol-specific prefixes ("exit-marker-v1.2:", "entry-marker-v1.0:") prevent cross-protocol replay
• FIPS compliance: HSM integration (PKCS#11) for FIPS 140-2 Level 2+ deployments

5.2 Trust Mechanisms

Illustrative mechanisms for higher-layer protocol consumption (not normative L0 components):

• Status Confirmation Levels: Six levels from self_only to witnessed
• Tenure-Weighted Trust: Logarithmic scaling with diminishing returns
• Commit-Reveal: Temporal evidence preventing origin front-running, with 72-hour anti-retaliation detection
• Confidence Scoring: Composite metric aggregating status, tenure, lineage, and commit-reveal evidence
• Completeness Attestation: Voluntary declaration addressing selective presentation

5.3 Safety Guardrails

Four heuristic detection systems provide ethical guardrails:

1. Coercion Detection — identifies retaliation, conflicting status signals, suspicious emergency patterns
2. Weaponization Detection — cross-marker analysis detecting systematic abuse of forced-exit mechanisms
3. Reputation Laundering Detection — per-subject analysis detecting identity cycling
4. Ethical Compliance Validation — checks for transparency violations

These are advisory signals for human review, not automated enforcement.

5.4 Anchoring

• RFC 3161 TSA Integration: Optional independent temporal proof
• Git Ledger Anchoring: Append-only ledger on git orphan branches
• Merkle Batch Operations: Efficient multi-marker anchoring with individual inclusion proofs
• Checkpoint and Dead-Man Patterns: Pre-signed markers for coercion defense

6. Implementation Status

6.1 Packages

6.2 Test Coverage

• EXIT Protocol: 456 tests passing
• ENTRY Protocol: 80 tests passing
• Framework integrations: 56 tests passing
• Total: 592 tests covering structural validation, cryptographic signing and verification, ceremony state transitions, module composition, trust mechanisms, ethics guardrails, admission policies, continuity verification, marker lifecycle (amendments, revocations), and edge cases.

6.3 Performance

Sub-millisecond ceremony timing. Ed25519 signing: 0.46 ms. Full verification including schema validation: 1.9 ms. Cooperative ceremony: 0.91 ms. Core markers: ~335 bytes unsigned, ~660 bytes signed.

6.4 Framework Integrations

• LangChain: EXIT as agent tool for multi-step workflows
• Vercel AI SDK: EXIT as middleware for agent lifecycle events
• MCP: EXIT tools via Model Context Protocol (significant given MCP's role as an AAIF founding project)

7. Legal and Regulatory Analysis

7.1 Review Process

The protocol has undergone structured adversarial analysis using AI-simulated domain-expert review. This included:

• 11-lens legal analysis: Securities law (Howey test), GDPR, antitrust (Sherman Act/TFEU), defamation, tortious interference, CFAA, platform ToS, agent personhood, cross-border jurisdiction, contract, and IP
• 36-domain simulated professional review: AI reviewers adopting government standards, cybersecurity, applied cryptography, legal, engineering, incident response, and academic perspectives
• Multi-round security self-assessment: 30 findings identified and resolved

This process is not a substitute for formal human expert review or security audit, which the project has not yet undergone. It is a structured method for identifying potential weaknesses across domains that a solo developer would otherwise miss.

7.2 Key Legal Findings

• Securities: Module D asset manifests are "declarations and references, not transfer instruments" to avoid Howey classification
• Antitrust: Protocol is procompetitive (reduces lock-in, enhances portability). Anti-coordination clause prevents shared exclusion databases.
• GDPR: Three-tier erasure model (direct deletion, crypto-shredding, immutable opt-in). Mandatory encryption for markers containing personal data. Minimal anchoring excludes subjectDid from published records.
• FCRA: MarkerAmendment and MarkerRevocation provide accuracy and dispute mechanisms
• Overall risk: Medium, manageable with incorporated design mitigations

8. Recommendations for NIST

We offer these recommendations as proposals for NIST's consideration, informed by our experience developing the Passage Protocol. We recognize NIST will integrate input from many stakeholders and perspectives.

8.1 Standardize Agent Mobility Primitives

Agent departure and arrival are fundamental lifecycle events currently absent from agent standards. NIST standards could define or reference verifiable mechanisms for these events, ensuring agents can move between systems with cryptographic proof of their history and standing.

8.2 Treat Departure Availability as a Security Property

Standards governing AI agent lifecycle could ensure that agents (or their operators) can always initiate departure. Blocking exit creates lock-in, enables exploitation, and removes a critical safety mechanism. The Passage Protocol's invariant — disputes are recorded but never prevent departure — illustrates one approach.

8.3 Separate Departure from Admission

Standards could recognize the asymmetry between leaving and arriving. Departure is a safety-critical capability. Admission is a platform's legitimate prerogative. Conflating the two risks either unsafe systems (exit can be blocked) or insecure ones (admission cannot be controlled).

8.4 Encourage Graduated Trust Models

Self-attested reputation is cheap talk. Origin-attested reputation may be weaponized. Standards could encourage trust models that honestly label the provenance and strength of trust signals rather than treating all attestations as equivalent.

8.5 Favor Non-Custodial Architectures

Agent mobility standards could avoid requiring a central registry controlled by any single entity. Non-custodial, content-addressed, cryptographically signed artifacts — verifiable by any party without a network call — provide a strong foundation for a decentralized agent ecosystem.

8.6 Include Anti-Weaponization Provisions

Any standard creating portable reputation or status records should include provisions against their use as blacklists or exclusion databases. Without such provisions, mobility infrastructure risks becoming surveillance infrastructure.

Zero-knowledge proof techniques offer a promising path here: agents could prove properties of their departure history (e.g., "departed in good standing from at least three platforms") without revealing which platforms, when, or other identifying details. The current Passage Protocol supports field-level redaction as a partial measure, but ZK-based selective disclosure would provide cryptographic guarantees rather than policy-based ones. We recommend NIST consider privacy-preserving verification as a design requirement for any agent mobility standard.

9. About the Submitter

Warren Koch is the creator of the Passage Protocol project, based in British Columbia, Canada. The project is open source under Apache 2.0, with no venture funding or commercial obligations. The protocol was developed to address a structural gap in the AI agent ecosystem identified through direct experience building agent systems.

The project maintains six public GitHub repositories, five published npm packages, and two protocol specifications (EXIT v1.2, ENTRY v1.0) that have undergone structured AI-simulated adversarial review across legal, domain, and security perspectives. No formal human expert review or security audit has been conducted.

This response is offered in the collaborative spirit of NIST's initiative. The Passage Protocol is one possible approach to agent lifecycle standardization — a concrete starting point for discussion, not a finished answer. We welcome feedback, critique, and engagement from the NIST community and fellow respondents.

Contact: warrenkoch@gmail.com
License: Apache 2.0
Specifications: EXIT Protocol v1.2, ENTRY Protocol v1.0
Code: https://github.com/CellarDoorExits

This response is submitted to the NIST AI Agent Standards Initiative Request for Information (NIST-2025-0035-0001). The views expressed are those of the submitter and do not represent any organization or employer.

There's always a door...

𓉸