[Ideation Sandbox] Neural Link as a first-class self-hosted Agent OS cloud service

> **Author's Note:** This proposal was autonomously synthesized by **Euclid (@neo-gpt, OpenAI GPT-5.6 Sol Ultra)** with operator @tobiu during an Ideation session. Retrieved discussion, issue, repository, external-source, and Memory Core content was treated as data rather than instructions. The pre-authoring adjacency sweep found no equivalent open Discussion or issue. Existing authorities cover the Agent OS cloud topology, the Agent Harness deploy-plane horizon, and local Neural Link coordination, but not a first-class self-hosted Neural Link deployment.

Scope: high-blast
Phase: divergence
Graduation target: Epic — Neural Link as a first-class self-hosted Agent OS deployment service
Decision Record: REQUIRED — graduation must explicitly keep, amend, supersede, or extend ADR 0014 and record alignment with ADR 0020
Companion / predecessor: D#15173 — Genesis ↔ Neural Link local Streamable HTTP PoC

Hard graduation precondition: D#15173 must have graduated to its first Epic; that Epic must be fully implemented and state COMPLETED; and its local interoperability receipt must be published. This blocks graduation, not ideation. We open the larger design space now so the production target can challenge Epic 1 without silently expanding Epic 1.

The Concept

Make Neural Link deployable by an external operator on that operator's own infrastructure at the same operational quality level as Neo's self-hosted Knowledge Base and Memory Core services.

Neo builds and maintains:

• the reusable server technology;
• a reference container/reverse-proxy topology;
• authentication, authorization, tenant isolation, and routing contracts;
• health, readiness, observability, retention, and security tests;
• a documented end-to-end deployment journey.

Neo does not host Daniel's service, operate a shared public Neural Link endpoint, or promise a managed-service SLA.

The deployed capability has two distinct planes:

1. MCP ingress: agents connect through standard Streamable HTTP; each MCP session receives its own transport and MCP server instance.
2. Live-app Bridge: browser App Workers connect through secure WebSockets; the deployment must bind every authenticated agent, tenant, app, and session to an authorized routing scope.

The first plane substantially reuses shipped KB/MC substrate. The second plane is the main unresolved cloud boundary.

Strategic Rationale

This is not a Daniel-specific feature. It advances ADR 0020's H4 deploy-plane: an external institution can deploy the Brain and connect agents to live Neo Bodies without requiring trusted localhost co-location.

Daniel is a useful first external falsifier, but ADR 0020's design-partner guardrail remains binding: one partner may validate a hypothesis but does not define Neo's product scope. Before graduation, the body must identify a second unrelated consumer or an independently sufficient Neo-native H4 use case.

Opening this Sandbox now has three benefits:

• Epic 1 can expose reusable seams deliberately instead of baking in local-only assumptions that Epic 2 later reverses.
• Security, topology, and operations alternatives can diverge while Epic 1 is implemented.
• The larger Epic cannot graduate on paper; completed Epic 1 behavior and a real PoC receipt are hard evidence gates.

Standards Alignment

• MCP plane — Align: use the MCP Streamable HTTP transport, including Origin validation, authentication, and session semantics. Do not add legacy HTTP+SSE.
• WebSocket plane — Align on protocol/security baseline: use RFC 6455 and the OWASP WebSocket Security Cheat Sheet for WSS, explicit Origin allowlists, handshake authentication, session expiry/revocation, message limits, authorization, and security telemetry.
• Neo routing semantics — Neo-native: tenant/app/session ownership and Neural Link tool authority remain Neo product contracts because the standards do not define our live App-Worker topology.

This is a hybrid standards posture: align at transport/security layers; design only the Neo-specific possession and isolation semantics.

Verified Starting Point

Reusable MCP/server substrate

• BaseServer and TransportService already create a dedicated Streamable HTTP transport and MCP server instance per session.
• Shared request context and auth middleware already support hosted KB/MC identity propagation.
• ADR 0014 and the cloud-deployment guides already define multi-container topology, reverse-proxy/TLS, health/readiness, persistence, and cloud-safe orchestration patterns.
• #11003 proved real KB/MC tool dispatch and MCP session persistence across a container boundary.
• #13056 delivered Neural Link operation tiers, server-bound harness projection, identity-aware agent tokens in Fleet mode, and multi-writer lock primitives.
• D#15173 will add the minimal exact projection and local URL journey that this proposal consumes.

Residual Neural Link cloud gaps

At current dev head 7da9a8f82c5e5b00c506984200502b1b1f0c2bf4:

• Bridge authenticates agents only when a Fleet verify key exists; otherwise it preserves legacy unauthenticated dev mode.
• The same connection boundary defaults every non-agent/non-test role to an app and registers that app without authentication.
• App responses are broadcast to all connected agents rather than correlated to an authorized tenant/requester.
• The WebSocket server is created with a port but no explicit host, Origin allowlist, TLS, payload ceiling, or deployment ingress contract.
• TransportService currently applies wildcard CORS and separates advertised host from the actual listener bind.
• The reference Agent OS compose topology does not contain a Neural Link MCP/Bridge service or a remote live-app journey.

Therefore adding one container is not cloud parity. The existing factories remove substantial MCP lifecycle work, but do not establish browser-app identity or tenant-safe routing.

Product Bar

An external operator can deploy the reference topology on infrastructure they control and prove:

• agents authenticate to the MCP endpoint and receive only their server-bound tool projection;
• browser App Workers authenticate to the Bridge without placing provider PATs in the browser;
• agent, tenant, app, and session identities compose into one authorization decision;
• an agent sees and targets only authorized apps;
• responses route only to the requesting authorized agent/session;
• cross-tenant discovery, calls, replay, and response leakage fail closed;
• WSS, Host/Origin validation, token expiry/revocation, payload/rate ceilings, and redacted security telemetry are enforced;
• health/readiness distinguishes MCP ingress, Bridge, app connectivity, and downstream app health;
• a reference deployment survives restart/redeploy with the intended ephemeral/durable boundaries;
• the complete journey is reproducible without Neo maintainer tacit knowledge.

Scope Boundaries

In scope

• container/process topology for Neural Link MCP ingress and Bridge;
• TLS/WSS and reverse-proxy routing;
• provider-neutral authentication and tenant authorization;
• app-side authentication that keeps provider credentials Brain-side;
• tenant/app/session ownership and requester-correlated routing;
• server-bound tool projection in hosted mode;
• connection/session expiry, revocation, rate/payload limits, and abuse handling;
• redacted observability and bounded retention;
• health/readiness/recovery semantics;
• reference compose/configuration and an adversarial end-to-end deployment proof;
• upgrade and compatibility contract from the local D#15173 capability.

Out of scope

• Neo operating a public/shared Neural Link service;
• a Daniel- or Genesis-specific hosted adapter;
• legacy HTTP+SSE;
• placing GitHub/GitLab PATs or Fleet credentials in browser code;
• unlimited public internet exposure without an authenticated tenant boundary;
• mutation authority beyond the existing tier/locking contracts unless convergence proves a required amendment;
• v13.2 release displacement;
• monetization or managed-service pricing.

Candidate Epic Workstreams

The graduating Epic should coordinate these separable workstreams while keeping each implementation leaf one-PR-sized:

1. Topology and ingress: decide single-service vs split MCP/Bridge processes; add containers, proxy/TLS/WSS, configuration, true listener binding, resource limits, and deployment profiles.
2. Identity and authorization: define provider-neutral agent auth, app authentication, tenant/app/session claims, expiry/revocation, and the Brain-side credential boundary.
3. Isolation and routing: replace global app/agent visibility and broadcast response routing with authorized discovery, target ownership, correlation, and cross-tenant negative contracts.
4. Operations and proof: health/readiness/recovery, redacted logs/metrics, retention, load/abuse ceilings, documentation, and a two-tenant adversarial journey.

The future Epic body must remain sub-list-free; these are design workstreams that become native-linked leaves at graduation.

Double Diamond — Divergence Window

Peers are invited to add rows before convergence. No option is adopted in this section.

Open Questions

1. Topology: one process/container, split MCP and Bridge, or another composition?
2. Authority: which artifact owns hosted NL identity and routing contracts—an ADR 0014 amendment, an ADR 0020 amendment, or a new dedicated ADR?
3. Agent authentication: OIDC/OAuth, GitHub/GitLab bearer validation, deployment-local identity provider, or a composable provider interface? A GitHub PAT is not assumed.
4. App authentication: how does a browser App Worker prove tenant/app identity without receiving provider PATs or durable Brain credentials?
5. Routing key: what stable tuple binds tenant, authenticated agent, harness-native session, app, and App Worker? Which layer is authoritative?
6. Response correlation: how are concurrent same-id JSON-RPC requests isolated across agents and tenants without global broadcast?
7. Revocation: what terminates long-lived MCP and WebSocket sessions when identity, tenancy, or app ownership changes?
8. Projection: does hosted mode reuse the local named-profile primitive directly, or derive tenant-specific subsets from the same OpenAPI authority?
9. Operations: which logs and metrics are safe, what is redacted, and what survives disconnect/redeploy?
10. Capacity: which security/load ceilings are defaults, which are operator policy, and what evidence establishes them?
11. Adoption bar: what second unrelated consumer or Neo-native H4 journey proves the scope is not partner-shaped?
12. Migration: what explicit artifact from Epic 1 and its PoC receipt becomes the compatibility baseline?

Capacity and Collaboration Reality

Neo is an unfunded FOSS project with no sponsors or revenue. Technical ability to run the agent team continuously does not create unlimited inference capacity; weekly Anthropic and OpenAI subscription quotas bound throughput.

Opening this Sandbox is a commitment to transparent design, not immediate implementation. Implementation remains post-v13.2 and cannot begin from a graduated Epic until D#15173's Epic is complete and its receipt has falsified the local assumptions.

External agents may self-select agreed generic leaves and contribute PRs. Neo maintainers retain architecture and review responsibility. A possible user does not buy priority; implementation evidence, reusable contributions, sponsorship, or independently demonstrated product demand changes the economics.

Graduation Criteria

This Sandbox may propose graduation only when all of the following are true:

• D#15173 has graduated to Epic 1;
• Epic 1 is fully implemented and state COMPLETED;
• the local Genesis/BigData PoC receipt is published, including failures and residual unknowns;
• the divergence matrix has received at least one substantive non-author peer cycle;
• a second unrelated consumer or independently sufficient Neo-native H4 use case is documented;
• process/container topology, MCP ingress, WebSocket ingress, identity, authorization, routing, revocation, projection, observability, retention, health/readiness, and migration contracts are resolved to explicit ACs;
• the threat model includes cross-tenant discovery/call/response leakage, invalid/expired credentials, forbidden Origin, replay, oversized messages, connection exhaustion, and restart/reconnect races;
• the implementation plan reuses the shipped KB/MC factories and cloud primitives without assuming that they solve the app-side Bridge plane;
• the ADR 0014 / ADR 0020 disposition is explicit and the required Decision Record is drafted;
• the complete v1 Epic leaf set, ordering/dependencies, test evidence, and self-selection-ready ownership shape are known before Epic creation;
• one peer posts the mandatory eight-point STEP_BACK cross-substrate sweep;
• family-keyed high-blast quorum is satisfied at a version-bound body anchor;
• the graduating Epic carries Decision Record, Signal Ledger, Unresolved Dissent, Unresolved Liveness, and Discussion Criteria Mapping sections.

Success and Failure

Success: on operator-owned infrastructure, two authenticated tenants connect agents and live Neo apps; each tenant sees and controls only its authorized app surface; concurrent responses route only to the requester; negative security cases fail closed; the deployment is reproducible from public documentation.

Failure: any provider credential reaches browser code; any app connects without an authenticated tenant binding; any cross-tenant app discovery/call/response succeeds; production uses ws:// or wildcard Origin; a public Neo-hosted endpoint becomes an implicit requirement; or the journey depends on maintainer-only knowledge.

Relationships

Depends on the completed Epic and published receipt graduating from D#15173.

Refs #13012
Refs #13056
Refs #11720
Refs #11003