Skip to content
Hussh
Connect MCP

Connected Systems, user-controlled integrations under PCHP

User-authorized external integrations, their scoped consent contract, and deployment-specific custody limits.

Concept2 weeks ago

TL;DR: Connected Systems are user-authorized links to external applications under scoped consent. Their information and credentials follow the selected runtime's custody contract. An owner-controlled cloud pod is a deployment path; placement of every integration there and complete migration across paths remain to be verified.

Relations

Overview

Connected Systems links external applications, enterprise CRM systems, retail platforms, and productivity services to One through user authorization. The person should be able to see what is connected, what access was granted, and how to revoke it.

Current implementations include shared service paths and pod paths. Their storage, key custody, and audit behavior must be assessed per path and environment. A consent grant does not, by itself, prove that every connector runs inside a private pod or that every access produces a durable receipt.

Where Your Integrations Actually Live

The intended private agent architecture gives each person an isolated pod with persistent encrypted recovery state. An owner-controlled cloud project is one supported deployment target. Hussh-hosted pods are a separate target with their own custody conditions, and development pods are a validation environment. A reported owner-cloud deployment proves that path for a particular pod; it does not establish that every Connected System has moved there.

Today, integration paths can still use server-side service state and scoped requests. The person’s encrypted vault and pod working copy have separate roles. A service may handle readable information transiently to fulfill an authorized request, and provider processing has its own boundary. Custody and deletion claims therefore depend on the actual connector, selected runtime, and deployed configuration.

The target is owner-controlled information access, portable encrypted recovery, and a control plane that brokers scoped authority without becoming a second personal-information store. Each deployment must demonstrate its own key, storage, migration, and erasure behavior before it can make that custody claim. The source candidate reviewed on September 24, 2026 connects the owner’s encrypted connector settings to Chat and exact-call review. The unlocked client supplies a bounded, temporary configuration for enabled connectors; the server binds its reference to the owner and conversation and consumes it once. OAuth refresh tokens are excluded from this turn projection. An explicitly empty connector catalog prevents fallback to legacy custom registrations. This establishes source wiring, not verified custom remote OAuth or live connector acceptance.

The One Dashboard

The One Dashboard is the intended place to inspect Connected Systems and their consent grants. Its useful view includes the connected service, authorized scope and purpose, duration, and revocation state. Audit history should show completed access and action receipts where the owning path records them.

The dashboard can present grant metadata without displaying the underlying records. Whether it can show a complete access history depends on durable receipts from each connector path; that coverage remains an implementation and verification requirement.

Core Architectural Invariants

  1. Owner authority. Verify the person’s authority before reading or changing information. A connected service receives only the scope needed for the authorized purpose.
  2. Custody by deployment. Keep vault persistence encrypted and use the pod’s declared storage and key boundary. Owner-cloud, Hussh-hosted, and shared runtime paths have different custody evidence; do not infer the strongest guarantee from the existence of a pod.
  3. Scoped integration. Prevent open-ended synchronization across corporate and personal stores. The connector’s actual token, cache, and record placement must be checked at its service boundary.
  4. Audit and revocation. Record meaningful access and action receipts, support revocation, and verify downstream cleanup. Grant revocation alone does not prove immediate provider-token disconnection or deletion of every retained copy.

What This Means

Connected Systems should let a person connect a service, understand its access, and end that access. The private agent and owner-cloud pod are important parts of that direction. Current guarantees must be stated for the specific connector and deployment that has been verified.

Sources

  • Hussh Research Repository — current implementation and public development history.
  • Internal architecture review, 2026-09-23 — pod deployment paths, consent authority, connector state, and remaining custody evidence.