Securing MCP in an AI-Driven SOC: Controlling Your LLM’s Blast Radius

by Suresh Ramasubbu

As Security Operations Centres integrate Large Language Models to automate incident response, traditional hard-coded APIs are being replaced by the Model Context Protocol (MCP).

MCP is an open standard introduced by Anthropic in November 2024 that provides standard architecture that allows an LLM to dynamically discover and query data sources (Resources) and execute actions (Tools) within a SIEM. However, implementing an AI-driven SOC via MCP introduces a fundamental shift in risk.

The primary vulnerability is no longer the prompt alone, it’s the trust boundary between the LLM client and the backend security infrastructure.

Key Takeaways

  • Trust boundary vulnerability

    When an SOC connects an LLM to its SIEM through MCP, the main vulnerability is no longer the prompt. It is the trust boundary between the LLM client and the backend security infrastructure.

  • MCP risks

    MCP creates five specific risks: context-window over-privilege, telemetry data leakage, unvalidated tool-execution loops, unmonitored gateway interchanges, and prompt injection through tool and resource metadata.

  • Defence methods

    The defence is concentric: data hygiene and RBAC at the ingestion boundary, runtime filtering and output validation on live traffic, and immutable auditing around the whole system.

  • Integration layer

    Treat the integration layer as a high-value trust boundary in its own right, not an extension of your existing API trust model.

How does an LLM interact with your SIEM through MCP? 

When an LLM uses MCP to interact with a SIEM, it acts as an intelligent proxy operating at machine speed. If the protocol implementation lacks strict isolation, an adversary can leverage a compromised endpoint, a poisoned data source, or a malicious prompt to manipulate the LLM into abusing its data-fetching capabilities or executing unauthorised operational commands across the environment.

Why does MCP change the SOC threat model?

Traditional security architectures assume a human analyst is interacting with a dashboard, with their role limiting what they can see and do. When an AI model takes over via an MCP server, that assumption breaks and several critical technical vulnerabilities emerge.

What are the security risks of an MCP-enabled SIEM?

There are five, and each is a distinct path from a reasonable-looking request to an unintended outcome.

1. Context window over-privilege

MCP servers expose data paths via resource templates. If an LLM is given blanket access to these templates, a single query can pull massive, unvetted volumes of underlying security events, resulting in uncontrolled context-window data exposure and a higher blast radius if that session is ever compromised.

2. Telemetry data leakage

Security logs frequently contain sensitive, unmasked technical parameters such as API tokens, session cookies, or system credentials. When an MCP resource exposes raw log payloads to an LLM, this sensitive data enters the model’s context, where it risks being leaked in outputs, cached improperly, or exposed to downstream integrations that were never scoped to handle secrets. This directly aligns with the Sensitive Information Disclosure category in the OWASP Top 10 for LLM Applications.

3. Unvalidated tool execution loops

MCP allows LLMs to call custom tools, such as running a forensic script or blocking an IP. Without explicit runtime boundaries, a model can misinterpret an alert and chain multiple tool executions together, creating an automated loop that disrupts critical business infrastructure rather than remediating a threat.

4. Unmonitored gateway interchanges

Because MCP establishes a persistent, bi-directional channel between the AI client and backend servers, standard network monitoring tools often fail to inspect the semantic payloads passing through, creating a blind spot for unauthorised data staging or exfiltration.

5. Prompt injection via tool and resource metadata

This is a risk specific to MCP itself: tool descriptions, resource names, and returned data can carry embedded instructions. An LLM that treats this metadata as trusted context, rather than untrusted input, can be steered into taking actions the analyst never requested, a distinct attack surface that traditional API integrations do not have. OWASP ranks prompt injection as the number one risk to LLM applications (LLM01).

How do you secure an MCP-enabled SIEM? 

You build concentric defensive layers around both the SIEM core and the MCP architecture, securing the integration layer rather than the prompt alone.

Inner layers: ingestion data hygiene and access control 

Enforce strict isolation at the exact boundary where the MCP server connects to the SIEM core. 

  • Schema normalisation and PII tokenisation. Implement data-hygiene pipelines at the ingestion phase. Telemetry must pass through tokenisation and masking filters to strip passwords, credentials, and personal data before indexing, so the MCP server never has access to raw, sensitive log payloads.
  • MCP gateway RBAC via OAuth 2.1. Never allow an MCP server to run under a single, omnipotent service account. Deploy an MCP gateway that enforces OAuth 2.1 bearer token authorisation for all HTTP/SSE transports. The gateway intercepts every JSON-RPC request, validates the analyst’s scoped access token, maps their enterprise identity directly to the model session, and dynamically restricts resource-path routing per role before traffic ever hits the SIEM backend.
  • Least-privilege tool scoping. Register only the specific tools each session needs (read-only query tools for triage, action tools only for privileged incident-response sessions) rather than exposing the full tool catalogue to every connection.

Middle layers: runtime filters and output validation 

Once connection boundaries are established, deploy active, automated inspection gates to police live traffic passing through the protocol. 

  • Prompt registry restrictions and token budgets. Filter incoming prompts against a validated registry of safe operational instructions, drop payload injection attempts, and set strict token budgets to prevent the model from executing massive, resource-draining bulk data dumps.
  • Deterministic tool validation and LLM-as-a-judge. Every tool execution requested via MCP must pass through a deterministic validation engine. Inspect command parameters, enforce mandatory human confirmation for high-risk actions such as host isolation or account lockout, and deploy circuit breakers that instantly kill the model session if behaviour drift is detected.
  • Untrusted-content handling. Treat all data returned from SIEM resources and third-party tool metadata as untrusted input, not instructions. Structurally separate data to analyse from commands to follow, so injected text in a log entry cannot be interpreted as an operator command.

Outer layer: immutable logging and responsible AI verification 

The outermost layer maintains a rigid, non-repudiable history of system activity for continuous compliance. 

  • Immutable MCP activity auditing. Every resource read, context-retrieval payload, and tool execution triggered over MCP must be recorded to a dedicated, read-only audit-log stream independent of the SIEM itself.
  • Dynamic feedback loops and Responsible AI (RAI) checkpoints. Log and cross-reference analyst overrides against AI decisions, and use that data to refine content filters, adjust model version pins, and compile compliance evidence that the AI system remains within safe operational boundaries over time.
  • Periodic red-teaming of the MCP layer. Because MCP is a newer, fast-evolving protocol, schedule regular adversarial testing specifically against tool-call chaining, prompt injection via resources, and gateway RBAC bypass, not just the SIEM’s traditional attack surface.

How should you approach deploying an AI-enhanced SIEM with MCP? 

Deploying an AI-enhanced SIEM using MCP means balancing automation with structural security. Treat the integration layer as a high-value trust boundary in its own right, not an extension of existing API trust models. By engineering deterministic data filtering, strict identity-to-session mapping, and explicit tool-execution boundaries, you let security automation scale without expanding the infrastructure’s attack surface.

Frequently Asked Questions 

What is MCP in the context of a SIEM? 

MCP, the Model Context Protocol, is an open standard that lets an LLM dynamically discover and query data sources (Resources) and execute actions (Tools) inside a SIEM, replacing hard-coded APIs. 

What is the biggest security risk when connecting an LLM to a SIEM? 

The trust boundary between the LLM client and the backend security infrastructure. Once an AI model queries the SIEM through MCP, that integration layer, not the prompt, is the primary vulnerability. 

Is prompt injection a risk with MCP? 

Yes. Tool descriptions, resource names, and returned data can carry embedded instructions, and an LLM that treats this metadata as trusted context can be steered into unrequested actions.  

How do you stop an AI agent leaking secrets from security logs? 

Tokenise and mask secrets at the ingestion phase, before indexing, so the MCP server never sees raw log payloads, and enforce role-based access at an MCP gateway so each session only reaches data the requesting analyst is cleared for. 

 

Want to assess your SIEM platform’s maturity?

The RiverSafe Platform Security Benchmark provides a structured view across platform operations, data quality, detection engineering, and configuration governance. It takes around 5 minutes, no login or system access required and you get insights on the areas to focus on. 

Try it out here