[GH-ISSUE #5476] [Feature] Support authenticated access for non-loopback MCP HTTP deployments #3332

New issue

Open

opened 2026-10-31 00:39:15 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:39:15 +00:00

Owner

Originally created by @jayykernel on GitHub (Oct 20, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5476

Before submitting

I searched open issues for a related HTTP authentication proposal.
I removed credentials, tokens, private paths, and sensitive target data.

Area

MCP or agent integration

Current limitation

The documented rea mcp --http Streamable HTTP endpoint uses plain HTTP without TLS or client authentication. The default bind is loopback, but callers can explicitly bind a non-loopback interface, making the same tool catalog and active analysis state reachable at that address. The documentation warns that this should be used only in a trusted local or isolated environment.

This is a documented deployment limitation, not a claim that the default loopback setup is vulnerable. However, users who need access from another machine currently have no built-in way to require an identity-bearing credential at the MCP endpoint.

Relevant references:

docs/mcp-contracts.md, section Transports
src/server/http/serveStreamableHttp.ts, where Host/Origin validation is conditional on the listener's bound address

Host/Origin validation helps with request-origin checks but is not client authentication.

Proposed change

Add a documented, configurable authentication mechanism for non-loopback HTTP MCP deployments, such as a bearer token supplied through a protected configuration/environment mechanism. Prefer a fail-closed default for remote binds unless authenticated access is enabled, with any insecure override explicit and clearly named. TLS can remain the responsibility of a trusted reverse proxy if the project does not want to terminate TLS itself.

The implementation should avoid logging or echoing credentials and should authenticate requests before allowing session initialization or tool execution.

Acceptance criteria

Loopback-only use remains simple and behaves as documented.
A non-loopback deployment can require credentials; missing or invalid credentials cannot initialize an MCP session or invoke tools.
Valid credentials permit ordinary Streamable HTTP MCP initialization, notifications, tool calls, and session deletion.
Credentials are not included in logs, error messages, or returned Evidence.
Documentation explains the trust boundary and recommends TLS when requests cross an untrusted network.
Tests cover missing, invalid, and valid credentials and verify that unauthenticated requests do not disturb an existing authenticated session.

Scope note

This is a security-hardening feature request based on the currently documented transport behavior. It does not assert a demonstrated exploit, and remote use should remain limited to trusted or isolated environments until an appropriate protection layer is configured.

Originally created by @jayykernel on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5476 ### Before submitting - [x] I searched open issues for a related HTTP authentication proposal. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area MCP or agent integration ### Current limitation The documented `rea mcp --http` Streamable HTTP endpoint uses plain HTTP without TLS or client authentication. The default bind is loopback, but callers can explicitly bind a non-loopback interface, making the same tool catalog and active analysis state reachable at that address. The documentation warns that this should be used only in a trusted local or isolated environment. This is a documented deployment limitation, not a claim that the default loopback setup is vulnerable. However, users who need access from another machine currently have no built-in way to require an identity-bearing credential at the MCP endpoint. Relevant references: - `docs/mcp-contracts.md`, section **Transports** - `src/server/http/serveStreamableHttp.ts`, where Host/Origin validation is conditional on the listener's bound address Host/Origin validation helps with request-origin checks but is not client authentication. ### Proposed change Add a documented, configurable authentication mechanism for non-loopback HTTP MCP deployments, such as a bearer token supplied through a protected configuration/environment mechanism. Prefer a fail-closed default for remote binds unless authenticated access is enabled, with any insecure override explicit and clearly named. TLS can remain the responsibility of a trusted reverse proxy if the project does not want to terminate TLS itself. The implementation should avoid logging or echoing credentials and should authenticate requests before allowing session initialization or tool execution. ### Acceptance criteria - Loopback-only use remains simple and behaves as documented. - A non-loopback deployment can require credentials; missing or invalid credentials cannot initialize an MCP session or invoke tools. - Valid credentials permit ordinary Streamable HTTP MCP initialization, notifications, tool calls, and session deletion. - Credentials are not included in logs, error messages, or returned Evidence. - Documentation explains the trust boundary and recommends TLS when requests cross an untrusted network. - Tests cover missing, invalid, and valid credentials and verify that unauthenticated requests do not disturb an existing authenticated session. ### Scope note This is a security-hardening feature request based on the currently documented transport behavior. It does not assert a demonstrated exploit, and remote use should remain limited to trusted or isolated environments until an appropriate protection layer is configured.

bsakaguchi referenced this issue

2026-10-31 00:42:37 +00:00

[GH-ISSUE #5969] [Bug] JavaScript recovery reports a changed selected input as unreadable output #3638

bsakaguchi referenced this issue

2026-10-31 01:10:17 +00:00

[PR #3788] [MERGED] fix(javascript): reject FIFO recovery inputs without blocking #5900