Notifications
Clear all
Topic starter
02/08/2026 11:33 am
TL;DR: MCP security governs authentication, access control, and audit logging for agents and tools, while MCP protection focuses on inline runtime enforcement that can block prompt injection and tool poisoning as attacks unfold, according to Impart Security. The key issue is that governance and enforcement solve different problems, and neither closes the full session-level risk on its own.
NHIMG editorial — based on content published by Impart: MCP Security vs. MCP Protection
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams govern MCP access in agentic workflows?
A: Security teams should govern MCP access as delegated identity, not simple application connectivity.
Q: Why do authenticated agents still create security risk in MCP environments?
A: Authenticated agents still create risk because authentication only proves that a subject entered the system.
Q: What do organisations get wrong about MCP security?
A: They often focus on network isolation or prompt filtering and miss the real issue: an authorised workload can still perform an unintended action.
Practitioner guidance
- Define the MCP control boundary Document which controls are governance only, such as authentication, allowlisting, and audit logging, and which controls can actually interrupt a live session.
- Inventory every non-gateway MCP path Map direct client connections, developer-installed tool integrations, and any API routes that bypass centralized MCP enforcement.
- Correlate prompts, tool output, and action sequence Require the security team to review how prompt content, tool responses, and downstream actions fit together during an incident.
What's in the full article
Impart's full article covers the operational detail this post intentionally leaves for the source:
- A side-by-side breakdown of MCP security and MCP protection control responsibilities across the stack.
- Specific examples of inline response techniques for blocking prompt injection and tool poisoning.
- The operational distinction between session-level correlation, alerting, and true enforcement.
- The practical gap between gateway governance and runtime interruption in deployed environments.
👉 Read Impart Security's analysis of MCP security vs. MCP protection →
MCP security vs. MCP protection: are your controls keeping up?
Explore further
02/08/2026 12:47 pm
MCP security is an access-control and observability layer, not a runtime containment layer. That distinction matters because organisations often expect policy enforcement, audit logging, and authentication to do the job of stopping an attack in progress. They cannot. In MCP architectures, the security control may know who connected and what tool was called, but not whether the session was being steered toward abuse. Practitioners should treat this as a governance boundary, not a marketing distinction.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which helps explain why governance-only controls remain incomplete.
A question worth separating out:
Q: Who is accountable when an MCP session misuses tools or data?
A: Accountability sits with the organisation that defined the policy, the control plane that granted the session, and the team that owns logging and revocation. If those responsibilities are split, investigation and containment become slow, and the governance gap becomes part of the incident itself.
👉 Read our full editorial: MCP security vs. MCP protection: runtime governance gaps
