Skip to content
Hussh
Connect MCP

PCHP — Personal Consent Handshake Protocol

Hussh consent protocol implemented today through Consent Protocol, Developer API, hosted MCP consent/export, and audit flows; future UI and rules-engine surfaces remain separate until proven.

Product

TL;DR: PCHP (Personal Consent Handshake Protocol) is Hussh's consent and scoped-export layer: SSH for humans.

Status as of 2026-06-12: see body.

Relations

The four primitives

PCHP composes four small artifacts into one consent handshake:

The user's signed statement: "I consent to scope X, for purpose Y, until time Z." Issued at the moment of consent, presentable to the user or an auditor, and revocable.

2. Data Access Token (DAT)

The capability the receiving party gets. Bound to a specific CRT — no CRT, no DAT. Includes scope, expiry, and the audit hooks. The receiver cannot widen scope without re-handshake.

3. Transparency Log

Every issued/revoked CRT and every honored DAT lands here. The user can reconstruct who saw what, when, why in one place. The audit truth belongs to the user's consent record, not to a partner CRM.

4. Ephemeral Envelope

For one-shot reads or partner exports, the data moves as a short-lived or encrypted envelope scoped to the approved request. This is what prevents "Kai composed a financial picture" or "a partner requested a CRM update" from becoming broad vault extraction.

Why SSH for humans

The analogy is more than marketing. SSH solved a specific problem: making remote-access negotiable, auditable, and revocable across an open network of mutually-suspicious machines. PCHP solves the same shape of problem one layer up — making personal-data access negotiable, auditable, and revocable across an open network of mutually-suspicious agents and services. The four primitives map to SSH's session keys / authorized keys / known hosts / connection log, with consent semantics replacing crypto-only semantics.

Founding principle

PCHP exists because consent should be a technical boundary, not a paragraph in a terms page. The principle is simple: if software reads private data, the user should know the scope, purpose, duration, and audit path before access is honored.

Adjacent positioning

  • PCHP is not OAuth. OAuth grants access; PCHP grants consent, with audit and revocation as first-class primitives.
  • PCHP is not OpenID/SSO. PCHP is about data flow, not identity assertion.
  • PCHP is not DRM. DRM enforces what the recipient can do; PCHP enforces whether the recipient can read at all, on the user's terms.

A useful framing for partner conversations: SSL/TLS for the AI agent economy — the neutral consent infrastructure all major model ecosystems need.

Repo truth and north-star boundary

  • Current implementation truth: PCHP is implemented today through the Consent Protocol, Hussh Developer API, hosted MCP consent tools, consent tokens, scoped exports, and auditable consent status flows. Offline & Local-First Support (Active): A robust air-gapped offline mode has been added (by setting DB_OFFLINE=1). When active, the db client (db_client.py) automatically builds a local SQLite database on first use, generating 20 real tables (such as consent_audit, consent_exports, pkm_, vault_, and runtime_) from an introspected Postgres DDL schema (offline_schema.sql). Request-consent and consent-status round-trips run over HTTP against the SQLite database with local reviewer-session bypass for Firebase authentication. Hussh Python SDK (hussh_sdk): Stabilized under consent-protocol/ to establish first-class client interfaces. The standard synchronous tool-calling and execution runtime (agent.py, factory.py) implements .know() (Nav-gated vault reads), .remember() (consent-gated vault writes), and .do() (one-tap user confirmation) to ensure all data interactions pass strictly through PCHP boundaries, with non-interactive credential validation and token resolution via VaultCredentialResolver and PKMCredentialResolver. Redesigned Consent Connector UX: Features a redesigned consumer-friendly consent connector UX, accompanied by an active agent icon directly in the search bar. Priced-Consent Offers / Bids (Reverse-Auction): Shipped end-to-end on 2026-06-12 (commit 17f6eb7e2). The PCHP request_consent payload now natively accepts an optional offer object carrying bid_amount, currency, offer_summary, and settlement_ref. The bid amount rides directly inside the consent request metadata (audited) and is surfaced in responses so the user's agent (ONE/Nav) can evaluate against their reserve price policy. Settlement is handled downstream at the money boundary (using AP2 Payment Mandates), keeping the consent protocol strictly for clearing/authorization without touching regulatory payment rails.
  • North-star direction: PCHP remains the trust handshake for human and agent requests, including future enterprise partner lanes.
  • Not shipped / not implied: partner gateways, CRM systems, data-cloud systems, or agent platforms do not replace Hussh consent, scope validation, vault context, or audit authority.
  • Evidence boundary: backed by offline mode schema and bootstrap scripts, first-class SDK files, and redesigned consent connector UX merged and current as of 2026-06-11.

Sources