Notifications
Clear all
Topic starter
19/08/2026 4:06 pm
TL;DR: Tool-based access in MCP can quickly become an identity and governance problem, especially when configuration files, scoped permissions, and client-side execution are handled loosely, according to Stacklok’s walkthrough. The operational lesson is that MCP adoption needs control boundaries, not just working code.
NHIMG editorial — based on content published by Stacklok: Build your first enterprise MCP server with GitHub Copilot
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.
Questions worth separating out
Q: How should security teams govern MCP in enterprise environments?
A: Treat MCP as an identity and authorization problem first.
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.
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.
Practitioner guidance
- 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.
- Remove secrets from configuration files Keep tokens, API keys, and certificates out of project files and deployment manifests.
- 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.
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.
👉 Read Stacklok’s guide to building an enterprise MCP server with GitHub Copilot →
Enterprise MCP servers: what identity and access controls are missing?
Explore further
19/08/2026 4:39 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Building enterprise MCP servers safely needs identity-aware controls
