Notifications
Clear all
Topic starter
20/08/2026 5:50 pm
TL;DR: MCP is not a single product but a fragmented ecosystem of servers, clients, registries, gateways, and agent frameworks that changes how tools, transport, and authentication are governed, according to Obot. The governance problem is no longer just deployment choice; it is controlling who or what can invoke tools, under what policy, and with what audit trail.
NHIMG editorial — based on content published by Obot: MCP tooling, servers, clients, registries, and gateways
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 tool access in enterprise environments?
A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools.
Q: Why do MCP registries and marketplaces create identity risk?
A: Registries improve discovery, but they do not validate trust.
Q: What breaks when MCP servers are added without a gateway?
A: Authentication, authorization, and audit responsibilities fragment across servers, which makes policy inconsistent and revocation slow.
Practitioner guidance
- Map the full MCP trust chain Document which clients, gateways, registries, and servers are in use, then assign ownership for each access boundary.
- Require scoped OAuth before remote deployment Do not allow remote MCP servers into production until token scopes, revocation, and audit logging are defined for each tool and resource path.
- Treat registries as intake points Review third-party servers before they are trusted by agents or users, and block any server that cannot demonstrate safe credential handling and least privilege.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step comparisons of FastMCP, Postman, Claude Code, and other MCP client and server patterns.
- Practical deployment notes for OAuth, remote transports, and hosted versus self-hosted MCP servers.
- Gateway and registry implementation details for audit logging, policy enforcement, and on-demand hosting.
- Framework-specific advice on when to use LangChain, Nanobot, or n8n for MCP orchestration.
👉 Read Obot's guide to MCP servers, clients, gateways, and orchestration →
MCP servers, gateways, and clients: where identity risk starts?
Explore further
20/08/2026 6:30 pm
MCP governance is an identity problem before it is an integration problem. The article’s tooling map makes that clear: once servers, clients, registries, and gateways are all part of the path, the control surface is no longer one product but a delegation chain. That means NHI governance has to follow invocation rights, token scope, and auditability across each hop. Practitioners should stop treating MCP as just a developer interface and start treating it as a multi-actor access fabric.
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.
- 71% of IT teams have been advised on AI agent data access, while only 34% of executives have the same visibility, according to the same report.
A question worth separating out:
Q: How do teams decide whether to use self-hosted or remote MCP servers?
A: Choose based on the level of control you need over credentials, logging, and system reach. Self-hosted deployments give more direct governance, while remote servers usually require stronger authentication and proxy controls. The deciding factor is not convenience alone, but whether you can enforce the same policy standard end to end.
👉 Read our full editorial: MCP tooling fragments identity governance across servers and agents
