Topic starter
25/10/2026 11:01 am
TL;DR: MCP only works in security operations when the surrounding harness enforces bounded delegation, evidence capture, and reviewable behaviour, according to Corelight. AI SOCs then need governance over traces, permissions, and drift, not just a protocol choice.
Editorial analysis by NHI Mgmt Group, based on content published by Corelight: “What the Black Hat NOC taught me about MCP & agentic SOCs (Chapter 3 of 4)”.
Key questions
Q: Why do self-improving security agents create operational risk?
A: Self-improving agents can drift away from the approved behaviour they started with, especially when changes are driven by traces and no one reviews the resulting code or workflow updates.
Q: What breaks when AI investigations rely only on embedding-based retrieval?
A: Embedding-only retrieval can miss structure, sequence, and windowed change, which are often the real clues in security investigations.
Q: How should teams govern AI agents that use MCP?
A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle.
Practitioner guidance
- Define bounded agent roles before production Separate hunting, validation, incident response, reporting, and telemetry-checking duties so each agent has a narrow purpose and minimal authority.
- Treat retrieval design as part of the control plane Use SQL, structured document traversal, and summarisation only where each one matches the investigation question and preserves evidential context.
- Freeze stable agent baselines and review deltas Save known-good versions, require human review for proposed changes, and compare new traces against a rolling baseline before release.
Bottom line: MCP becomes useful in security operations only when the harness around it enforces bounded delegation, evidence capture, and reviewable behaviour.
Glossary terms: MCP Agent Harness, AI Agent Drift, Bounded Delegation, Dynamic Retrieval
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:16 pm
MCP governance is really harness governance: the protocol is only the transport layer for tool use, while the security outcome depends on how identity, permissions, evidence, and orchestration are controlled around it. That is why SOC teams should assess the wrapper first, because the wrapper decides whether the model can act safely at all.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should teams decide between a central orchestrator and peer-to-peer agent communication?
A: A central orchestrator is easier to inspect, constrain, and audit than a mesh where every agent can talk to every other agent. For security operations, that usually produces better control over sequencing and permissioning. Peer-to-peer designs may look flexible, but they often make authorisation, attribution, and containment harder to reason about.
👉 Read our full editorial: MCP harness design matters more than the protocol itself
This post was modified 7 days ago by NHI Mgmt Group