MCP is the new interface for security tools

In the past few months, Model Control Protocol (MCP) servers have slowly been gaining in popularity. But this week, something incredible happened — we hit an inflection point. Three different people I know built MCP servers for interacting with security tools since Sunday. One did it in just 20 minutes. I expect I’ll hear about another one by the end of today.

MCP is an open protocol, originally developed by Anthropic, that allows models to interact with external tools and systems. It’s another interface, like an API — and it’s opened a whole new realm of possibilities. MCP implements tool calling, but provides a common format (with a spec) for the industry to connect agents to tools, with an understanding of what the tool does and how to use it. It’s a standard that lets you expose a tool’s capabilities — so you can build agentic systems that call different agents in order to access specific information or use specialized knowledge. Even though MCP is open, most people I know use it with Claude (and generally only really use Claude). OpenAI recently already added MCP support as well, in a desperate bid to continue to be relevant (or am I the only one who doesn’t see the enterprise value of Ghibli-style images?).

Security teams stand to benefit enormously from MCP for three key reasons:

1. Security is fragmented: We have dozens of tools generating alerts, logs, and findings. MCP can pull this disparate data together without custom development.

2. Not all security professionals code: Many security analysts and leaders aren’t engineers who can code. MCP bridges this gap, allowing non-technical users to get the insights they need through natural language.

3. Security drowns in data: Everything in security needs context. Only data engineering deals with more information volume — but those folks already know how to query it effectively.

This is a complete rethinking of how we interact with security tools. This reminds me of Tines, which rethought how we create workflows for security tools. Tines is a general-purpose connector, but its entrypoint to the market was in security because the pain of tool fragmentation hits us hardest.

Using a model with MCP servers doesn’t only give you a way to ingest, analyze, visualize — and so understand — information, but also to act on it. You can take actions, such as create a new group, or ack an alert. Users will absolutely not realize the power of this and accidentally perform sensitive actions, like delete their account. But the potential is there to simplify a lot of complex security work.

The “single pane of glass” vendors have been promising for years will finally arrive, but it won’t be another dashboard. An MCP-enabled client becomes the front end of choice, with an LLM building custom visualizations on demand for whatever specific question you have. This is more than just an evolution of a Slackbot, it’s fully custom to your specific user needs. You don’t need an enterprise- or security-specific agent. You just need an MCP-enabled agent — and to control what it has access to.

If you’re building security tools, your job isn’t UI anymore — it’s data and interfaces. Products selling just “visibility” will face a reckoning as LLMs become the interface. In the past few months, users have built MCP servers for security tools they use, such as Ghidra, VirusTotal, Keycloak, Snyk, Trivy, and many many more. But in the last few days, vendors have realized the value and already come out with MCP servers, like at RunReveal and Semgrep. We’re seeing the same evolution we saw with unofficial versus official Terraform providers.

Remote MCP servers are even more exciting because they don’t require local deployment — they allow your local client to connect with web-based servers (like those provided by your security SaaS tools). Squint and this looks like service-to-service communication.

This allows us to actually build agentic workflows. What if the model received an alert, automatically investigated it, and took a remediation action? I know this is what we’ve all been talking about, but now it’s possible. It’s something we could incrementally add to our existing stack.

The security of these MCP servers will be critical. MCP servers must use OAuth 2.1 for authentication and authorization — well, if they implement any auth at all 🥲. We’ll also need audit logs and approval flows.

The challenge isn’t just implementing MCP — it’s also figuring out how to properly implement user prompts for OAuth (which I’ve written about previously) and approvals for sensitive actions. And, managing these at scale, when every employee in your environment has a slightly different set of permissions and access.

MCP is poised to fundamentally transform security operations, turning LLMs into the interface of choice for your security stack.