MCP server security best practices for enterprise production teams

At a glance

What this is: This is a how-to guide on securing MCP in production, with the key finding that enterprises need platform-enforced isolation, per-request identity, and tool-level least privilege because MCP extends AI actions into real systems.

Why it matters: It matters because MCP governance sits at the intersection of NHI, IAM, and emerging agentic workflows, where shared credentials, weak logging, and broad tool access can turn a single server compromise into enterprise-wide action risk.

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.

👉 Read Stacklok's how-to guide on MCP security best practices for 2026

Context

MCP security is the governance problem that appears when an AI agent is allowed to call real tools through a server that sits between the agent and enterprise systems. The first-order risk is not just data exposure, but delegated action without enough isolation, identity separation, or auditability to explain what happened after the fact. That is why MCP needs controls beyond traditional API authentication, including per-request identity and least-privilege tool access.

Most enterprise teams are still treating MCP like an early prototype layer rather than a production control plane, which leaves shared credentials, weak provenance checks, and informal deployment patterns in place. Stacklok’s guide argues that the protocol itself does not enforce security, so the platform must supply the missing control points. For practitioners, that makes MCP a governance design problem as much as a tooling choice.

This also ties directly to the wider NHI problem space, because MCP servers, service accounts, tokens, and agent clients all become non-human actors with distinct access paths. The adjacent challenge is not whether agents can use tools, but whether each call can be attributed, constrained, and revoked with the same discipline used for other high-risk machine identities.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

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. In practice, that means one leaked key can expose multiple users, multiple agents, and multiple tools at once. Request-level identity is what preserves auditability and lets teams scope access correctly.

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. Once that happens, the server is no longer just retrieving content. It is acting as a bridge from user input into protected infrastructure, which dramatically increases blast radius.

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.

Technical breakdown

Why MCP security is not the same as API security

MCP changes the enforcement model because the server does not just broker data, it can broker actions. Traditional API security focuses on authenticating the caller, but MCP security also has to control which tools can be used, what parameters can be passed, and whether the call should be allowed in the first place. The protocol defines message exchange, but it leaves authorization, isolation, and logging to the platform. That is why an MCP deployment can be technically functional while still being operationally unsafe.

Practical implication: Treat MCP platform selection as a control decision, not a developer convenience decision.

Container isolation and blast-radius control for MCP servers

Running each MCP server in its own isolated container reduces the impact of compromise by limiting filesystem access, network reachability, and privilege escalation paths. This matters because MCP servers often sit close to sensitive tools and data sources, so a single weak server can become a broad execution bridge. The container boundary is not a complete trust model, but it is the first meaningful containment layer. Without it, a compromised server can pivot far beyond its intended function.

Practical implication: Require isolation by default and reject MCP deployments that rely on shared runtime trust.

Per-request identity, OIDC, and tool-level RBAC

Shared API keys and shared service accounts erase accountability because every call looks the same after the fact. Per-request identity solves that by binding each tool invocation to the specific user or agent that initiated it, typically through OIDC or OAuth-backed authentication. Once identity is preserved at request time, tool-level RBAC can enforce who may call which tool and under what conditions. That creates an auditable control surface instead of a pooled credential model.

Practical implication: Move every MCP server toward request-level identity and block shared credentials in production.

Threat narrative

Attacker objective: The objective is to turn one trusted MCP endpoint into a high-leverage path for unauthorised tool use, data exposure, and workflow manipulation.

1. entry via a compromised or poorly governed MCP server that can reach enterprise tools, because the server itself becomes the trust boundary.
2. escalation occurs when shared credentials, absent tool scoping, or weak isolation let the server exercise actions beyond the intended workload.
3. impact follows when the agent or server can query data, write files, call APIs, or trigger workflows across connected systems with no reliable audit trail.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Per-request identity is the named control gap that separates accountable execution from pooled access. Shared credentials collapse attribution, make review impossible, and turn every call into an anonymous action performed by the server rather than the actual user or agent. The practitioner takeaway is that MCP without request-level identity cannot support credible governance.

Curated registries are the real supply chain control point for MCP adoption. Open server discovery looks convenient, but it imports unreviewed code, unknown provenance, and inconsistent permission models into production workflows. For identity teams, that means approval workflows for server enrollment matter as much as runtime policy.

Tool-level least privilege is the only defensible default for production MCP deployments. If a read-only use case can write data or trigger workflows, the environment is already over-scoped. The correct security model is deny-by-default with explicit tool exceptions, because MCP expands the blast radius of every credential that reaches it.

From our research:

• 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.
• For teams mapping this risk to governance, OWASP Agentic Applications Top 10 provides a useful external control lens for tool abuse and delegation exposure.

What this signals

Curated server governance: MCP adoption will keep expanding faster than most IAM programmes can redesign trust boundaries, which means the control point shifts upstream to approval, provenance, and runtime containment. Teams that do not inventory MCP servers as non-human execution assets will miss the place where risk is actually accumulating.

The practical signal is that machine identity controls now need to cover tool invocation paths as well as authentication events. If request identity is not preserved and analysed, you lose the ability to distinguish legitimate agent activity from over-scoped automation, which makes both incident response and access review far less useful.

The broader governance direction is clear: MCP belongs beside workload identity and privileged automation in the identity architecture, not in a separate developer sandbox. That is why the overlap with OWASP Agentic Applications Top 10 matters, because tool-use risk and identity risk are converging.

For practitioners

• 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.
• Route MCP activity into central detection and audit systems Capture user identity, tool name, parameters, and response data in structured logs and send them to your SIEM and observability stack.
• Apply tool-level RBAC and deny-by-default policy Allow only the minimum set of tools needed for each use case, and block write, destructive, or data-export functions unless explicitly approved.

Key takeaways

• MCP creates real execution authority, so weak runtime boundaries and shared credentials become identity governance failures, not just technical misconfigurations.
• The clearest evidence points to a broad control gap in MCP deployments, where exposed secrets and poor tool scoping leave server actions difficult to attribute or constrain.
• Practitioners should treat isolation, request-level identity, provenance review, and tool-level RBAC as the minimum production baseline for MCP.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Per-request identity: A control pattern where each tool call carries the identity of the user or agent that initiated it. For MCP deployments, this preserves auditability, supports least privilege, and prevents shared credentials from masking who actually performed the action.
• Tool-level least privilege: A permission model that grants access to individual tools rather than broad platform-wide capabilities. In MCP environments, this reduces blast radius by ensuring a server or agent can only invoke the specific actions needed for its task, not everything the platform can reach.
• Curated MCP registry: An approved catalog of MCP servers that have been reviewed for provenance, intended use, and permission scope before developers can deploy them. This is a governance control, not a convenience feature, because it reduces supply chain exposure from arbitrary server discovery.

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.

👉 Stacklok's full post covers deployment controls, registry governance, and audit logging details for MCP production use.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.