TL;DR: MCP adoption is creating five recurring security blind spots, including typosquatting, excessive permissions, hard-coded secrets, and weak observability, according to Noma Security. The practical issue is not just exposure in individual servers, but the way agent interactions can cascade across connected systems and widen blast radius.
Editorial analysis by NHI Mgmt Group, based on content published by Noma Security: “The top-five MCP security blindspots putting your organization at risk”.
Key questions
Q: What breaks when MCP servers run with shared local trust?
A: Shared local trust breaks isolation because any process on the machine may be able to call the server, and the server may inherit privileges that were never intended for broad reuse.
Q: Why do default-enabled MCP tools increase enterprise risk?
A: Because they let an agent inherit capabilities far beyond the task it was meant to perform.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact.
Practitioner guidance
- Audit MCP server provenance Inventory every MCP server in use, verify publisher identity, and remove any lookalike or unofficial package that was installed on naming similarity alone.
- Enforce default-restrictive tool sets Disable destructive and sensitive tools unless a task explicitly requires them, then recertify the enabled set whenever the workflow changes.
- Replace stored secrets with short-lived auth Prefer OAuth-based authentication or vault-backed issuance so MCP clients do not depend on hard-coded tokens in configuration files.
Bottom line: MCP security failures are not isolated software bugs. They are identity and privilege failures that can cascade across agent-driven workflows.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
MCP security blind spots are an identity governance problem, not just an AI tooling problem. Once an MCP server can mediate access to databases, APIs and business systems, it becomes part of the organisation's effective identity perimeter. That means provenance, privilege scope and auditability matter as much as code quality. The practitioner conclusion is that MCP must be governed as a non-human identity surface.
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: When should organisations prioritise blast-radius controls over more agent features?
A: They should prioritise blast-radius containment as soon as one MCP server can reach multiple business systems or sensitive data sets. Feature expansion without containment simply creates a larger failure domain. The safer sequence is to limit downstream reach first, then expand functionality only after the trust model is visible and tested.
👉 Read our full editorial: MCP security blind spots are expanding agentic AI attack surfaces