Where an MCP server belongs on a corporate network
- AI Security
- On-Premise
The problem MCP solves is clear: put the tools behind one standard interface instead of writing a separate integration per agent. On a corporate network it genuinely lowers integration cost.
It is worth remembering what you are standing up, though. An MCP server is, by definition, a service with programmatic access to internal systems. Where it sits on the network turns out to matter more than which tools it exposes.
Next to the resource, not next to the agent
The arrangement that comes to mind first is putting the server where the agent runs. Easy, and close to the wrong side.
With the server next to the resource, credentials stop travelling the network - it already runs in the zone that has access. The access log also stays at the point nearest the resource.
What is left on the agent's side is one connection. Break that connection and the agent holds nothing. That turns out to be more reassuring than it sounds.
The identity belongs to the request
The most common mistake is handing the server a single broadly privileged service account. Then every action appears under the same identity and two questions go unanswered: who asked for this, and were they allowed to.
Authority has to come from the context of the request. If the agent is acting on a user's request, the device group it can reach is bounded by that user. If it is running inside an unattended flow, authority comes from the narrow scope defined for that flow.
The server does not make this call itself. It validates the context that arrives and enforces it.
The tool list leaks too
We were slow to notice this one. An MCP server hands the connecting client its tool list - and that list is a map of internal systems.
Which services are managed, which environments exist, what has been automated. All readable from tool names and descriptions.
So the list gets filtered by authority as well. A client sees only what it can use. A tool it cannot see is, for that client, a tool that does not exist.
Separating reads from writes
The most useful decision in practice was not putting read and write tools on the same server.
Read tools can be broad: querying inventory, reading logs, checking state. Misuse is cheap and the agent needs them constantly.
Write tools live on a separate server, in a tighter zone, behind stricter authorisation. Access to the read server is continuous; access to the write server is tied to the task.
That puts the distance between "the agent can read something" and "the agent can change something" at the network level rather than the prompt level.
The logging side
MCP calls differ from ordinary API calls in one way: the caller is a model, and the reason for the call does not appear in the log.
We attach the identifier of the triggering incident to every call. From an action on a machine you can walk back to the incident, the plan and the step that produced it.
Without that link, the server's logs amount to a record that someone did something.
Using MCP on a corporate network looks like an integration decision and is a network design decision. Briefly: keep the server next to the resource, derive authority from the request, and keep reads and writes apart.