What should organisations do before enabling MCP for production workflows?

Classify every tool by impact, define which actions require human confirmation, and verify that audit logs capture identity, host, tenant, and outcome. Then test whether the same control intent survives across every client that can consume the capability. If it does not, the governance model is incomplete.

Why This Matters for Security Teams

Enabling MCP in production is not just a tooling decision. It expands the number of actions an AI system can take on behalf of a user, and that changes the control plane. Security teams need to treat each MCP tool as a distinct risk surface, not as a generic capability bundle. That means classifying impact, defining explicit approval boundaries, and deciding which tool actions can execute without human confirmation. Guidance in the OWASP Agentic AI Top 10 aligns with this approach because agentic workflows fail when permissions are broader than the task.

This is also where governance often falls apart in practice: logs exist, but they do not reliably capture who initiated the action, where the request came from, which tenant was involved, or whether the outcome matched policy. NHIMG research on the State of MCP Server Security 2025 found that 53% of mcp server expose credentials through hard-coded values in configuration files, which shows how quickly operational shortcuts turn into persistent risk. In practice, many security teams encounter failed MCP governance only after a sensitive tool has already been used in production.

How It Works in Practice

Before production enablement, organisations should build a tool-by-tool control model. Start by inventorying every MCP server and every exposed tool, then assign each one an impact category such as read-only, internal modification, or external side effect. That classification should drive whether the tool can run automatically, requires step-up approval, or is blocked entirely. This is consistent with the control intent described in the OWASP Top 10 for Agentic Applications 2026, where runtime decisioning matters more than static trust.

From there, define the identity and audit requirements for each action. Current best practice is evolving toward short-lived credentials, workload identity, and request-time policy evaluation rather than long-lived shared secrets. That means tying the capability to the calling workload, not just to the user who launched it. NHIMG’s Ultimate Guide to NHIs is useful here because MCP servers are effectively non-human identities when they execute privileged actions.

• Classify each tool by data sensitivity, system impact, and reversibility.
• Require human confirmation for destructive, irreversible, or cross-tenant actions.
• Log identity, host, tenant, tool name, prompt context, and final outcome.
• Test the same policy across every MCP client, gateway, and orchestration layer.
• Remove hard-coded secrets and replace them with short-lived, scoped credentials.

These controls tend to break down when multiple MCP clients interpret the same server capability differently because policy intent is not enforced consistently across the full path.

Common Variations and Edge Cases

Tighter approval controls often increase latency and operator friction, so organisations have to balance safety against workflow speed. That tradeoff is especially important for production systems that rely on high-frequency tool calls, where forcing confirmation on every request would make the system unusable. Current guidance suggests using risk-based approval thresholds rather than a single approval rule for every action.

There is no universal standard for MCP governance yet, so teams need to account for client diversity, proxy layers, and server implementations that may not preserve the same semantics. A tool that looks read-only in one client may still trigger downstream side effects through chained actions or delegated calls. The Analysis of Claude Code Security is a reminder that agentic workflows can create hidden execution paths that are easy to miss in design reviews.

For that reason, organisations should pilot MCP in a constrained environment first, with production-like logging, explicit tenant separation, and rollback criteria for every high-impact tool. If a client cannot preserve approval intent, identity binding, and audit fidelity end to end, it is not ready for production use.

Related resources from NHI Mgmt Group

• How can organisations detect unsanctioned AI use before it becomes a data problem?
• How should security teams test agentic identity controls before production?
• How should organisations test AI systems for bias before deployment?
• Why do identity controls matter before organisations claim AI productivity gains?