Lonnie VanZandt (@lonniev) on X

What it claims

Secure Courier is a consent flow in Tollbooth DPYC. In it, each MCP service acts as its own authorization server. There is no shared server and no account directory. Lonnie VanZandt argues that this limits a breach to the grants one service issued, which expire or can be revoked. A central identity provider or a CIBA authorization server, by contrast, exposes every account it serves when breached. VanZandt calls CIBA "progress" and says the Tollbooth DPYC protocols are similar to it.

How it works

The thread describes these steps and the roles in them:

sequenceDiagram
    participant A as AI agent
    participant S as MCP service
    participant R as Nostr relays
    participant U as User's Nostr app
    A->>S: Act for npub (OAuth connection, no login page)
    S->>R: Sealed DM, signed with service key
    R->>U: Deliver (relays cannot read it)
    U->>U: Check service key in registry
    U->>R: Reply signed with nsec, plus expiry
    R->>S: Signed approval
    S->>S: Verify signature, issue own grant
    S-->>A: Grant stays encrypted in wallet behind connection

• Service identity. Each service has its own Nostr key pair, listed under its name in the Tollbooth DPYC community registry. The user checks the request's signature against that registry entry.
• Transport. The request travels as a sealed direct message, so public relays carry it without being able to read it.
• Agent connection. The agent connects to the service over "ordinary OAuth plumbing", with no login page and no consent screen. That connection proves nothing about the user until the user answers.
• The grant. The grant never leaves the service. It is stored encrypted in a wallet behind the agent's connection and bound to the npub. It expires on the date the user chose and is void on revocation. It records the user's own signature, so consent can be verified later.
• The code word. The request includes a code word. It only matches the reply to the request and unlocks nothing.
• Payment. Patrons buy "API Sats" in tranches over Lightning, outside the tool calls. Balances are tracked against npubs that patrons choose freely, with no PII, KYC or KYT.

How to use it

The code is open source under Apache 2.0, at a GitHub link the thread truncates (github.com/lonniev/tollbo…). Operators set prices in a Pricing Studio at tollbooth-dpyc.com. A technical write-up sits at a truncated cafe.tollbooth-dpyc.com/blogs link. The thread gives no install commands, API shapes or message formats.

Limits

• Patent. The project is marked "Patent pending (US Prov. App. No. 64/045,999)". Anyone building on the Apache 2.0 code should check how the licence's patent grant applies.
• No evidence. The thread reports no audit, threat model or implementation details. Its security claims are the author's own.
• Unspecified mechanics. The thread does not name the Nostr sealing scheme, describe the revocation mechanism, or say how the community registry is governed and kept trustworthy.
• Breach scope. The breach-containment argument assumes the user's Nostr app keeps the nsec safe. A compromised service can still misuse its own unexpired grants.
• Source. The post is promotional. It was published by Excalibur-MCP, a Tollbooth DPYC service.