Open connect tier

Connecting any MCP server into The Cloud — the superhighway. It ships when containment is real (egress broker plus credential vault), not when we trust the servers. The gate, and its sequence, stated honestly.

Read as Markdown

Open connect tier

Today, connecting a service into The Cloud goes through the curated Tools catalog — first-party providers we wired and vouch for. That is the safe on-ramp. The destination is the open tier: point The Cloud at any MCP server and connect it, the way a browser visits any URL without anyone reviewing the site first.

The web did not scale because someone reviewed every page; it scaled because the browser contained what a page could do to you. The open tier scales the same way — and we will not pretend otherwise.

Gate

The gate — open is gated on containment, not on reviewing servers

Reviewing every server is just curation that does not scale. Open ships the day containment is real, not the day we trust the servers — we never trust the servers, we contain them. No open connection ships before the egress broker and credential vault exist, and these docs will never claim otherwise.

The honest delta

Curated MCP means The Cloud is the server and outside AIs are clients calling our own classified tools. The open tier inverts the arrow: The Cloud becomes a client of a server you nominated. Three things that are free today become the whole problem:

Unknown blast radius. An arbitrary server's tools are not in our safety partition — we cannot pre-classify them.
Output is attacker-controllable. A server's response is untrusted text that re-enters an AI's context — it is data, never commands.
Credentials and egress. The server may need a secret and may want to reach the internet — the two things the sandbox flatly denies today.

The sequence — containment first

Open follows the curated catalog, strictly after the containment runtime exists. In order:

Extract the containment spine Lift the Studio broker, capability vocabulary, and permission model into one shared module both Studio apps and external servers project onto. Same gate, two transports.
Egress broker + credential vault The gate. A server-side outbound choke point — allowlisted, budgeted, logged — and a per-connection encrypted vault that injects secrets at call time so the model and the server never see a raw credential. Nothing open ships before this exists.
External-server connections + deny-by-default grants A connection record per server, near-zero default scope, widened per capability by the owner. Server output is framed as data at the result boundary, never merged into the instruction channel.
Connect any server by URL The actual superhighway entry — paste an MCP endpoint, maximum-friction consent, most-contained tier. Safe because it is the most contained, not because it is reviewed.

Trust tiers, terms, kill switch

Trust tiers. Verified, community, and unverified. A higher tier earns less friction — never wider reach without consent. Containment holds regardless of tier.
Platform, not guarantor. Provider terms place responsibility for a server's behavior on its operator; The Cloud orchestrates the bytes safely and takes a clear platform role.
Kill switch. Per-connection revoke exists today; a global quarantine and abuse-reporting path harden the tier as it opens.

Meanwhile, connect any client to The Cloud today on the Connect INTO The Cloud path.

Open connect tier

Gate

The gate — open is gated on containment, not on reviewing servers

The honest delta

Unknown blast radius. An arbitrary server's tools are not in our safety partition — we cannot pre-classify them.

Output is attacker-controllable. A server's response is untrusted text that re-enters an AI's context — it is data, never commands.

Credentials and egress. The server may need a secret and may want to reach the internet — the two things the sandbox flatly denies today.

The sequence — containment first

Open follows the curated catalog, strictly after the containment runtime exists. In order:

Extract the containment spine Lift the Studio broker, capability vocabulary, and permission model into one shared module both Studio apps and external servers project onto. Same gate, two transports.

Egress broker + credential vault The gate. A server-side outbound choke point — allowlisted, budgeted, logged — and a per-connection encrypted vault that injects secrets at call time so the model and the server never see a raw credential. Nothing open ships before this exists.

External-server connections + deny-by-default grants A connection record per server, near-zero default scope, widened per capability by the owner. Server output is framed as data at the result boundary, never merged into the instruction channel.

Connect any server by URL The actual superhighway entry — paste an MCP endpoint, maximum-friction consent, most-contained tier. Safe because it is the most contained, not because it is reviewed.

Trust tiers, terms, kill switch

Trust tiers. Verified, community, and unverified. A higher tier earns less friction — never wider reach without consent. Containment holds regardless of tier.

Platform, not guarantor. Provider terms place responsibility for a server's behavior on its operator; The Cloud orchestrates the bytes safely and takes a clear platform role.

Kill switch. Per-connection revoke exists today; a global quarantine and abuse-reporting path harden the tier as it opens.

Meanwhile, connect any client to The Cloud today on the Connect INTO The Cloud path.