DEV Community

FusionAL
FusionAL

Posted on

An unauthenticated MCP server on an internal network is still an open door

"It's only reachable from inside" is a common reason to skip authentication on an MCP server. I understand it. The server is a small helper, the network is private, and the goal is to get a workflow running.

But an internal network is not a single trusted person. It is every laptop, every script, every browser tab and every tool that can send a request to that address.

What an open server actually allows

An MCP server with no authentication will answer whoever asks. It does not know if the caller is the assistant you set up, a teammate's test script or something that wandered onto the network. It lists its tools to any client and runs them when told to.

Whether that matters depends on the tools. A server that only returns the office holiday calendar is a small problem. A server that can read a shared folder or send a message is a different one.

A hypothetical example

This is a demo scenario, not client work. Say a small team builds an assistant that drafts replies to internal support questions. A person reviews each draft before it goes out. The assistant uses an MCP server with two tools: search the team's help articles, and read a ticket by ID.

The workflow is sound. The human review is real. But if the server is open, anyone on the network can call "read a ticket" directly. They skip the assistant and skip the reviewer. The review step protected the output, not the access.

Checks for one workflow

Pick the one workflow that uses MCP and look at these:

  • Does the server require a credential, and is it tied to a person or a named service?
  • Does it listen only on the interfaces it needs, not on every address?
  • Are the tools limited to what the workflow uses? A lookup does not need write access.
  • Can you see who called what?

None of these is exotic. Most take an afternoon for a single server.

Make the handoff understandable

The result should fit on one page. It should say what the server exposes, who can reach it, what was changed and what is still open. Someone who did not build the workflow should be able to read it and know where things stand.

Not every team needs a formal audit. If your workflow does not use MCP, none of this applies. If it does, and the server is open because the network is "internal," that is worth an hour of attention. Privacy and security duties apply to internal tools too, whether or not the work is regulated.

I run FusionAL, and checks like these are part of how we review a single workflow before it is relied on.


I'm Jonathan Melton. I run FusionAL, focused on reviewing and integrating lower-risk internal AI workflows, one bounded workflow at a time.

Top comments (0)