DEV Community: Warren Koch

On-Chain AI Agent Attestations with EAS

Warren Koch — Thu, 12 Mar 2026 19:45:44 +0000

When an AI agent moves between platforms, the departure record needs to live somewhere trustworthy. For most cases, a local database works fine. But when you need immutable, publicly auditable records, you need on-chain anchoring.

Why On-Chain?

Off-chain markers are signed and verifiable, but depend on someone storing them. On-chain anchoring puts the marker's hash on an immutable ledger. Regulatory compliance, legal disputes, and insurance claims can reference it.

Not every marker needs this. Most don't. But for high-stakes operations, the option matters.

Setup

npm install @cellar-door/eas cellar-door-exit ethers

Creating an Anchored Marker

import { quickExit, toJSON } from 'cellar-door-exit';
import { anchorToEAS } from '@cellar-door/eas';

const { marker } = quickExit('did:web:platform.example');

const attestation = await anchorToEAS(toJSON(marker), {
  provider: ethersProvider,
  signer: ethersSigner,
});

console.log('Attestation UID:', attestation.uid);

Verification

import { verifyEASAttestation } from '@cellar-door/eas';

const result = await verifyEASAttestation(attestationUid, {
  provider: ethersProvider,
});

console.log(result.valid); // true

Other On-Chain Options

ERC-8004: ties departure records to on-chain identity and reputation
Sign Protocol: alternative attestation framework

npm install @cellar-door/erc-8004
npm install @cellar-door/sign-protocol

When to Use On-Chain vs Off-Chain

Off-chain (default): fast, free, works for most cases.

On-chain: when you need immutability, public auditability, or regulatory compliance.

The protocol doesn't force either path.

EXIT Protocol + MCP: Portable AI Agent History

Warren Koch — Thu, 12 Mar 2026 19:45:08 +0000

The Model Context Protocol (MCP) gives AI agents a standard way to use tools. The Passage Protocol gives them a standard way to record that they used those tools and moved on.

The Gap MCP Doesn't Fill

MCP standardizes how agents discover and call tools. But it doesn't track what happens when an agent finishes with a service and moves to the next one. There's no departure record, no audit trail.

The EXIT protocol fills that gap with signed departure markers.

The MCP Server

npm install @cellar-door/mcp-server

Your MCP-compatible agent gets:

exit_create: create a signed departure marker
exit_verify: verify an existing marker
entry_admit: verify a departure record and create an admission stamp

Configuration

{
  "mcpServers": {
    "passage-protocol": {
      "command": "npx",
      "args": ["@cellar-door/mcp-server"],
      "env": {
        "EXIT_ORIGIN": "did:web:myplatform.example"
      }
    }
  }
}

The Flow

Agent connects to Platform A via MCP
Agent does its work
Agent calls exit_create for a signed departure marker
Agent connects to Platform B
Platform B calls entry_admit with the marker
If it verifies and passes policy, the agent is admitted

Each marker is ~335 bytes. Signed. Verifiable offline.

Adding Departure Records to Your LangChain Agents

Warren Koch — Thu, 12 Mar 2026 19:44:33 +0000

Your LangChain agent calls tools on external platforms. It chains through multiple services. Eventually, it finishes and moves on. But where's the record of what happened?

The Passage Protocol adds signed departure records to LangChain agents: verifiable proof that your agent was somewhere, did something, and left under specific conditions.

Why This Matters

When agents operate across multiple platforms, you need audit trails. Insurance, compliance, and incident response all depend on knowing where an agent has been.

Setup

npm install @cellar-door/langchain @langchain/core cellar-door-exit cellar-door-entry

Option 1: EXIT as a Tool

import { createExitTool } from "@cellar-door/langchain";

const exitTool = createExitTool();
// Add to your agent's tool array

Option 2: Automatic EXIT on Chain Completion

import { ExitCallbackHandler } from "@cellar-door/langchain";

const handler = new ExitCallbackHandler({
  origin: "my-app",
  onMarker: (marker) => {
    console.log("Departure recorded:", marker.id);
  },
});

await chain.invoke(input, { callbacks: [handler] });

Option 3: ENTRY Verification Tool

import { createEntryTool } from "@cellar-door/langchain";

const entryTool = createEntryTool({
  policy: { requireCooperative: true },
});

Python Too

pip install cellar-door-langchain

from cellar_door_langchain import create_exit_tool

exit_tool = create_exit_tool()

Building Departure Records for AI Agents

Warren Koch — Thu, 12 Mar 2026 19:16:48 +0000

AI agents are about to move between platforms the way people move between countries. They'll call tools on external services, get cloned across environments, migrate when platforms shut down. Every one of these transitions is invisible today.

No record. No proof. No audit trail.

I built the Passage Protocol to fix that: signed, portable departure and admission records for AI agents. Think passport stamps, but for software.

The Problem

When an AI agent leaves a platform today, nothing happens. There's no certificate of departure, no record of the conditions under which it left, no way for the next platform to verify where it came from.

This creates real problems:

Insurance can't price agent risk without departure history. If an agent causes damage, who's liable? The platform it came from? The one it's on now? Without records, this is unanswerable.
GDPR requires erasure proof when agents carry PII across borders. How do you prove data was properly handled during a transition that nobody recorded?
Incident response depends on conditions nobody tracks. Was the agent banned? Did it leave voluntarily? Was it an emergency evacuation?

This is the same problem global shipping solved decades ago. Point-to-point delivery works with simple rules. But a global supply chain with twelve handoffs needs bills of lading and chain-of-custody documentation. AI agents are at that inflection point now.

The Solution: EXIT + ENTRY

The Passage Protocol has two halves:

EXIT creates signed departure markers: a compact certificate that an agent left a platform, including why, when, and under what conditions.
ENTRY handles admission on the other side: verifying the departure record and applying local policy before granting access.

Each EXIT marker is just 7 mandatory fields, roughly 335 bytes. They're content-addressed, cryptographically signed (Ed25519, with a FIPS P-256 path), and verifiable offline years later without the origin platform being online.

Three ceremony types handle different scenarios:

Cooperative: both agent and platform sign. The standard path.
Unilateral: agent signs alone. For when the platform won't cooperate.
Emergency: immediate exit, one step, no waiting.

Show Me the Code

npm install cellar-door-exit

import { quickExit, quickVerify, toJSON } from 'cellar-door-exit';

// Create a signed departure marker
const { marker } = quickExit('did:web:platform.example');

// Verify it: works offline, works years later
const result = quickVerify(toJSON(marker));
console.log(result.valid); // true

That's the core loop. Create a marker, verify it anywhere. No network calls needed for verification.

For the admission side:

npm install cellar-door-entry

import { quickEntry } from 'cellar-door-entry';

// Verify a departure record and create an admission stamp
const entry = quickEntry(exitMarkerJson);
console.log(entry.admitted); // true

Framework Integrations

The protocol ships with integrations for the frameworks people actually use:

LangChain (TypeScript and Python):

import { ExitCallbackHandler } from '@cellar-door/langchain';

const handler = new ExitCallbackHandler({
  origin: 'my-app',
  onMarker: (marker) => console.log('Departed:', marker.id),
});

await chain.invoke(input, { callbacks: [handler] });
// EXIT marker created automatically when the chain finishes

MCP Server: expose EXIT/ENTRY as tools in the Model Context Protocol.

Vercel AI SDK, ElizaOS: drop-in integrations.

On-Chain Anchoring

For situations where you need immutable, publicly auditable records, the protocol supports anchoring markers on-chain via:

EAS (Ethereum Attestation Service)
ERC-8004 (identity and reputation)
Sign Protocol

This is optional. The protocol works perfectly fine off-chain. But when regulatory or compliance requirements demand it, the path is there.

Where This Stands

I'll be honest: this is day one. Zero users. Apache 2.0. The protocol was submitted to the NIST AI Agent Standards Initiative in March 2026.

The codebase has 14 repos, 1,401 tests across 13 packages in TypeScript and Python. It's been through extensive testing but no formal security audit.

I'm building this because I think the agent ecosystem is going to need departure records the same way international travel needs passport stamps. Not because agents are people, but because the complexity of multi-platform agent movement exceeds what informal tracking can handle.

Links

If you're building multi-agent systems or thinking about agent portability, I'd love to hear what problems you're running into. The spec is open, the code is open, and I'm looking for early feedback.

Why AI Agents Need Passport Stamps

Warren Koch — Thu, 12 Mar 2026 19:16:38 +0000