Notifications
Clear all
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.
NHIMG editorial — based on content published by Obot: MCP security risks and the path to safer server deployments
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: What breaks when MCP servers are not governed like non-human identities?
A: The trust boundary becomes too wide.
Q: Why do MCP servers create more risk than traditional APIs?
A: MCP servers create more risk because they centralize access, make tools discoverable at runtime, and often sit close to the secrets that authenticate downstream calls.
Q: How do security teams know whether an MCP tool is over-privileged?
A: Look for any tool that can access more directories, APIs, secrets, or commands than its immediate task requires.
Practitioner guidance
- Classify MCP servers as governed non-human identities Assign each server an owner, permission boundary, and lifecycle state so it is reviewed like any other privileged workload identity.
- Freeze and verify tool metadata before deployment Pin versions, sign approved components, and prevent unreviewed changes to method names, descriptions, and command parameters.
- Separate prompt context from untrusted capability data Keep external tool content out of sensitive prompt context and block servers from injecting untrusted material into the same session as privileged instructions.
What's in the full article
Obot's full analysis covers the operational detail this post intentionally leaves for the source:
- Code-level examples of command injection and unsafe tool handling in MCP server implementations
- Recommended deployment patterns for sandboxing, signing, and version pinning MCP components
- Operational guidance on prompt sandboxing and capability restriction for bidirectional client flows
- The article's security-first recommendations for enterprise MCP gateway governance
👉 Read Obot's analysis of MCP server security risks and controls →
MCP security risks: what IAM and NHI teams need to know?
Explore further
20/08/2026 6:37 pm
MCP server security is an NHI governance problem before it is an AI problem. The protocol creates identity-bearing components that execute with real privileges, so the question is not whether the model is intelligent but whether the connected server is governed like a non-human identity. That means access scoping, secret handling, and command execution controls belong in the same conversation as tool routing and prompt safety. Practitioners should classify MCP servers as governed machine identities, not incidental integrations.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
A question worth separating out:
Q: What should teams do when an MCP server is updated or replaced?
A: Treat the change like an identity lifecycle event. Revalidate the server’s permissions, review tool descriptions and command paths, re-sign or re-approve the component if needed, and confirm that old access paths are removed before the new version is trusted.
👉 Read our full editorial: MCP security risks expose a new identity governance gap
