The first time an MCP (Model Context Protocol) server felt real to me, it wasn't because of a clean demo. It was because of the noise.
TL;DR: The harness matters more than the protocol, and the evidence matters more than both. MCP earns its keep when it shortens the path from a good security question to trustworthy evidence, and almost everything interesting about making that work happens in the harness wrapped around the model. In this series, I will cover how to build an MCP for an AI SOC.
Empowering your SOC with AI requires more than just deploying agents. You need to have a way to keep accountability and continue availability. This final chapter covers some of the difficulties of agent management, from establishing guardrails to capturing practical value. I also share a few final takeaways.
This chapter includes:
MCP doesn't remove the need for governance. It adds another layer that has to inherit the governance of the systems underneath it. And the bar you actually need scales with who's using it.
On one end, we have single-operator mode. The LLM client and MCP server both run on your box: one user, one identity, and you're the only person who can see the traces. The risk profile is basically "Don't run queries you don't understand." Light-touch controls are fine.
On the other end, we have a multi-user enterprise: multiple analysts, multiple permission levels, traces that can contain sensitive log content, and code-mode execution hitting production data. It is a different game entirely. You need OAuth or equivalent identity layer so every prompt, query, and action can be attributable to a named human. You need trace storage under the same access controls as the underlying logs, because a trace from an EDR query is effectively a copy of that EDR data. You need retention policies that line up with whatever compliance regime covers the source systems. You need audit logging that survives the agent self-modifying its own code. Service accounts should be scoped, not shared. Authentication and authorization flow from source systems and should not be re-implemented at the model layer. Prompt injection through ingested logs is a real threat in a SOC MCP, because your input surface is hostile by design.
Code mode needs its own line. A disposable Docker container with scoped network access is the floor, not the ceiling. You also need a kill switch that actually works when the model is mid-loop, a record of every execution for later audit, and a clear answer to "Who owns the blast radius if this goes wrong." "It's in a container" is not a governance answer.
There's a knowledge ceiling on every AI-assisted investigation, and it's set by your evidence, not your model. If the telemetry doesn't exist, the smartest model in the world can't reason past what isn't there. Invest in the data first. Everything else rides on top of it.
Before asking whether your team needs MCP, answer these questions first:
Good first use cases are narrow and read-heavy:
These are enough to prove value without pretending the system is ready to take irreversible action.
Whatever the use case, the output has to show its work. If the system can't explain what it queried, what fields it used, what it assumed, what evidence supports the conclusion, and what a human should review next, it doesn't belong in a SOC. The goal isn't to replace the analysts. It is to take the tedious retrieval off their plates without hiding the evidence, to speed up the boring pivots, to show them the query, and to help newer analysts learn the shape of an investigation instead of just allowing them to paste an answer.
The hard part of agentic SOC analysis is not the front end design. The hardest pieces are context, retrieval, constraints, evaluation, and adoption.
You need schemas the model can actually use. You need just-in-time lookup so you aren't stuffing every field into the prompt. You need golden answers for regression. You need live-data testing to catch what the golden set will never show. You need a security model around traces. You need to decide when code mode is allowed, what it can reach, and how disposable the execution environment is.
Here are a few quieter lessons worth sharing:
If both sides are implemented properly, a well-designed MCP server can be just as token-efficient as a CLI tool, and a well-designed CLI tool can be just as controllable as an MCP server. That's the clean version.
In practice, a lot of MCP servers in the wild are bloated. Tool descriptions balloon the context window, context rot sets in, and the model gets less accurate. That's why there's real momentum from the Claude Code and open-harness side toward CLI-style tools. The CLI pattern has been beaten into shape for decades, and the discipline of "one command, one job, predictable output" maps cleanly to what an agent needs.
My working rule now is to pick the one that gets the result with the right controls, and don't treat it as one-or-the-other. CLI, MCP, or both in the same stack are all valid. Don't choose based on ideology, choose based on where the user already is and what you can actually keep bounded.
And yes, you'll see "MCP is dead" takes in the feeds. They're early, but they aren't wrong about the failure mode. The fix isn't the protocol debate, it's workflow-layer discipline on whichever side you land on.
This is n=1. One team, one environment, one set of data sources, and a mix of senior professionals under unusual conditions. The numbers are data points, not benchmarks. Non-determinism is real. Run the same prompt against the same data twice and you'll see variance. Most of the value here is in the patterns, not the numbers.
If I were starting this from scratch today, I wouldn't begin with "let's build an AI SOC" as my goal.
I'd pick one workflow where the pain is already obvious, make it read-only, give it good schema access, encode the core investigation concepts, and test it against known data where I already have the answers. Then, I would test it against live data and watch where it breaks. Keep the human in the loop. Show the query. Show the evidence. Track the misses. Improve the harness.
That's the path that made MCP useful for me. Not because MCP is magic, but because the right workflow moves a human from question to evidence faster. Three things carry the weight, and they carry it in this order:
Get those in the right order and the results compound.