Support organization-shared and user-owned MCP connections

Describe the problem you want to solve

An organization needs to combine two connection ownership modes:

• organization-shared connections authenticated once with a company identity;
• user-owned connections where each member completes their own provider OAuth, so upstream actions are attributed to the actual human.

Today a connection and its single downstream token are organization-scoped. Creating duplicate personal connections is possible operationally, but the product has no first-class ownership/visibility contract for them, and Virtual MCP/Agent composition cannot express shared children plus same-user private children safely.

This matters for providers such as Linear, Stripe, Supabase, and support systems where per-human attribution and revocation are required.

Propose your solution

Add a backward-compatible access scope to concrete and VIRTUAL connection rows:

type ConnectionAccess =
  | { scope: "organization"; user_id: null }
  | { scope: "user"; user_id: string };

• Existing and omitted values default to organization.
• A user-scoped connection remains a distinct row with the existing one-token-per-connection model.
• Ordinary members discover/manage their own private rows plus shared rows; owner/admin retains an audited recovery path.
• A user-scoped Agent may aggregate organization-scoped children and same-owner children. An organization Agent may aggregate organization-scoped children only.
• Personal OAuth completion is bound to the matching authenticated human and connection; service keys can reconcile sanitized status/disconnect but cannot complete human OAuth.
• API keys require explicit entry on the requested connection/Agent plus exact child tool/resource/prompt actions.
• Keep caller-facing storage method signatures stable by applying visibility once at request-context construction, backed by SQL predicates.

The change should include real-Postgres visibility/mutation tests and black-box denial coverage for management, OAuth, direct MCP entry, cache behavior, Agent composition, discovery, and delegation.

Compatibility

• No per-user downstream-token table is required.
• Existing organization connections continue to behave as they do today.
• The feature can be delivered in additive, independently reviewable layers so each part is easy to audit and revert.

No files or entry points are named. Start by locating concrete and VIRTUAL connection rows and request-context construction, then trace visibility, OAuth, MCP entry, caching, Agent composition, discovery, and delegation. Done means additive access-scope layers with real-Postgres visibility and mutation tests plus black-box denial coverage.