An IPsec tunnel that drops for a moment every half hour easily costs an engineer a morning: pulling logs, laying the phase 2 settings on both sides next to each other, checking whether an MTU problem sits underneath. A language model can do that groundwork, but only if it can look into your environment itself instead of waiting for your copy-paste. For that there is now an open standard, MCPMCP Model Context Protocol: an open standard that lets an AI assistant use data and functions from other systems, such as your network or your Odoo database., and our AI inference can use it to call tools in your own network under your instructions. This article explains what that is, what the model may and may not do, and how that traffic flows without your firewall having to face the internet.
The misconception: a cloud chatbot with admin rights
The picture that comes to mind for many engineers: AI on your firewall means a chatbot somewhere in a cloud gets an admin login and signs in to your management interface over the internet. Understandable, because that is what the first demos look like. It is not how we set it up. What is actually there consists of four separate parts, each of which you can check on its own:
- A scoped account — a dedicated API account or token on your device, with read rights only, that you create and you revoke.
- A private path — the connection runs over a cross-connect or a private VRF, not over the public internet.
- A model in Ede — inference runs in BIT-2C, not at a party outside the Netherlands.
- A human who decides — the model investigates and advises; nobody applies a change without explicit approval.
Take one of those four away and you do indeed have the chatbot with admin rights. With all four you have a research assistant that cannot switch anything over.
What MCP is, and what it is not
MCP (Model Context Protocol) is an open standard, introduced by Anthropic in November 2024 and now widely supported, that describes which tools a model may call and what those tools return. An MCP server is a small piece of software that offers those tools and translates them to the API of the device behind it. For a FortiGate such a server talks to the REST API; for a UniFi Dream Machine Pro, to the UniFi Network API.
So the model does not see "a firewall" but a list of tools with a description: get the VPN status, return the last 200 lines of the event log, show the policies on this interface. It picks the ones it needs, reads the answer and requests the next one. That is the whole mechanism.
What MCP is not: a way to let a model manage things on its own. Which tools exist and with which rights is something you decide yourself, in the MCP server and in the account behind it.
Read-only, and a human decides
Our starting point is read-only. The model can retrieve configuration, logs, active sessions and statistics, and that is enough to answer most questions:
- Why does that IPsec tunnel flap? — phase 1 and phase 2 parameters on your side, dead peer detection, the timestamps in the log and whether it coincides with a DHCP lease or a WAN failover.
- Which policy blocks this traffic? — the order of the rules, which one matches first and what the log says about it.
- Which client is eating the bandwidth? — the session table and the per-client traffic statistics, sorted.
The answer is an analysis with a proposal, not an applied change. That is a deliberate choice, because a model can be wrong: it can misread a log or assume a cause that does not hold. A wrong analysis costs you a few minutes of checking; a wrong change on a firewall costs you reachability. If you do want the model to make changes, that is only possible if it has been agreed beforehand, with rights agreed beforehand, and only after a human has approved the concrete proposal.
A private path instead of an open port
The connection between the model and your equipment does not have to touch the public internet. If your equipment is in our data centre, or your network is connected to our fabric over a line of your own, the traffic runs over a cross-connect or a private VRF on our EVPN fabric. Your firewall gets no management interface on the outside; the MCP server reaches it over the private path and nobody else does.
That is the same idea as out-of-band management via WireGuard: a management interface should be unreachable for anyone who has no business there, and you arrange that in the network, not with a strong password. Here too you simply turn TLS on; a private path is no reason to leave API traffic unencrypted.
Least privilege and your own logging
The account the MCP server uses is a dedicated API account or token in your device, with read rights only and created by you. Revoking it is a single action on your side; you do not have to call us for it. As far as your firewall or controller logs API calls, what was requested and when is visible in your own environment under the model's account. On our side we do not store prompts; that is laid down contractually. The record of what the model requested therefore sits with you, not with us.
AI-driven investigation at Xyphen IT
Our AI inference in BIT-2C in Ede can call MCP tools in your environment when that is relevant; how you connect to it is on the technical page. Connecting a FortiGate or a UniFi Dream Machine Pro is routine work for us; for other equipment or software with an API we build them as custom work, in consultation. If your equipment is in BIT colocation or your network hangs off our EVPN fabric, we link it over a private path. And if you want not just a model that investigates but also people who follow it up, this sits alongside our NOC as a Service.
Want to know whether your equipment is suitable for this? Request a proposal or get in touch.