What should organisations do when MCP-connected systems start touching production data?

Why This Matters for Security Teams

When MCP-connected systems begin reaching production data, the risk profile changes immediately. These are no longer low-friction developer integrations; they are governed access paths that can read records, trigger workflows, and move sensitive data across tool chains. That makes ownership, scoping, and auditability non-negotiable. Current research on MCP shows how often security assumptions fail in practice, including exposed secrets and weak permission scoping in live deployments, as documented in The State of MCP Server Security 2025.

Security teams often misread MCP as a protocol issue when the real problem is trust expansion. Once an agent can query production systems, every downstream action needs explicit policy, logging, and review. The same pattern appears in agentic systems more broadly, where autonomous behavior creates access paths that traditional integration reviews do not capture, which is why the OWASP Agentic AI Top 10 treats tool abuse and excessive authority as first-order risks. In practice, many security teams encounter data exposure only after an agent has already queried production tables or copied sensitive outputs into another workflow, rather than through intentional access design.

How It Works in Practice

The right response is to put MCP connections under the same governance model used for privileged workloads. Start by assigning a named owner for each mcp server, then classify every connected tool by the production data it can reach and the actions it can invoke. That means separate approval for read, write, export, and administrative functions, not a single blanket “integration approved” decision.

From there, apply least privilege at the tool and dataset level. If an agent only needs customer status lookups, it should not inherit table-wide access or broad API permissions. Current guidance suggests using short-lived credentials, scoped tokens, and explicit session boundaries so access expires when the task ends. This is especially important for production-facing agents because long-lived secrets expand the blast radius when a workflow is replayed, chained, or reused outside its original purpose. NHIMG’s research on OWASP Agentic Applications Top 10 aligns with this view: tool authority must be constrained at runtime, not assumed safe because the integration was approved once.

• Map each MCP tool to a data class, business owner, and risk tier.
• Use per-task or per-session credentials with clear TTL and revocation.
• Log every tool invocation, arguments, response class, and downstream handoff.
• Review whether the agent can escalate from read-only actions into write paths.
• Test the full chain, including what happens when a tool returns sensitive data unexpectedly.

Where possible, align the identity of the connecting workload to a verifiable workload identity rather than a shared service account. That makes it easier to prove which agent or automation invoked a production action and to isolate one compromised path from another. This guidance breaks down in environments where MCP servers are deployed ad hoc with shared tokens, no per-tool authorization layer, and no centralized log correlation across the agent, the MCP server, and the target system.

Common Variations and Edge Cases

Tighter control over MCP access often increases operational overhead, requiring organisations to balance faster experimentation against stronger production safeguards. That tradeoff becomes harder when teams want agents to move from sandbox to production without a formal review, but best practice is evolving toward staged promotion rather than open-ended trust.

One common edge case is read-only access that still creates risk. Even if an agent cannot write to production, it may exfiltrate customer, financial, or credential data into prompts, memory, or downstream tools. Another is delegated automation, where an MCP server itself calls additional APIs. In that case, security teams need to inspect the entire chain, not only the first hop, because the agent may be operating within policy at one layer while violating it at the next. The AI Agents: The New Attack Surface report shows why this matters: organisations already report agents going beyond intended scope, including accessing unauthorised systems and revealing credentials.

There is no universal standard for MCP production governance yet, so organisations should treat policy as code, enforce approval gates before production enablement, and require periodic access recertification. Use current research from Analysis of Claude Code Security as a reminder that developer-facing agent tools can still touch live environments if guardrails are weak. The sharpest failures usually appear when teams allow “temporary” production access to become permanent because nobody owns the review cycle.

Related resources from NHI Mgmt Group

• What should IAM teams review first when agents start touching production systems?
• Why do AI systems make sensitive data harder to protect than traditional applications?
• Why is it important to integrate identity and data governance?
• How do organisations operationalise NHI ownership at scale?