security(mcp): the HTTP/SSE transport has no per-client authentication — one shared credential for every caller

Provenance

Surfaced by a simulated panel — not user research. This finding was raised by modeled personas (.claude/personas.md) reasoning from domain knowledge. No user was interviewed, surveyed, or observed. It is filed on its own merits, verified below.

Raised by the panel and verified against the code.

Raised by

Theo (AI-Native Technical Operator); also relevant to Nadia (Integration/API Developer).

Finding

The MCP server's stdio transport (its default, spawned as a local subprocess next to the caller's own client) is fine for Theo's own workflow: one token, one local process, no shared surface. The HTTP/SSE transport is documented as authenticating the server to TruePPM with a single embedded token, with no client-side authentication at all — anyone who can reach that endpoint reads as the token's owner. This blocks a team-shared MCP endpoint (several teammates pointing their own MCP clients at one deployed server) without either sharing one identity or standing up one server per person. It is not a violation of any hard NO for Theo's own single-user stdio path, but it is a real gap for a self-hosted org that wants to offer MCP as a shared internal service, and it is short of the OAuth 2.1 + PKCE convergence the wider MCP ecosystem is adopting for exactly this deployment shape.

Falsification line

Falsified if no self-hosting operator attempts a shared/team HTTP-SSE MCP deployment in the 0.4/0.5 beta window. Confirmed if an operator reports hitting the no-client-auth limitation while trying to stand up one shared MCP endpoint for a team.

Code-level verification

Checked against main at b518fd0c0 (2026-09-05):

  • packages/website/src/content/docs/administration/mcp-server.md — stdio is the documented default (local subprocess); the HTTP/SSE transport is documented as having no client-side authentication, with the embedded token authenticating the server process itself.

Proposed improvement

Add per-client authentication to the HTTP/SSE transport — at minimum, one MCP token per connecting client rather than one shared server-level credential — so a self-hosted org can run one MCP endpoint for a team without collapsing every caller into one identity. A full OAuth 2.1 + PKCE flow is the fuller answer if/when a broader remote-MCP story is scoped; this issue is the narrower per-client-token step.

Acceptance criteria

  • The HTTP/SSE transport can authenticate each connecting client with its own token, distinct from any other client's
  • administration/mcp-server.md documents the shared-deployment path and its auth model
  • No change to the stdio default, which stays the recommended single-user path