Notifications
Clear all
Topic starter
17/08/2026 4:39 pm
TL;DR: Model Context Protocol opens a practical path for LLMs to interact with infrastructure, but it also expands the blast radius of overpermissioned access unless identity, authorization, and audit rules are enforced consistently, according to Teleport. The core issue is that MCP makes LLM-to-system connections easier while preserving the same governance assumptions that fail when machine-mediated requests can reach sensitive data or write paths.
NHIMG editorial — based on content published by Teleport: Where Large Language Models meet Infrastructure Identity
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 access when LLMs use MCP servers?
A: Treat the MCP server as an authorization boundary, not a convenience layer.
Q: What breaks when an LLM can call too many MCP tools?
A: The access model breaks first.
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
- Scope every MCP tool by identity and purpose Define which user, service account, or workload may invoke each tool, and limit the tool set to the minimum needed for the task.
- Separate read and write entitlements for model workflows Treat retrieval, update, and administrative actions as different privilege classes.
- Log every model-initiated request with full identity context Capture the originating user, the delegated identity, the tool called, the object touched, and the decision outcome.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- The database-by-database examples showing how MCP requests are allowed or denied under role-based access rules.
- The sample role configuration used to restrict LLM access to read-only file and data operations.
- The step-by-step logging output that shows what an audit trail looks like for approved and blocked requests.
- The product-specific implementation context for integrating infrastructure identity controls with MCP-backed workflows.
👉 Read Teleport's analysis of MCP and infrastructure identity controls →
MCP and LLM access control: are your identity controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:44 pm
MCP does not create a new identity problem, but it makes an old one easier to ignore: organizations still have to decide which identity is authorized to reach which tool, and for what purpose. The presence of an LLM between the user and the system does not remove the need for least privilege, logging, or scoped authorization. The practitioner conclusion is simple: model-mediated access must be governed as identity access, not application convenience.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to the State of MCP Server Security 2025.
- Hard-coded credential exposure is a standing privilege problem, and standing privilege is exactly what attackers want when tool-connected systems can reach sensitive data.
A question worth separating out:
Q: Who is accountable when an LLM-initiated MCP request causes data exposure?
A: Accountability sits with the organization that granted the delegated access, not with the model itself. The deciding factors are which identity was authorized, what scope it held, and whether the request path was logged well enough to reconstruct responsibility after the fact.
👉 Read our full editorial: MCP exposes the limits of legacy identity controls for LLMs
