Notifications
Clear all
Topic starter
18/08/2026 2:48 pm
TL;DR: MCP security depends on platform-enforced isolation, per-request identity, curated server approval, structured logging, and tool-level least privilege, according to Stacklok’s how-to guide. The core problem is that MCP turns AI tool use into real execution paths, so default prototyping habits create standing access and audit gaps that traditional API security does not close.
NHIMG editorial — based on content published by Stacklok: MCP Security Best Practices: What Every Enterprise Team Needs to Know in 2026
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do shared credentials create so much risk in MCP deployments?
A: Shared credentials erase accountability and make containment harder because every tool call appears to come from the same identity.
Q: What breaks when MCP servers can reach internal services directly?
A: A single untrusted tool call can become a pivot into cloud metadata, localhost services, or internal admin planes.
Practitioner guidance
- Enforce container isolation for every MCP server Require separate runtime boundaries, blocked host filesystem access, restricted network paths, and no privilege escalation for each server before it can reach production tools.
- Replace shared credentials with per-request identity Bind each tool call to the individual user or agent through OIDC or OAuth-backed identity and eliminate locally stored shared keys in agent processes.
- Build a curated approval registry for MCP servers Review provenance, signed artifacts, and intended tool scope before a server is made available to developers or automation workloads.
What's in the full article
Stacklok's full how-to covers the operational detail this post intentionally leaves for the source:
- Exact container and network isolation settings used for MCP server deployment on Kubernetes.
- OIDC and OAuth integration details for preserving per-request identity across MCP tool calls.
- Registry and provenance workflow specifics for approving MCP servers before developer access.
- Logging, telemetry, and SIEM integration patterns for MCP activity monitoring.
👉 Read Stacklok's how-to guide on MCP security best practices for 2026 →
MCP server security for enterprises: are your controls ready?
Explore further
18/08/2026 3:31 pm
MCP security is really an NHI governance problem disguised as a tooling choice. The protocol creates a delegated execution path, but the identity risk sits in the credentials, tool permissions, and audit chain around it. That means practitioners should evaluate MCP through the same lens used for service accounts and other machine identities, not as a narrow developer platform feature.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: Who is accountable when an MCP server authorises the wrong action?
A: Accountability sits with the teams that designed and operated the consent, token validation, and scope controls, because MCP makes authorisation decisions part of the system boundary. In regulated environments, the question is not only who clicked approve but who allowed client identity, audience, and delegation checks to remain incomplete.
👉 Read our full editorial: MCP server security best practices for enterprise production teams
