Topic starter
30/09/2025 11:41 am
TL;DR: Teleport says Model Context Protocol standardises how LLMs discover tools and send structured requests, but leaves identity checks, scope enforcement, logging, and revocation to the implementation. That makes MCP useful for integration but fragile for governance when connected systems can trigger high-impact actions without native control boundaries.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport: “What is the Model Context Protocol (MCP)?”.
Key questions
Q: What fails when MCP tools are exposed without external identity controls?
A: The failure is not the protocol itself but the gap between discovery and enforcement.
Q: Why do MCP deployments need short-lived credentials and revocation controls?
A: Because persistent tokens turn a temporary model session into durable access.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact.
Practitioner guidance
- Layer identity verification around MCP servers Require mutual TLS, signed tokens, or gateway-enforced identity checks before any client can discover or invoke tools.
- Enforce runtime authorisation on declared scopes Validate every tool call against caller identity and current policy instead of trusting role labels embedded in schemas.
- Replace persistent credentials with short-lived access Use session-bound certificates or tokens with expiry and rotation so compromised MCP clients do not retain durable access.
Bottom line: MCP standardises model-to-tool communication, but it does not provide the trust enforcement needed for enterprise access decisions.
What's in the full article
Teleport's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of MCP hosts, clients, servers, and tool schemas
- Examples of MCP deployment models across local machines, enterprise networks, and cloud services
- Teleport's control-layer approach for adding identity checks, RBAC, and audit logging around MCP
- The article's FAQ section on using MCP with existing APIs and SDKs
👉 Read Teleport's article on Model Context Protocol security and governance gaps →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
07/10/2026 6:23 pm
MCP does not create governance, it exposes where governance must already exist. The protocol standardises discovery and invocation, but the article makes clear that identity verification, scope enforcement, logging, and revocation are all external responsibilities. That means MCP is not a control plane for trust, only a transport for action. Practitioners should treat every MCP deployment as an identity architecture decision, not a plugin decision.
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: How should security teams handle approval for high-risk MCP actions?
A: Approval should be reserved for actions that are irreversible, high impact, or likely to change access, data exposure, or production state. The goal is not to slow every task, but to stop the few actions that create real business risk if executed incorrectly. Approval should occur before the sensitive permission is granted or the action executes.
👉 Read our full editorial: Model context protocol leaves NHI governance to the caller