Building enterprise MCP servers safely needs identity-aware controls

At a glance

What this is: This is a walkthrough on building an enterprise MCP server, and its main finding is that MCP adoption turns quickly into an identity and governance issue when tools reach private knowledge through client-side execution and loosely defined permissions.

Why it matters: IAM, NHI, and AI security teams need to treat MCP servers as governed access pathways, not just developer convenience features, because tool execution, permission scope, and secret handling all shape the effective attack surface.

Context

MCP is a standard for connecting AI clients to tools and data sources, but that convenience creates a governance problem once private enterprise knowledge is exposed through those tools. The article is really about the control plane around AI-assisted retrieval, where identity, permissions, and client execution boundaries matter as much as code quality.

The security issue is not that MCP exists, but that enterprise teams can treat it like a normal application integration and miss the access model underneath it. When tools are executed on the client side and configuration is handled loosely, the same patterns that cause NHI sprawl and secret leakage in other systems begin to appear here too.

Key questions

Q: What breaks when MCP tools are given broad access to enterprise knowledge?

A: Broad access turns an AI tool into an implicit delegation path, so private data can be reached through a legitimate-looking workflow that no one reviewed as a privilege boundary. The failure is not only technical exposure, but governance drift: the tool becomes easier to reuse than to control, and access decisions move from policy to convenience.

Q: Why do MCP servers create more risk than traditional APIs?

A: MCP servers create more risk because they centralize access, make tools discoverable at runtime, and often sit close to the secrets that authenticate downstream calls. Traditional APIs usually expose fixed interfaces; MCP adds a broker that can widen the blast radius if credentials or permissions are too broad. The danger is delegation without enough identity governance.

Q: What are the signs that an MCP deployment is drifting into unsafe privilege and visibility gaps?

A: Warning signs include broad tool permissions, unsigned or missing traces, repeated manual exceptions, and agents that can act outside their intended scope. If catalog drift is rising, redaction and region-routing rules are bypassed, or the team cannot prove which authority was used for a call, the deployment is losing control and should be tightened immediately.

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.

Technical breakdown

Client-side execution changes the trust boundary

In MCP, the model does not call the data source directly. The client executes the tool request, which means the control point sits with the local app, its configuration, and the identity context it carries. That creates a different trust model from a conventional API integration because the tool invocation is mediated by the user-facing environment, not a fixed server-to-server path. If the client, configuration, or session is not tightly governed, the effective access path becomes much broader than the intended tool scope.

Practical implication: treat the client as part of the access control boundary, not just the model or server.

Why MCP tools are not API endpoints

API endpoints are usually small, reusable operations, while MCP tools are expected to complete a full workflow in one deterministic action. That design makes tool descriptions and scope control especially important, because the tool is carrying the business logic boundary, not just a transport interface. In identity terms, the danger is overloading a single tool with broad authority that would normally be split across several controlled operations. For enterprise use, the safer model is explicit task scoping with narrow, reviewable permissions.

Practical implication: map each tool to one bounded business action and avoid broad, composite permissions.

Configuration files become secret and policy choke points

The article points to the need for centralized configuration and repeatable project settings, which is helpful for engineering discipline but also reveals where NHI risk concentrates. If MCP server settings, tokens, or client instructions are scattered across files and developer workflows, those files become a leakage surface and a persistence surface for secrets. That is the same governance pattern seen in other machine-identity problems: the secret is not the only asset at risk, the surrounding authorization intent is too. Build-time convenience has to be matched with runtime secret handling and revocation discipline.

Practical implication: govern MCP configuration as sensitive control material, not just developer convenience.

Threat narrative

Attacker objective: The attacker aims to use a legitimate-looking MCP workflow to reach private enterprise data or abused tool access without crossing a strong authentication or authorization boundary.

1. Entry occurs through AI-assisted development and client-side tool setup, where the MCP server is connected to enterprise knowledge sources without a strong access boundary.
2. Credential or policy weakness then appears in configuration, because tool definitions, secrets, and permissions can be handled in ways that are easy to copy, reuse, or overexpose.
3. Impact is unauthorized exposure of private enterprise knowledge through an apparently legitimate AI workflow, with the trust decision shifted to the wrong control layer.

Breaches seen in the wild

• Microsoft Azure OpenAI abuse by Storm-2139: Storm-2139 used API keys leaked by Microsoft customers to hijack Azure OpenAI, bypass safety guardrails and resell access to generate harmful content.
• Samsung ChatGPT leak 2023: Samsung staff pasted chip source code and meeting notes into ChatGPT weeks after it was allowed, leading Samsung to restrict generative AI tools.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity-aware tool governance is now a prerequisite for safe MCP adoption. MCP collapses the distance between an AI request and an enterprise data source, so the governance model has to decide who or what is allowed to invoke a tool, under what conditions, and with what scope. The article’s central lesson is that tool usefulness and access discipline must be designed together. Practitioners should treat MCP as an identity control problem before they treat it as an integration pattern.

Tool sprawl creates the same governance debt seen in NHI estates. Once teams start wrapping internal knowledge, search, and retrieval logic into tools, they create a growing set of machine-mediated access paths that must be inventoried, reviewed, and retired. This is where NHI thinking becomes directly relevant: the tool is not just code, it is an access-bearing workload with lifecycle obligations. Practitioners should manage MCP servers as governed non-human access paths, not as throwaway developer utilities.

Centralized configuration reduces variation, but it does not remove authorization risk. The article shows why centralizing project settings, tasks, and prompts helps consistency, yet consistency alone cannot guarantee that a tool is appropriately scoped or that secrets are protected. That is the control gap many teams miss: standardization without entitlement review still leaves broad access in place. Practitioners should pair configuration hygiene with explicit privilege design and revocation ownership.

The named concept here is tool-mediated access drift: when AI tools, client execution, and enterprise knowledge access gradually widen the effective authority of a workflow beyond what the original design intended. In practice, the drift happens when tool descriptions, configuration files, and developer convenience outpace identity review. Practitioners should look for this drift whenever an MCP server is promoted from prototype to shared enterprise service.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• 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.
• Read next: MCP Security Guide

What this signals

Tool-mediated access drift: once an MCP server becomes the default way to reach internal knowledge, the real control problem is no longer model quality but whether the tool path has the same review discipline as any other access-bearing service. That means identity ownership, entitlement scope, and secret handling need to be explicit from the first prototype.

The AI security lesson is broader than MCP itself: when clients execute tools locally, the trust boundary shifts toward the user environment and the configuration that defines what the tool can do. Teams that already manage NHI lifecycle risk will recognise the pattern immediately, because the same questions appear here. Who owns the access, how is it limited, and what happens when it must be revoked?

For practitioners

• Define explicit tool authority boundaries Assign each MCP tool a narrowly bounded business purpose, a named owner, and a reviewable permission scope before exposing enterprise knowledge to AI clients.
• Treat client-side execution as governed access Document the client, server, and identity context that each tool invocation depends on, then restrict the enterprise knowledge sources reachable from that path.
• Centralize and review MCP configuration Keep tool definitions, runtime settings, and secret references in controlled configuration so that changes can be reviewed, traced, and revoked quickly.
• Run MCP servers through standard security checks Validate the server with repeatable linting, testing, and dependency review before it is allowed to expose any enterprise data.

Key takeaways

• Enterprise MCP servers turn AI convenience into an access governance problem when private knowledge is exposed through client-side tool execution.
• Configuration discipline helps, but it does not replace explicit authorization design, secret control, and lifecycle ownership for the tools themselves.
• Treat MCP servers as governed access paths with named owners and scoped authority, or the prototype will quietly become a durable identity risk.

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.
• Tool-Mediated Access Drift: The gradual widening of authority when an AI tool begins with a narrow purpose but ends up reaching more data, systems, or workflows than intended. It usually happens through convenience-driven configuration, reused permissions, and weak lifecycle review.
• Client-Side Execution: Client-side execution is the running of code inside the user’s browser after the application has been delivered. It matters because scripts can interact directly with page content, form inputs, and session context, which creates a governance problem that server-side controls do not fully cover.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the controls needed to govern AI-connected access paths with confidence.