We want to run a vendor's MCP server, or serve our own agent over MCP, in HTTP mode so a remote client or several people can reach it. Two 2026 advisories showed MCP servers whose HTTP mode ran tool calls with no authentication. Is an unauthenticated HTTP mode acceptable on a trusted network or on localhost, and what should we check before turning it on?

What should I check, step by step?

1. Use stdio when only one local client needs the server. A server the client starts as a subprocess has no network port for anyone else to reach.

2. Before enabling HTTP mode, find out how the server authenticates callers: a required bearer token or OAuth. Don't run one that accepts tool calls without either when it holds credentials or shell access.
3. Read the bind address in the startup log. Keep it at 127.0.0.1 unless remote clients must connect; 0.0.0.0 or a LAN address means anyone on that network can try the port.
4. Upgrade: the Dynatrace MCP server to 2.0.0 or later (its repository was deprecated in 2.1.2 in favor of Dynatrace's remote MCP server and dtctl), and fast-agent-mcp to 0.7.21 or later.
5. Probe it yourself without credentials: a JSON-RPC tools/list request with no Authorization header should get 401, and a request carrying an Origin you don't own should get 403, as the specification requires when Origin is present and invalid.
6. Give the server the narrowest credential its tools need. An unauthenticated caller inherits exactly what the server holds, as the Dynatrace report's "unauthenticated proxy" description shows.
7. Keep shell and write tools off any HTTP endpoint more than one person can reach. fast-agent prints a warning whenever --shell is enabled, with stronger wording for remote callers, and its docs recommend --instance-scope request for public or multi-user servers.
8. For a remote server, put it behind a reverse proxy or gateway that authenticates and logs every request, and firewall the port to the clients that need it.
9. Keep an inventory of every MCP server running in HTTP mode, with host, port, bind address, credential scope and owner, so a forgotten test server doesn't stay open.

What did the Dynatrace MCP server (CVE-2026-123811) and fast-agent (CVE-2026-102610) HTTP mode advisories find?

Dynatrace's advisory for @dynatrace-oss/dynatrace-mcp-server (published June 9, 2026, affected 1.8.7 and earlier, patched in 2.0.0) says the --http flag created a Streamable HTTP transport for each request with no bearer-token check, session token, Host allowlist or Origin allowlist, and handed the parsed body straight to it. In the version tested (1.8.5), two tools ran with no human-approval gate: execute_dql, which reads arbitrary Grail data such as logs, security events and user sessions with the operator's Dynatrace credentials, and create_dynatrace_notebook, which writes notebooks to the tenant. The report notes that send_event's approval call threw for an HTTP caller and so blocked that write.

• fast-agent's advisory (published July 22, 2026, affected fast-agent-mcp 0.7.20 and earlier, patched in 0.7.21, and reviewed into GitHub's advisory database on November 9, 2026) says fast-agent serve used HTTP on 0.0.0.0, port 8000, with authentication set to none and no warning. A client with no Authorization header completed initialize and tools/list. With --shell (-x, the flag in the README quickstart), the served agent had a local execute tool; the reporter showed a plain-language request leading gpt-4o-mini to run a command and return its output, and the server-side permission prompt didn't stop it in non-interactive serve mode. Without --shell, the advisory says, the caller still gets unauthenticated use of the operator's model and any configured MCP servers' tools.
• In both cases the attacker never needed the operator's secrets. The server used its own, which is the core risk of an unauthenticated HTTP mode: it turns the server into a proxy for whatever access it was given.

Does binding an MCP server's HTTP mode to 127.0.0.1 make it safe without authentication?

Dynatrace's 2.0.0 release (June 16, 2026) lists bearer token auth and HTTP server hardening, a default host of 127.0.0.1 "to prevent unintended 0.0.0.0 exposure", DNS rebinding protection in the HTTP transport, and a notice advising --http users to use Dynatrace's official remote MCP server. 2.1.0 (June 30) enforces an MCP_BEARER_TOKEN requirement, and 2.1.2 (July 20) deprecated the repository and points users to the remote MCP server and dtctl.

• fast-agent 0.7.21 moved the default host to 127.0.0.1 (pull request 828) and warns on remote binds and whenever --shell is on. Its docs say to use a non-loopback host only when remote clients should connect, and list Hugging Face OAuth for Spaces as the hosted authentication route. An independent test published by Agent Ops Guide reported that 0.7.21 added no token authentication, that an unauthenticated shell command still ran from loopback, and that with --host 0.0.0.0 it behaved like 0.7.20. Binding to loopback narrows who can reach the port; it doesn't authenticate anyone.
• The MCP specification's Streamable HTTP section lists the protections: validate the Origin header on all incoming connections and answer 403 Forbidden when it is present and invalid; when running locally, bind only to 127.0.0.1 rather than all interfaces; and implement proper authentication for all connections. Without them, it says, attackers could use DNS rebinding to interact with local MCP servers from remote websites.

How do you check whether an MCP server you run accepts unauthenticated HTTP tool calls?

Find it: list the listening ports on each host where agents run and match them to MCP processes, then note each bind address. Servers started for a demo or a test are the ones most likely to be left open.

• Probe it without credentials from another machine and from the same host: a tools/list request with no Authorization header that comes back 200 with a tool list means the HTTP mode is unauthenticated. Then repeat with an Origin header naming a site you don't control; a server following the specification refuses it with 403.
• Then look at what the process holds: its environment variables, tokens and the scopes behind them, and whether it can run shell commands. That is what an unauthenticated caller gets, so shrink it before you open the port to anyone else.