Notifications
Clear all
Topic starter
24/06/2026 7:13 pm
TL;DR: MCP standardizes how AI applications discover and invoke external tools, but production deployments with many servers create authentication sprawl, fragmented observability, and unclear authorization boundaries, according to Kong. That makes MCP governance an IAM and NHI control problem, not just an integration pattern.
NHIMG editorial — based on content published by Kong: What Is an MCP Server? Guide to the Model Context Protocol for Enterprise AI
Questions worth separating out
Q: How should security teams govern access to MCP servers in production?
A: Treat MCP servers as part of the non-human identity estate.
Q: Why do MCP servers create new risk for IAM and NHI programmes?
A: Because they multiply credentials, authorization rules, and telemetry points across many connected systems.
Q: What breaks when AI tools are exposed through loosely governed MCP servers?
A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight.
Practitioner guidance
- Inventory every MCP server as an identity-bearing asset Track each server, its credentials, and its downstream systems in the same inventory used for service accounts and other non-human identities.
- Separate tool permissions from read-only context Classify exposed capabilities so that write or execute actions require tighter approval and logging than resource reads or prompt templates.
- Centralize authentication and discovery before server sprawl grows Introduce a shared control layer for policy enforcement, approved server discovery, and consistent audit logging across the MCP estate.
What's in the full article
Kong's full article covers the architectural detail this post intentionally leaves to the source:
- A clear breakdown of how MCP clients, hosts, servers, and transports interact in real deployments.
- Examples of tools, resources, and prompts and how each maps to different control boundaries.
- The production scaling issues behind authentication sprawl, routing complexity, and observability gaps.
- Kong's view of how gateway-style control applies when many MCP servers must be governed together.
👉 Read Kong's guide to MCP servers for enterprise AI →
MCP servers and agent access: what IAM teams need to know?
Explore further
25/06/2026 4:25 am
MCP governance is really non-human identity governance in a new wrapper. The protocol standardises discovery, but it does not eliminate the need to govern credentials, privilege, and auditability across each server-client relationship. That puts MCP squarely in the same control family as service accounts, API keys, and workload identities. Practitioners should treat the server fleet as an identity estate, not an integration detail.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint research.
A question worth separating out:
Q: How do teams reduce blast radius when deploying many MCP servers?
A: Use central policy, server registration, and fine-grained capability scoping so one credential cannot reach every connected system. Then review logs for unusual tool sequences and limit each server to the smallest practical set of actions. The goal is to constrain how far one identity can move before detection or containment.
👉 Read our full editorial: MCP servers create new governance gaps for enterprise AI access
