Topic starter
20/08/2026 5:58 pm
TL;DR: MCP servers introduce classic security failures in a new runtime context, from command injection and deceptive tool naming to bidirectional abuse, weak authentication, and unsafe local execution, according to Obot. The governance problem is not MCP itself but the assumption that tool-connected identities can be trusted without tighter scoping, verification, and lifecycle controls.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “Security risks in the Model Context Protocol: What you need to know”.
Key questions
Q: What breaks when MCP servers are not governed like integrations?
A: What breaks is the trust boundary.
Q: Why do MCP servers create more risk when they inherit user or service privilege?
A: Because they can become confused deputies.
Q: How do you know if MCP security controls are actually working?
A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows.
Practitioner guidance
- Inventory every MCP server as a governed non-human identity Track each server, its source, transport mode, permitted tools, and connected systems.
- Sandbox MCP runtimes before granting system reach Run local servers in constrained environments with minimal file, command, and network permissions.
- Validate tool metadata and freeze approved versions Pin tool names, descriptions, and package versions so updates cannot silently change behaviour.
Bottom line: MCP security failures are governance failures when local runtimes, tool selection, and delegated authority are trusted without sufficient scoping.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:37 pm
Tool-connected identity is becoming the real MCP governance unit: MCP servers are not just software components, they behave like non-human executors with direct access to commands, files, and connected tools. That means the governance boundary is the server identity, its permissions, and its lifecycle, not the prompt alone. Security teams that still treat MCP as a simple integration layer will miss the real control point, which is whether the runtime is approved, scoped, and revocable.
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: What should organisations do when a third-party MCP server changes behaviour?
A: Treat the change as a new trust event, not a routine update. Re-approve the server, verify the new capability set, and confirm that any added tool paths still operate under the same user-context and least-privilege constraints. If those checks cannot be completed, remove the server from use until they can.
👉 Read our full editorial: MCP security risks expose a new identity governance gap