Shared MCP Hub: public release specification

Status: publication requirements baseline, November 4, 2026. Pilot implementation evidence updated November 5.

The first release of daedro-mcp-hub lets a person discover and use approved MCP services on shared infrastructure while keeping their profiles, credentials, inputs, jobs and results private. Daedro Secret is the separate credential management and delivery subsystem. It is not a standalone product prerequisite that customers must install or operate. Dedicated customer infrastructure, arbitrary uploaded MCP execution and the visual workflow editor are later phases.

This document supersedes earlier phase-one statements that require customers to run provisioning scripts, create infrastructure, paste hub administrator tokens or manage OpenBao. Existing private-pilot behavior remains documented as evidence, not the public release contract. The S3 pilot implements the first server slice. The publication gates below remain the acceptance contract for internet traffic.

1. Product outcome and scope

A new customer signs in, gets a personal workspace and default profile, selects an available MCP, connects their provider account when needed, authorizes the connection through Google Authenticator, and receives a real result. An MCP client can use the same connection under a revocable, scoped machine identity. The customer does not need to know what OpenBao, IAP, AppRole, Docker or unsealing means. Engineering documentation still explains these operator concerns.

The initial execution launch may include a smaller approved subset. A connection is not marked Ready until its real action and isolation checks pass. The rest stay visible with honest status and no nonfunctional Connect button. S3 is the first acceptance slice; transcription and video follow, then the rest of the reviewed inventory. Paid subscriptions, crypto and Google sign-in remain recorded future requirements; they do not bypass identity, privacy or seller-readiness gates.

2. Terms and ownership

3. User journeys

A. First connection

1. Browse categories and inspect a service without signing in. See what it does, whether it is available, whether it needs a personal credential and whether an operation can cost money or change external data.
2. Sign in using the supported passkey-based identity flow. Complete Google Authenticator enrollment in the browser: scan QR, verify code, record a recovery method. Do not ask for an OpenBao username or recovery-file password.
3. Receive a personal workspace and default profile automatically. Selecting Connect opens a profile-scoped form, not a deployment wizard.
4. Authorize the provider via OAuth where supported, or enter the required personal key in the dedicated secret form. The page names the destination, scope and intended MCP; it never assumes a global operator key is personal.
5. Review the exact secret/grant transaction and confirm with Google Authenticator. The secret module validates the challenge itself. Save only after both authentication and authorization succeed; never send a test request to the provider before this permission is established.
6. Run a bounded read-only check and see what was actually tested. Then perform the actual supported operation and receive its result. A capabilities check is not a transcription, a catalog card is not a deployment, and “success” without an operation/result is not completion.

B. Returning customer and profile changes

Passkey verification plus Google Authenticator establishes the customer session. The current workspace and profile remain visible. Each connection card shows status, allowed scope and last result. Profile switching changes the entire connection and run context. Starting an operation uses the server-resolved context, never a submitted identity claim. Signing out invalidates the customer session; an external client grant has its own explicit revocation control and lifetime.

C. Secret management

The Secrets section shows references, provider type, connection grants, version and rotation status, never saved values. Fresh Google Authenticator verification is required on entry to sensitive secret metadata. Every add, replace, rotate, delete, connection attachment/detachment, permission change, client-credential issuance and revocation is confirmed for that specific action. Reveal/export is not offered in V1. A wrong or expired code leaves the change uncommitted and provides a retry path without exposing values.

A single confirmation can cover a displayed atomic batch such as save key and allow this connection, but it cannot create a reusable “MFA passed” window for unrelated operations. Mutation proofs bind actor, session, tenant, profile, resource, action, expected version and a server-held canonical payload HMAC (including grant recipient, tools, resource scope, expiry and the entire batch) to a one-use challenge with a proposed maximum lifetime of 90 seconds. The six-digit code does not sign the action; the server enforces this binding. TOTP codes are rate limited. Accepted time-steps are tracked globally per authenticator, not just per challenge; step consumption, intent authorization and mutation are atomic. Conflicting changes require a new confirmation. Cancelled forms must not save credentials. Operator/support human actions obey the same per-action rule. Emergency factor recovery is a separately approved, audited procedure, not a silent bypass or an unrestricted operator route.

D. Automated execution

A user-approved connection grant permits machine reads only for its declared operation and resource scope. Workload identity obtains a narrowly scoped, short-lived lease; the runtime receives only the needed credential. This is not a human secret-management route and never changes grants. It does not ask a person for TOTP on every background call. Disabling a connection or grant blocks new admissions; in-flight behavior is explicit and bounded. Grants have a finite expiry and execution/usage budget; every machine secret read is audited. Missing authorization state or required audit persistence denies new access. A static provider API key does not become short-lived merely because the vault token is.

E. Connect an external MCP client

Choose the existing personal connection, then Connect client. Review the profile, allowed tools, resource scope, grant lifetime and usage budget. Confirm issuance with a fresh Google Authenticator action proof. Prefer a browser-led OAuth pairing; if a client token is required, deliver it once through the secure flow and never put it in a URL, logs or a reusable copyable public configuration. This initial delivery is distinct from reveal/export of saved provider secrets, which remains unavailable. The client receives Hub authorization, never the provider key. Revoke or replace the grant through the same action-gated flow; verify that revoked clients cannot execute or retrieve results.

F. Recovery and outages

Lost device/phone recovery is an explicit browser-led path with identity checks, notifications, bounded recovery proofs, factor revocation and audit. It must not silently downgrade two factors to an unverified reset. Operator vault recovery and customer account recovery are distinct. A second passkey and recovery code or equivalent approved method must be offered without creating another daily password. Recovery-code storage and enrollment must be tested, not just shown. Vault or identity-provider failure denies new secret access with a useful Unavailable state; no plaintext file fallback. Customer support instructions do not contain shell commands. Operator runbooks may.

4. Daedro Secret contract

OpenBao is a proposed implementation of storage and lease primitives, not the customer UI and not proof of these requirements. The current pilot does not meet this contract. MFA protects authorized access; it cannot make a compromised privileged host or authorized malicious MCP unable to see a credential it uses. There is no “unhackable” or zero-knowledge claim.

5. Shared execution isolation

Shared services may reuse capacity, code and public immutable models. They must not reuse another customer's process-global credential state, mutable client session, temporary directory, job namespace or cached result. Each adapter declares which model it supports: stateless per-request credential context, isolated per-run process/container, or upstream per-connection principal. This execution isolation may use containers on a shared worker; it does not imply a dedicated customer VM. Environment-injected credentials require a separate per-run process/container. A shared long-lived process is permitted only with verified per-request credential and authorization state and no cross-request mutation or cache leakage.

A provider-wide service key is allowed only for an explicitly platform-funded service whose user data still has enforceable ownership and quotas. It must never be substituted for a customer's personal account key. If upstream cannot preserve tenant ownership, build a reviewed isolation adapter or leave the MCP unavailable for shared use. A process-global environment variable must not be changed between concurrent tenants as credential switching.

Personal context (provider account settings, browser/session state, chat history, agent memory and connector caches) has its own scoped storage, ACL and retention policy. It is never kept in a singleton shared profile.

Every data path carries ownership: request admission, queue, retries, worker claim, provider session, upload/object key, job/result lookup, cache key, download URL, cancellation, deletion, audit and external client access. Random IDs and unguessable URLs are not authorization. Tokens must identify principals, not serve as stable data-owner IDs: credential rotation must not change ownership.

6. Real catalog and readiness

Two different inventories currently exist: 13 repository catalog contracts and 11 locally configured user MCP connections. They overlap; neither count is a count of publicly usable services. See inventory.

Every listing must declare catalog_id, version, provider, category, allowed tools, transport, deployment owner, credential mode, isolation mode, execution side effects, input/output contract, limits, data retention, readiness evidence and last check time. Track three distinct objects: public service availability, private connection readiness, and each run outcome. A rejected personal key must not turn the public service Offline. The connection card may show a permitted non-sensitive summary; secret versions/grants/details remain behind the metadata step-up. Service publication states are Listed, Needs setup, Offline, Verification failed, Ready and Degraded. Private raw error details are operator-only; the customer sees the affected operation and recovery action.

The primary release slice is: account A and account B each connect their own S3 account/bucket scope, list permitted buckets/objects, inspect metadata and obtain an authorized result through the Hub. Neither can list, guess, download, reuse or observe the other's credentials, connections or results, including under concurrency, restart, retry and credential rotation.

Transcription acceptance requires an authorized upload, bounded job submission, status, successful actual transcription and owned paginated result. Video must preserve this identity across delegation to audio. The provider destination and usage estimate must be disclosed before paid processing.

7. Observability, quotas and publication operations

Provide three views, not one unfiltered log: customer-owned run history, operator service health/capacity, and restricted security audit. Correlate by opaque run, connection and audit references. Track latency, error class, queue delay, saturation, quota rejection, worker lifecycle, vault health, auth failure and provider usage; never put raw inputs, outputs, credentials or high-cardinality personal identifiers in metrics labels. Traces must redact headers and bodies.

Per-profile/tenant admission limits cover concurrent calls, upload size, queue length, storage, runtime, external provider spend and replica resources. Reserve usage atomically before admission, reconcile actual cost and handle unknown provider completion without retrying billable work blindly. Billing alerts are not a spend cap. Public shared workloads need protection against noisy neighbors.

The target budget remains $50/month with headroom, using available trial credit without automatic paid upgrade. A final topology, recurring run schedule, variable provider costs, backups, telemetry retention and egress allowance must be costed before deployment. The approved private test window ends November 12, 2026 at 10:43:33 Asia/Ho_Chi_Minh for Secret access and 10:43:36 for the VM. Laptop-owned tunnels support the private preview. Public service requires a stable domain, trusted HTTPS, health monitoring, automated restart/unseal and a verified restore path. See operations assessment.

8. Publication gates and evidence

Public traffic cannot be enabled merely because builds pass. Each enabled MCP must have adapter-specific evidence. Independent review does not guarantee the absence of vulnerabilities; it is a release control in addition to tests.

9. Implementation order and decisions pending

1. Review this product boundary, entity model, isolation and per-action MFA requirements; resolve contradictory legacy docs.
2. Select the maintained identity stack and recovery method; design the trusted first-owner bootstrap. Passkey + Google Authenticator is the desired customer experience. Device binding, synchronized passkeys and recovery must be described honestly; no MAC-address authentication.
3. Implement tenant ownership and the independent secret API before connecting real multi-user traffic. Establish KMS/restore and operator access separately.
4. Deliver the complete S3 two-user vertical slice and UI results.
5. Extend the same ownership contract through audio and video jobs, then onboard the remaining catalog by reviewed adapter readiness.
6. Meet the publication gates, cost the deployment and then publish the approved shared subset. Dedicated private infrastructure is a separate later proposal.

Unresolved implementation decisions: IdP/hosting topology, exact recovery policy, public availability target, data-retention defaults, provider-funded vs BYOK services, user/provider spend ceilings and initial published subset. These are not a request for the customer to design infrastructure; the working group must propose concrete choices with tradeoffs before implementation.

Supporting reviews: security architecture, user experience, operations.