Topic starter
12/02/2026 9:45 pm
TL;DR: Model Context Protocol centralizes AI tool connections, logging, and authorization, which can reduce shadow tools, excessive permissions, and prompt-injection exposure, according to Noma Security. The governance problem shifts to whether teams can trust each MCP server, scope tool access tightly, and monitor behaviour before AI agents inherit broad access.
Editorial analysis by NHI Mgmt Group, based on content published by Noma Security: “How model context protocol (mcp) strengthens security for your agentic ai”.
Key questions
Q: What breaks when AI tools are exposed through loosely governed MCP servers?
A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight.
Q: Why do MCP servers create governance problems for AI workloads?
A: Because they mediate tool access for AI systems while often leaving little trace of what happened inside the interaction.
Q: What are the signs that MCP governance is failing?
A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose.
Practitioner guidance
- Inventory every MCP server and connector Record each server, owning team, business purpose, and tool scope so hidden integrations and duplicated access paths can be removed.
- Validate server trust before onboarding Require provenance, patch ownership, and update review for every untrusted MCP server before it is allowed to mediate tool access.
- Scope AI tool permissions by use case Bind each AI workflow to the minimum tool set needed for that task, then separate browse, data, and execution permissions.
Bottom line: MCP can simplify AI tool governance, but it also creates a privileged trust layer that must be managed as carefully as any other identity control point.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/10/2026 5:41 pm
MCP creates a governance concentration point, not just an integration standard. Once tool access, authorization, logging, and discovery converge in one protocol layer, that layer becomes part of the identity control plane. The value is real, but so is the blast radius if the server, connector, or integration chain is not trusted. Practitioners should treat MCP as privileged identity infrastructure, not middleware.
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.
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Should organisations treat MCP access like third-party software risk or IAM risk?
A: Both. MCP server onboarding is a third-party trust decision, while tool permissions, authorization, and revocation are identity governance decisions. If either side is handled in isolation, the organisation can approve a connector that still gives AI systems too much practical access.
👉 Read our full editorial: MCP centralizes AI tool access, but trust and supply chain risk remain