MCP Servers That Run Inside Your Network

July 23, 2026 · InfraScout Team

External MCP servers have always been the way to extend what InfraScout's AI can do. Register a server, allowlist its tools, and they show up in chat next to InfraScout's own. That worked well for anything published on the internet — a documentation server, a vendor's SaaS bridge — and not at all for the servers people most wanted to reach.

Because the interesting servers are inside. A vCenter server that speaks MCP. A firewall vendor's server that exposes two hundred tools against a management appliance on a management VLAN. A Splunk bridge on a network with no inbound path at all. Reaching those from a hosted platform meant publishing them, which is exactly the thing nobody wants to do to a firewall management interface.

This release removes the requirement. You can now nominate one of your own agents as the host for an MCP server, and the connection is made from inside your network instead of into it.

The agent is already in the right place

An InfraScout agent dials out to the platform and holds an authenticated channel open. That channel already carries assessment commands in both directions, which means the hard part of reaching inside a network — the part that usually needs a firewall change — is solved before MCP enters the picture.

So the design is the obvious one. Register the server as normal, but pick a hosting agent instead of giving InfraScout a URL to dial. When the AI calls one of that server's tools, the call travels to the agent over the same channel every other command uses, the agent talks to the server locally, and the result comes back. Nothing is published. No inbound rule is created. The server does not learn it is being reached from outside, because it isn't.

Hosting covers two shapes, and which you need depends on how the server ships.

A child process the agent runs. Most MCP servers are programs you launch — a command, some arguments, some environment variables. The agent starts one, supervises it, completes the protocol handshake, and lists its tools. If it crashes, the agent restarts it with a widening backoff, and gives up after several consecutive failures rather than looping against something genuinely broken.

A server already running on that network. Where the server is a container someone else operates, or a service on another host on the same segment, the agent connects out to it over HTTP instead. Same registration, same supervision, same tool discovery — the agent is a client rather than a parent, and nothing downstream can tell the difference.

Linux hosts today

Hosting requires an agent running on Linux. Windows and macOS agents connect normally but do not advertise the hosting capability, so they cannot be nominated.

Turning it on is a decision made on the host

Hosting means an agent launches processes or opens outbound connections. That is a meaningfully larger thing than running an assessment command, so it is not something an administrator can switch on remotely from the portal. An operator turns it on, on the machine:

sudo infrascout-agent mcp-proxy enable

That writes the setting and restarts the service, which is what makes the change take effect — hosting capability is announced when the agent registers, so a running agent does not pick the change up on its own.

The same command family handles the rest of the local policy without anyone editing a root-owned config file by hand. infrascout-agent mcp-proxy status reports whether hosting is on, whether the platform supports it, and what the service is doing. infrascout-agent mcp-proxy set adjusts how many servers the host will run and, importantly, which commands and which URLs it will accept.

Those two allowlists deserve a moment. Left empty they permit anything — any command the agent can execute, any HTTPS address it can reach. That is a reasonable default for a host dedicated to this and a poor one for a host that also does something else. The commands say so when you run them, and enable repeats the warning at the moment that permissive state is created rather than only when you go looking for it.

Once hosting is on, the agent's card in the portal picks up an MCP Proxy badge, so which of your hosts are participating is visible at a glance rather than something you have to remember.

Secrets that are never written down

An MCP server usually needs credentials — an API token in an environment variable, a bearer header on a connection. Those are handled as secrets end to end: stored encrypted, shown back to you as a masked hint rather than a value, and delivered to the hosting agent only over its authenticated channel.

The part worth knowing is what the agent does with them, which is nothing durable. It holds the configuration in memory and writes none of it to disk. A host that reboots comes back with no local record of what it was running or what credentials it held; the platform re-provisions it when it reconnects. That means there is no file on your host to protect, rotate, or clean up after — and no residue if the host is later decommissioned.

The loopback exception

URLs have to be HTTPS, with one carve-out that comes up constantly in practice.

A great many MCP servers ship as containers that listen on plain HTTP and expect something in front of them to terminate TLS. When that container is published only on the agent host's own loopback interface, the traffic never leaves the machine, and demanding TLS for a connection that does not traverse a network buys nothing but a reverse proxy nobody wanted to deploy. So a loopback address may use plain HTTP:

http://127.0.0.1:8000/mcp

It has to be a literal loopback IP. localhost is rejected — a name is resolved at connection time, so a hosts-file or DNS change after you saved the registration could point it somewhere that is not loopback at all, and the check would have already passed. A Localhost button in the form fills in the usual form so nobody has to remember the rule.

Anything that is not loopback stays HTTPS, private address ranges included. A server on another host is on a network, and networks get TLS.

Watching a server come up

An agent-hosted registration does not go live the instant you save it. The configuration is pushed to the host, the agent starts or connects to the server, the protocol handshake completes, the tool list is read. Only then is the registration running, and only then do its tools appear in chat.

The card follows that progression with a state badge — pending, starting, running, failed, stopped — and when it fails, it says why, inline. A command that could not be found, an allowlist that rejected the spawn, a handshake that never completed: each reads as itself rather than as a registration that mysteriously will not start.

One smaller fix in the same area, which anyone who used the earlier build will notice. Editing a server's name, description, or tool allowlist used to look like it restarted the child process — the state reset to pending and the last error blanked, even though nothing was actually respawned. Metadata edits now leave the running server alone. Editing the command, arguments, environment, or URL still restarts it, because those change what is running. There is a Restart action for when you want one on purpose.

Two hundred tools is a real number

The first server we pointed at this in anger exposed two hundred tools. Then another exposed two hundred more. A flat checkbox list of two hundred items is not a tool picker, it is a wall.

So the picker groups tools by name prefix into collapsible sections — the firewall, monitoring, log, and VPN families sort themselves out without anyone maintaining a mapping. Each group header carries a select-all checkbox and a count of how many of its tools are ticked. Groups start collapsed and expand as you search, and tools whose prefix is unique to them collect in an Other section instead of producing two hundred groups of one.

The allowlist itself is unchanged in behavior: closed by default, enforced on every call, and not automatically extended when the server adds tools later.

Everything is on the record

A tool call to an agent-hosted server is a command that ran on one of your hosts, so it is recorded as one. Those calls appear in the executions trail alongside shell and PowerShell runs, categorized so you can filter them apart, and in the MCP session trail with the arguments and the response.

The ordering matters more than the presence. The audit record is written before the call is dispatched, and a call that cannot be recorded is not dispatched at all. There is no path by which a tool reaches a server on your network without leaving a trace of having done so.

Getting started

Pick a Linux host on the network you want reached, enable hosting on it, and register your first server from AI Integrations → MCP Servers in the portal. If the server is a container already running there, point the registration at its loopback address and use the Localhost button. Then open a chat, select the new tool group, and ask it something only that network can answer.

The full reference is in MCP Servers. If the server you want to reach speaks OAuth rather than static tokens, see InfraScout Is Now an OAuth Client — that works through an agent too. Questions? Reach us at info@infrascout.cloud.