Building enterprise MCP servers safely needs identity-aware controls

At a glance

What this is: This article explains how to build an enterprise MCP server that exposes private knowledge to AI assistants, and shows that the real challenge is governing tool access, configuration, and trust boundaries.

Why it matters: It matters to IAM and NHI practitioners because MCP servers turn knowledge access into a governed identity problem, where tool permissions, secret handling, and client trust must be controlled like any other privileged integration.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Stacklok’s guide to building an enterprise MCP server with GitHub Copilot

Context

MCP makes private enterprise knowledge available to AI assistants through a standard tool-calling layer, but that convenience creates a governance gap if tool permissions, configuration storage, and client trust are not controlled. In practice, the security question is not whether the model can call a tool, but who can expose that tool, what it can reach, and how its credentials are protected. For identity teams, MCP behaves like a privileged integration surface, not just a developer convenience.

This matters because the access pattern is easy to over-trust. When an MCP server reaches internal systems, it can effectively extend the blast radius of the connected AI client, the underlying secrets store, and any human or machine identity that authorises the workflow. That is why MCP needs the same discipline applied to service accounts, API keys, and workload identity in other production integrations.

Key questions

Q: How should security teams govern MCP in enterprise environments?

A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.

Q: Why do AI agents and MCP integrations increase IAM risk?

A: AI agents and MCP integrations increase IAM risk because they multiply the number of tool connections, service accounts, and tokens that can carry execution authority. If those credentials are embedded in configs or copied across workflows, the trust boundary moves into places that are hard to review. That makes least privilege and short-lived access much more important.

Q: What breaks when MCP tool permissions are scoped too broadly?

A: Broad scoping breaks least-privilege governance because the same workload can invoke tools and reach resources far beyond its actual role. In practice, that makes audits less reliable and magnifies the blast radius of any compromise or misconfiguration. The fix is narrower claim-based policy, not looser trust in the calling identity.

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

How MCP server tool execution works

MCP separates the client from the model. The model reasons over a prompt, then requests a tool, and the client executes that tool against a server or internal service. That design is useful because the LLM itself does not need direct credentials, but it also means security depends on the client, the transport, and the server-side permissions. The tool should represent a complete deterministic workflow, not a collection of loosely governed API calls, because partial exposure increases ambiguity and makes access harder to audit.

Practical implication: Treat every MCP tool as a privileged workflow with explicit authorization, logging, and limited downstream reach.

Why configuration files become a secret exposure point

Enterprise MCP implementations often centralize server settings in project files, local config, or deployment manifests. If credentials, tokens, or connection strings are embedded there, the configuration layer becomes a high-value secret store by accident. That is a classic machine identity problem: the server may run correctly, but the trust boundary collapses if secrets are stored where developers, pipelines, or agents can copy them. The issue is not just leakage, but persistence, because hard-coded values survive long after the original context changes.

Practical implication: Move all secrets out of configuration files and require scoped runtime injection with rotation and revocation support.

What access scoping means for enterprise knowledge tools

Access scoping limits which knowledge sources, actions, and data sets a tool can reach. In MCP terms, that means constraining tool permissions so a server can answer one bounded task without becoming a general-purpose path into internal systems. Without scoping, the server can become an over-privileged bridge between AI assistants and enterprise content. For identity governance, this is the same failure pattern seen in excessive service-account permissions: the workflow is legitimate, but the entitlement is too broad for the task.

Practical implication: Define per-tool scopes and review them like application entitlements, especially where internal knowledge or customer data is involved.

NHI Mgmt Group analysis

MCP servers should be treated as identity-bearing workloads, not lightweight developer helpers. The article shows that an MCP server can front enterprise knowledge, but the security boundary moves to the tool, the server, and the credentials that support it. That makes the server part of the privileged access plane, especially when it can query internal systems on behalf of a client. The practitioner conclusion is straightforward: govern MCP the way you would govern any high-trust service account or workload identity.

Hard-coded configuration is the most obvious failure mode in early MCP adoption. Stacklok’s walkthrough is a useful example of how quickly a working prototype can become a secret management problem if credentials are placed in configuration files. The broader lesson is that convenience-first AI integration often pushes teams into hidden standing access. The practitioner conclusion is to separate functional prototyping from production secret handling before the server is allowed into real enterprise workflows.

Tool boundary drift is the concept practitioners should watch. A single MCP tool may start as a narrow search function, then accumulate broader access, richer context, and more data sources over time. That drift turns a deterministic action into a general-purpose access path, which weakens auditability and complicates least-privilege reviews. The practitioner conclusion is to maintain a strict definition of tool purpose and re-certify it whenever scope expands.

The governance problem is not MCP itself, but the trust assumptions wrapped around it. The protocol standardises connectivity, yet standardisation does not equal authorization. If teams assume that a standard tool interface is inherently safe, they will miss the need for scoping, secret lifecycle control, and audit trails. The practitioner conclusion is to design policy around the server’s real permissions, not around the protocol’s convenience.

This topic sits squarely at the intersection of NHI governance and agentic AI control. The server, its tokens, and its automated tool-calling path all behave like non-human identities that must be issued, constrained, and reviewed. That means identity governance is not an add-on here, it is the control plane that makes enterprise MCP viable. The practitioner conclusion is to align MCP rollout with NHI lifecycle and access governance from the start.

What this signals

Tool-scoped identity is becoming the real control point for enterprise AI integration. As MCP moves into production, teams will need to govern which tools can be exposed, which credentials can be used, and what data each workflow may touch. The practical shift is from model-centric experimentation to workload-centric authorization, with identity controls carrying the security burden.

Tool boundary drift will become a recurring operational risk. A search tool today can become a multi-source enterprise data bridge tomorrow if scope is not repeatedly reviewed. For practitioners, that means access review, secret rotation, and workflow re-certification need to be part of the deployment lifecycle, not an afterthought.

From our research: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone. That figure signals a governance problem, not a configuration nuisance, and it strengthens the case for NHI lifecycle controls around every AI-connected service.

For practitioners

• Inventory MCP servers as privileged workloads Classify each MCP server, its client relationships, and its downstream data reach as a governed workload with an owner, scope, and review cycle. This makes the server visible in identity governance instead of leaving it hidden inside developer tooling.
• Remove secrets from configuration files Keep tokens, API keys, and certificates out of project files and deployment manifests. Use runtime secret injection, short-lived credentials, and rotation controls so configuration cannot become a durable secret store.
• Scope each tool to a single bounded task Define one tool per approved business workflow and restrict the knowledge sources or actions it can reach. Review those scopes like application entitlements so an MCP tool cannot quietly become a general access bridge.
• Add logging for tool invocation and data access Record which identity requested the tool, what source it reached, and which records were returned. That evidence supports audit, abuse detection, and incident reconstruction when AI-assisted access goes wrong.
• Re-certify scope after every prompt or code change Any change that expands retrieval, adds a new source, or alters the tool’s workflow should trigger a permissions review. Tool drift is usually gradual, so governance has to be repeated whenever the implementation changes.

Key takeaways

• MCP is a governance problem as much as a tooling problem, because every server introduces a privileged access path into enterprise knowledge.
• Secret exposure and weak tool scoping are the central risks, and both are common enough to treat as design assumptions rather than edge cases.
• Production-ready MCP requires workload identity, scoped permissions, and auditability before it can be trusted with internal data.

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 Scope: The specific set of actions or resources a tool-enabled identity is allowed to use. For MCP, scope is the practical boundary that keeps a model-connected server from turning into broad system access. Weak scope design creates unnecessary blast radius and complicates later revocation.
• 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.
• Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.

What's in the full article

Stacklok’s full blog post covers the implementation detail this analysis intentionally leaves for the source:

• The full prompt sequence used to scaffold the Python MCP server with Copilot and uv.
• The specific corrections made when the AI confused the MCP SDK and selected Mypy instead of Ty.
• The streamable HTTP server transformation and the updated handle_search docstring.
• The practical project memory pattern used in AGENTS.md and README.md for future coding sessions.

👉 The full Stacklok post covers the implementation workflow, testing setup, and AI coding corrections in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It is designed for practitioners who need to turn AI-connected access into a governed control surface.