MCP exposes the limits of legacy identity controls for LLMs

At a glance

What this is: This is an analysis of how Model Context Protocol changes LLM integration with infrastructure and why identity and access controls must apply to model-driven requests.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern LLM-mediated access as a normal identity flow, not a special-case integration path.

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.

👉 Read Teleport's analysis of MCP and infrastructure identity controls

Context

Model Context Protocol is a standard that lets large language models connect to tools and data sources in a structured way. The identity problem is that once an LLM can act on behalf of a user or service, the access path must inherit the same authorization, logging, and scope controls that govern any other non-human identity.

The gap is not the protocol itself. The gap is assuming that an LLM-mediated request is somehow separate from the enterprise identity model, when in practice it can reach databases, files, and operational tools through the same permissions that govern service accounts and other NHIs.

For security teams, that means MCP should be treated as an access layer with identity consequences, not just an integration convenience. The article’s examples show that read and write outcomes depend on policy scope, which is typical of the broader challenge, not an edge case.

Key questions

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. Identify the human, the client application, and the backend tool separately, then enforce least privilege on each tool call. If the server cannot verify who is asking and what they may do, the model should not receive access to sensitive data or actions.

Q: What breaks when an LLM can call too many MCP tools?

A: The access model breaks first. If a model can choose from broad tool permissions, it can move from harmless retrieval into sensitive modification or disclosure without a meaningful authorization boundary. That creates excess blast radius and makes the original access review almost meaningless.

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. If tool access is inherited from a general user role without per-workflow limits, the control is probably too coarse to trust.

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.

Technical breakdown

How MCP turns an LLM into an identity-mediated tool user

MCP provides a structured way for a model to discover and call external tools, but the security meaning comes from the identity context wrapped around those calls. The model is not the authority; the session, service account, or user identity behind the request is. That means the effective trust boundary shifts from the prompt to the tool permission set, the data plane, and the audit layer. If those controls are broad or implicit, the model can reach more than the operator intended, even when the request appears benign.

Practical implication: scope MCP tool access by identity and task, not by model capability.

Why read and write permissions matter differently in MCP workflows

The article’s examples show a basic but important control pattern: read requests can be allowed while write requests are denied, and both outcomes should be logged. This is classic least privilege, but applied to model-mediated infrastructure access. The technical issue is that LLMs can appear to be a conversational front end while actually executing against databases or file systems. If authorization is too coarse, a model can cross from retrieval into modification without a meaningful human checkpoint.

Practical implication: separate retrieval permissions from modification permissions in every MCP-backed workflow.

Why audit logging is part of the control plane, not an afterthought

When a model can initiate infrastructure requests, audit records become the only durable evidence of what happened, who authorized it, and whether the action was permitted. The article emphasizes logging for both successful and denied requests, which is the right signal because failures are often as informative as approvals. In identity terms, logging supports accountability, exception handling, and post-incident review. Without that record, teams lose the ability to distinguish an approved model action from unauthorized overreach.

Practical implication: make every MCP request produce an auditable identity event with the user and tool context.

Threat narrative

Attacker objective: The objective is to use model-mediated access to reach data or actions that exceed the intended identity scope.

1. Entry occurs when an LLM is connected to internal tools through MCP and inherits access paths into databases or files. Escalation occurs if tool permissions are broader than the user’s actual authorization or if write paths are exposed alongside read paths. Impact occurs when the model retrieves sensitive data, modifies records, or bypasses accountability because the access scope was never constrained tightly enough.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Tool permission scope is now the control point that matters most for MCP governance: once a model can select and call external tools, overbroad permissions become the fastest route to unintended access. Read and write separation, per-tool scoping, and denial logging are not implementation details; they are the mechanism that keeps the model inside its intended authority. The practitioner conclusion is to treat MCP tool scopes as first-class entitlements.

Identity blast radius is the right concept for MCP risk: the question is not whether the model is clever, but how far a single connected identity can move across data and action boundaries. If one MCP session can query, transform, and act without meaningful segmentation, the blast radius is already too large. The practitioner conclusion is to shrink the identity footprint before expanding model connectivity.

LLM-mediated access exposes the same governance weakness that service-account sprawl creates in classic NHI programmes: access is often granted for integration convenience and then left broader than the task requires. That pattern was built for environments where interfaces were static and easy to reason about. The practitioner conclusion is to bring MCP under the same lifecycle discipline used for privileged NHI access.

Auditability is no longer optional when machine-mediated requests can trigger infrastructure actions: if the request path is not attributable, reviewable, and tied back to a governed identity, incident response loses the evidence chain it needs. The practitioner conclusion is to make audit logging a control objective, not a by-product of the platform.

From our research:

• 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.
• For a broader control model, see Ultimate Guide to NHIs for how lifecycle and access governance apply to machine identities across environments.

What this signals

Identity teams should expect MCP to pull LLM access into the same governance queue as other non-human identities: once tool use becomes operational, the question is no longer whether the model is intelligent enough, but whether the delegated access is narrow enough to survive audit. Programmes that already struggle with service account sprawl will feel this most quickly.

Identity blast radius is the concept to operationalise next: if a single delegated session can read, transform, and act across systems, the governance failure is about scope, not prompt quality. That is why NHI lifecycle controls and access review discipline need to extend into MCP-connected workflows before adoption scales further.

The practical signal for practitioners is simple: if you cannot explain which identity owns each tool path, you do not yet have governable MCP usage. That is a control problem, not a visibility problem, and it belongs in the same operating model as other privileged non-human access.

For practitioners

• 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. Review whether the model can discover tools that were not intended for that workflow, then remove or isolate them.
• Separate read and write entitlements for model workflows Treat retrieval, update, and administrative actions as different privilege classes. A model that can query a table should not automatically be able to modify it, and a denied write attempt should still generate a log record for review.
• 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. Use those records to support access review, incident reconstruction, and exception handling.
• Apply NHI lifecycle governance to MCP-backed access Track onboarding, recertification, change, and offboarding for every non-human access path that can reach an MCP server. If the underlying identity changes role or purpose, revoke the connected tool scope at the same time.

Key takeaways

• MCP does not replace identity governance, it makes delegated access more visible and more consequential.
• The real control issue is tool scope, because broad permissions turn LLMs into high-blast-radius access paths.
• Practitioners should govern MCP as non-human identity access with auditability, least privilege, and lifecycle control.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Tool Scope: The specific set of actions or resources a tool-enabled identity is allowed to use. For MCP, scope is the practical boundary that keeps a model-connected server from turning into broad system access. Weak scope design creates unnecessary blast radius and complicates later revocation.

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.

👉 Teleport's full post shows the query examples, access control patterns, and logging flow behind the examples.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.