Security MCP Servers: What They Are, and What a DNS One Changes
by Serena Raymond on Sep 17, 2026, 4:24:47 PM
A user reports a site they cannot reach. An alert points at a device, and you want to know what else that device was doing that afternoon. Neither question is hard. What takes time is the reconstruction: Opening the query log, setting a filter, narrowing the time window, switching views, and holding the whole thread together in your head while you do it.
A security MCP server removes that step. It lets an AI assistant read from a security tool directly, so an investigation becomes a question you ask directly instead of a sequence of clicks inside a dashboard. The DNSFilter MCP Server does that for your DNS data.
What a security MCP server actually is
Model Context Protocol, or MCP, is an open standard for connecting an AI assistant to a system it can read from and act on. A security MCP server applies that standard to a security product, exposing that product's own data and controls to the assistant under the permissions of the person who signed in.
That is the part that separates it from an API. Our API has been there since the beginning, and it is the right tool when you are building something durable: a pipeline, an integration, a scheduled job. A security MCP server is for the other half of the work, the questions you ask once. You add a server URL to your assistant, sign in, and start asking questions.
In practice, a security MCP server is useful for three jobs:
- Investigating an event that already happened
- Producing detailed reports
- Making routine administrative changes that would otherwise mean a trip into the console.
Why DNS is the data worth connecting
A security MCP server is only as useful as the data behind it, and DNS has three properties that make it unusually good raw material for this.
DNS is the record that answers the question a ticket actually asks. Why was this allowed or blocked, for this person, on this device, and what else was going on around it? Until now, that was a question you answered by working the filters yourself. With the connector, you ask it, and the assistant does the searching.
It is also the earliest record. Nearly every connection starts with a name lookup, before the connection completes and before anything is downloaded, so DNS captures the attempt itself, including the ones that were never completed. You see what a device tried to reach, not only what it managed to do.
Finally, it is also the broadest, and it is consistent. Every device resolves domain names the same way, whether it is a managed laptop, a contractor's machine, or hardware that runs none of your software. One record, one format, across the whole environment, so an investigation reads as a single timeline instead of a stitch of whatever each device happened to be running.
Filtering acts at the lookup; Behavior Analytics explains it
Filtering is a decision, not a report. A real-time call on every lookup: This one resolves, that one does not, based on the policy you set and what our intelligence knows about the domain at that moment. It lands before the connection exists, and it happens millions of times a day without anyone watching.
What reaches your desk is the decision after that one. Should this stay blocked? Did this person need what they were attempting to access? Is this device behaving oddly, or is that normal for this team? Those are judgment calls, and judgment needs context.
Behavior Analytics, a capability of DNSFilter CyberSight, is that context: Which applications, which processes, how often, at what hours, and on which machine. Filtering decided at the lookup. Behavior Analytics tells you what was happening around the lookup, so you can decide what to do next.
Until now, making that second decision meant assembling the evidence yourself. One view for the block, another for the behavior, and the connection between them held in your head. Through the connector you ask once and get both, then decide with the whole picture in front of you instead of half of it.
We already have customers who trialed our MCP Server in our beta finding value specifically pulling DNS and CyberSight data together in a single query:
"I found immense value in being able to pull DNS data and CyberSight data. I was able to search in natural language and have it pull data back for an incident that I worked."
— Jeremy Schwarzrock, CCSP, CISSP, Manager of Information Security, Titan Machinery
What changes day to day
Investigations take one pass, not several. The first question is the easy part. What a console never gives you cheaply is the second question, the one that occurs to you because of the answer to the first. Through a connector, the follow-up costs nothing, so you keep pulling the thread instead of deciding it is not worth the clicks.
Your DNS data sits alongside everything else. Because MCP is an open standard rather than a proprietary integration, an assistant can hold DNS evidence next to whatever else in your stack exposes its own MCP server: Your endpoint tooling, your asset inventory, your IT management platform. You are not standardizing on our console. You are making our data available to the way you already work.
“This is much easier to search with and helps correlate all my other data sources that have MCP servers such as SentinelOne, LanSweeper, and ManageEngine. I can quickly put together a picture of what happened and my threat hunting has vastly improved. Searching hasn't always been the best for me in the console, so this has changed the game for us."
— Jeremy Schwarzrock, CCSP, CISSP, Manager of Information Security, Titan Machinery
Anyone on the team can get an answer. Getting a precise answer out of any reporting tool is a learned skill, and it fades if you use it occasionally. Asking a plain-language question does not. That matters most for the people who touch DNS reporting a few times a month rather than every day.
You can hand work down without widening access. The connector runs under the permissions of whoever signed in, so it can see and do exactly what that person can. Handing the blocked-domain queue to a junior tech does not mean handing them more of the console.
How DNSFilter MCP Server access is scoped
Connecting an AI assistant to a security product is a reasonable thing to be careful about. The constraints below are the reason it is safe to do.
- Reporting is read-only
- Every change pauses for your explicit confirmation in the conversation before it runs
- Access follows the permissions of the signed-in user, so the connector can see and do exactly what that person can
- Your organization's privacy setting is applied when the session starts and cannot be overridden or bypassed through the connector
- Reads and writes are both logged and attributable to the authenticated user
- Only endpoints approved for AI access are reachable, so no other API surface is exposed.
- Scope covers reporting, policy, and day to day administration
- Setup is admin-only in the DNSFilter app
- The connector is added inside your AI assistant, so it is subject to whatever rules your organization already applies to connectors there
- Requires re-authentication every seven days
How to connect it
In the DNSFilter app, open Integrations and find the DNSFilter MCP Server card under AI Connectors. Open the card, copy the server URL, and add it to your assistant as a custom connector. Sign in with your own DNSFilter credentials and approve access.
Setup takes about five minutes, is admin-only, and involves no API keys and no service account. Full steps are in the MCP Server setup guide.
Frequently asked questions
What is a security MCP server? A security MCP server is a connector that lets an AI assistant read data from, and take action in, a security product using the Model Context Protocol. It runs under the permissions of the person who signed in, so the assistant can see and do exactly what that user could do in the product directly.
What is the difference between an MCP server and an API? An API gives you access. What you do with that access is yours to build: The code that calls it, the logic for what to pull, and somewhere for the results to land, whether that is a SIEM, a dashboard, or a scheduled report. You own and maintain that integration.
An MCP server delivers the data into the AI assistant directly. The assistant discovers the available operations when it connects and calls them when your question requires it. There is no integration to write and no pipeline moving your data into another tool first.
What can a DNS MCP server tell me that my other tools cannot? DNS is the earliest and broadest record of what a device tried to reach. Nearly every connection begins with a name lookup, including connections from unmanaged devices and hardware that cannot run an agent. That makes DNS data the place where services nobody registered and tools nobody installed still show up.
Can an AI assistant change my filtering policies? Yes, if you have the permissions to make that change yourself and you confirm it. Reporting capabilities are read-only. Every administrative change, including policy edits and block list updates, pauses for your explicit confirmation in the conversation before anything runs, and each change is logged and attributable to you.
What stops the assistant from seeing data it should not? Three things. Access follows the signed-in user's own permissions. Your organization's privacy setting is applied when the session starts and cannot be overridden through the connector. And only endpoints approved for AI access are reachable, so no other part of the API surface is exposed to the assistant.
Which AI assistants does the DNSFilter MCP Server work with? Any MCP-compatible assistant. Claude and ChatGPT have both been connected. Because MCP is an open standard, your DNS data can be correlated with any other tool in your stack that exposes its own MCP server, which is where much of the value shows up in practice.
Do I need CyberSight to use it? Only for the Behavior Analytics capabilities. DNS reporting and administration work without it. The connector checks for an active CyberSight entitlement when you sign in, and if your organization does not have one, those capabilities are simply not available in the session. CyberSight is included starting with our Plus plan.
How far back does the data go? Thirty days, for both DNS query log data and CyberSight data. That is the working window for investigations and reporting through the connector.
How much does it cost? Nothing additional. The MCP Server is included with eligible DNSFilter plans at no extra cost. See pricing for what is included with each plan.
Try it
The connector is live now. Open Integrations in your DNSFilter dashboard, or talk to our team if you want to see it against your own data first.
SecureTransit for MSPs: Digital Privacy Without Another Tool to Manage
MSPs need to boost client security without sacrificing efficiency or margin. Every extra tool, console, or license just adds overhead and slows down service delivery.
Privacy is a classic example. Clients want their remote and hybrid users protected from the networks they connect through and the trackers profiling them, but most solutions add another siloed tool and more operational work.