Topic starter
18/08/2026 2:48 pm
TL;DR: MCP servers create execution risk because they can call tools, write data, and trigger workflows, according to Stacklok. Production use needs isolation, per-request identity, curated server approval, structured logging, and least privilege at the action layer.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “MCP Security Best Practices: What Every Enterprise Team Needs to Know in 2026”.
Key questions
Q: Why do MCP servers need platform-level identity and authorisation controls?
A: MCP servers can trigger real tool actions, so the risk is not only authentication but what an authenticated caller can do next.
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.
Q: What breaks when MCP servers rely on a single shared credential?
A: A single shared credential breaks attribution, scope control, and revocation precision.
Practitioner guidance
- Enforce isolated runtime boundaries Run every MCP server in its own container with minimal filesystem, network, and privilege access so compromise stays contained to that server.
- Bind every call to a unique identity Replace shared keys and shared service accounts with per-request identity so each tool call is attributable to a specific user or agent.
- Approve servers before deployment Maintain a curated internal server registry and require provenance checks so only reviewed MCP servers can be made available to developers.
Bottom line: MCP servers create execution risk because they can call tools, write data, and trigger workflows, so identity and authorization must be governed at the action layer.
Glossary terms: Model Context Protocol, Per-request identity, Curated Registry, Blast Radius
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 20 hours ago by NHI Mgmt Group
18/08/2026 3:31 pm
MCP server security is now an identity boundary problem, not just an API hardening problem. MCP turns an AI tool request into a real execution path, so the control question shifts from who connected to what that identity is allowed to do at tool level. That is a material change for IAM, PAM, and NHI governance because authorization must follow the action, not just the session. Practitioners should treat the MCP layer as governed delegated access.
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.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What is the difference between API security and MCP security?
A: API security focuses on protecting known endpoints and request boundaries. MCP security must also govern the agent’s state, the context it carries, and the sequence of tool actions it can trigger. In practice, that means moving from endpoint-centric controls to workflow-centric access policy and continuous enforcement.
👉 Read our full editorial: MCP production security depends on governed runtime execution
This post was modified 20 hours ago by NHI Mgmt Group