Topic starter
17/10/2025 11:48 am
TL;DR: Model Context Protocol standardises how AI models connect to tools and data sources, with rapid adoption already producing 1,000 open-source connectors by early 2025, according to Astrix Security. The security issue is not connectivity itself but the new trust, access, and privilege assumptions it creates for non-human identities.
Editorial analysis by NHI Mgmt Group, based on content published by Astrix Security: “Model Context Protocol (MCP)”.
By the numbers:
- Since its launch in late 2024, MCP had over 1,000 open-source connectors developed by early 2025.
Key questions
Q: What breaks when MCP connectors expose more tools than the AI task needs?
A: The access model breaks because runtime discovery can widen the effective privilege set beyond what was approved.
Q: Why does Model Context Protocol create identity risk for enterprises?
A: MCP creates identity risk because it allows autonomous software to act across live systems with valid permissions and persistent context.
Q: How do teams know whether MCP permissions are actually under control?
A: Look for separate read and write entitlements, explicit per-tool scoping, and complete logs for both permitted and denied actions.
Practitioner guidance
- Define connector allowlists before deployment Approve only the tools and resources an AI host may reach through MCP, and reject servers that expose broader capabilities than the use case requires.
- Separate discovery from authorisation Do not let tool discovery itself imply permission.
- Review host-to-server trust boundaries Document which host applications can open MCP sessions, which servers they may call, and which enterprise systems those servers can touch.
Bottom line: MCP turns AI connectivity into an access-governance issue because standardised tool discovery can expand what a non-human identity can do in production.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 12 months ago by Astrix Security
This topic was modified 2 days ago by NHI Mgmt Group
06/10/2026 4:37 pm
MCP creates a trust-layer problem, not just an integration problem: The protocol standardises how AI systems reach tools, but standardisation also standardises the attack surface. Once connectors become portable, the governance burden shifts from one-off integration review to repeatable access control across many services. Practitioners should read MCP as a control-plane issue, not a convenience feature.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: What is the difference between MCP integration and normal API integration?
A: Normal API integration usually connects one application to one service with bespoke code and narrow, predefined calls. MCP standardises that interaction so models can discover tools and invoke them through a shared protocol, which improves portability but also expands the governance burden. Practitioners must add identity, scope, and approval controls around the protocol.
👉 Read our full editorial: Model Context Protocol changes how AI agents connect to enterprise tools