MCP servers expand AI tool access, but identity controls lag

At a glance

What this is: This guide explains what MCP servers are and why they matter for developer workflows, with the key finding that standardised AI tool access increases productivity only when identity and permission boundaries are tightly controlled.

Why it matters: IAM, NHI, and platform teams need to treat MCP as an identity integration problem as much as a developer convenience layer, because cross-tool AI access can quickly outgrow existing approval, logging, and least-privilege models.

👉 Read Descope's guide to the best MCP servers for developers

Context

MCP servers connect AI assistants to tools and data through a standard interface, which makes them useful but also creates a new identity and authorisation boundary to govern. For identity teams, the question is not whether MCP reduces friction, but whether each connected system still enforces scoped access, auditable actions, and controlled escalation.

The governance gap appears when an AI assistant can chain actions across GitHub, deployment platforms, databases, and documentation systems from one session. That changes the identity problem from single-system access to cross-tool delegation, where the blast radius depends on permissions, session elevation, and how much the workflow can act without human review.

Key questions

Q: How should security teams govern MCP servers in development workflows?

A: Treat each MCP server as a delegated access boundary. Separate read-only discovery from write-capable actions, scope the server to the smallest useful project or system, and require explicit approval for any step that can change infrastructure, data, or configuration. That approach keeps AI assistance useful without turning a convenience layer into broad operational authority.

Q: Why do MCP servers increase identity and access risk?

A: MCP servers increase risk because they let one AI session reach many tools through a standard protocol. If scopes are broad, the assistant can move from inspection to action across code, deployments, and data with little friction. The control challenge is not the protocol itself, but the amount of trust concentrated in each connected session.

Q: What breaks when MCP write access is not tightly separated from read access?

A: When write access is mixed with read access, the AI can change state immediately after inspecting sensitive information. That collapses the distinction between analysis and execution, making it difficult to review intent, contain errors, or prove what changed. The result is a broader blast radius and weaker accountability for every connected system.

Q: What frameworks should teams use to assess MCP governance?

A: OWASP NHI guidance and Zero Trust controls are the best starting points because MCP is fundamentally a delegated identity and access problem. Teams should also align the workflow to least privilege, session boundaries, and auditable actions so that AI assistance remains traceable across every connected tool.

Technical breakdown

How MCP standardises tool, resource, and prompt access

MCP separates three things: resources, which expose data; tools, which execute actions; and prompts, which package reusable instructions. That matters because it creates a common way for AI clients to discover and call capabilities across many services without custom integrations for each one. The server sits between the model and the platform API, translating a natural language request into a bounded set of functions. In identity terms, the server becomes a policy enforcement point only if its scopes, authentication method, and session state are actually constrained. Practical implication: treat each MCP server as an access gateway, not a convenience plugin.

Practical implication: inventory which resources and tools each server exposes before allowing production use.

Why session elevation and token scope are the real control points

Most MCP risk concentrates in how authentication and authorisation are implemented. A remote MCP server may authenticate with OAuth, API keys, or service roles, but the practical security question is what the connected AI can do once the session is active. The article shows read-only access, explicit write elevation, and time-bounded permissions for some workflows, which is the right design pattern because it recognises that AI-assisted actions are not all equal. If write access is broadly exposed, the AI can cross from observation into state change very quickly. Practical implication: separate discovery, read, and write privileges at the server level.

Practical implication: separate discovery, read, and write privileges at the server level.

Why multi-server orchestration changes the identity attack surface

The real change comes when multiple MCP servers are chained together in one workflow. A developer prompt can move from code review in GitHub to deployment in Vercel, then into documentation or database validation, without ever leaving the client. That is efficient, but it also creates a delegated access path that spans systems with different trust models, retention rules, and audit standards. The security issue is not just whether each individual server is secure, but whether the combined workflow preserves least privilege across every hop. Practical implication: govern the chain, not just the endpoint.

Practical implication: govern the chain, not just the endpoint.

NHI Mgmt Group analysis

MCP turns identity into a workflow layer, not just an authentication layer. Once an AI assistant can query, deploy, and update through a standard protocol, the identity control problem shifts from login to delegated action. That means IAM teams must think in terms of tool scopes, session state, and action boundaries, not just user or service authentication. The practitioner conclusion is simple: if the protocol can execute work, it must be governed like work.

Fine-grained permissions are only useful if write authority is isolated from discovery. The article correctly distinguishes read-only sessions from elevated write operations, which is the right architectural pattern for AI-mediated access. A server that can browse data and change configuration in the same trust state creates avoidable blast radius. OWASP NHI principles and Zero Trust thinking both point in the same direction here: separate observation from modification. Practitioners should map every MCP tool to a permission tier before production rollout.

Cross-server orchestration creates identity sprawl by delegation. GitHub, Vercel, databases, and documentation systems may each look controlled in isolation, but a chained AI workflow can move across them faster than governance processes can re-assess intent. That creates a compounded trust path where one session can touch multiple environments with different control owners. NHI governance needs to extend beyond secret storage into multi-system delegation review. The practitioner conclusion is to treat orchestration as a governance domain, not a productivity feature.

MCP adoption will pressure IAM teams to govern non-human access by action, not by account. Traditional reviews focus on which identities exist and which systems they can reach, but MCP makes the more important question what each identity is permitted to do through a natural language interface. That is especially relevant for agentic AI workflows, where tool selection and execution can occur inside one conversational session. The implication is that access governance must become outcome-aware, not merely account-aware. Practitioners should prepare for policy models that classify actions, not just principals.

OWASP NHI Top 10 and Zero Trust controls are the right baseline for MCP governance. MCP does not create a new identity category, but it does concentrate known NHI failures in a single workflow boundary: weak scope control, broad tokens, and excessive trust in connected systems. The problem is less about protocol novelty than about familiar controls being applied too late. The practitioner conclusion is to use existing NHI and Zero Trust discipline before MCP becomes embedded in production engineering.

From our research:

• From our research: 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.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• As AI agent adoption expands, teams should pair protocol governance with lifecycle controls, and our Ultimate Guide to NHIs shows how to structure that baseline.

What this signals

Agent-to-tool delegation is becoming a mainstream governance problem, not a niche developer pattern. With 98% of companies planning to deploy more AI agents in the next 12 months, the volume of connected access paths will rise even if the underlying identity model stays unchanged. Teams that already struggle with NHI inventory and access scope will feel that pressure first, especially where MCP sessions can reach production systems.

The practical signal for IAM leaders is that policy needs to move closer to the action boundary. If an assistant can inspect, deploy, and update from the same conversational interface, then approval, logging, and exception handling must follow that same chain. The controls that matter are the ones that can prove who authorised which tool, in which session, for which outcome.

Runtime delegation debt: this is the growing gap between what an AI session can do and what governance can still explain after the fact. As adoption rises, the organisations that win control will be the ones that classify actions by risk before the workflow becomes normalised.

For practitioners

• Map every MCP tool to a permission tier Classify each exposed capability as discovery, read, or write, and require a separate approval path for any tool that can change state, deploy code, or access sensitive records.
• Enforce session-bounded elevation for write operations Keep default sessions read-only, require explicit elevation for modifying actions, and make that elevated state time-bounded so the assistant cannot retain broad authority across unrelated tasks.
• Scope each server to the minimum production surface Limit an MCP server to the specific project, repository, database, or documentation space the team actually uses, and avoid broad tokens that span unrelated environments.
• Review chained workflows as one delegated access path Assess GitHub-to-deployment-to-documentation sequences as a single governance object, because the combined path can create a larger blast radius than any individual connector.

Key takeaways

• MCP standardises AI access to tools and data, but that convenience expands the identity and authorisation surface if scopes are not tightly bounded.
• The highest-risk failure mode is chained delegation across read and write workflows, where one AI session can move from inspection to production change.
• Teams should govern MCP at the action boundary, using least privilege, session elevation, and workflow-level review instead of relying on connector-level trust.

Key terms

• Model Context Protocol: A standard that lets AI clients connect to external systems through defined resources, tools, and prompts. In practice, it creates a repeatable way for models to discover data and execute actions, which means identity, scope, and audit controls must be enforced at the protocol boundary.
• MCP server: A service that implements Model Context Protocol and exposes a platform's capabilities to an AI client. It acts as the delegated access layer between the model and the target system, so its authentication model and permission scope determine how much authority the AI can exercise.
• Session elevation: A temporary increase in permissions granted during an active session for a specific task. For AI-assisted workflows, it matters because the elevated state should be bounded, auditable, and narrow enough that a model cannot carry privileged authority into unrelated actions.
• Delegated access path: A chain of permissions that lets one identity act through multiple connected systems. In MCP environments, this path can span code, deployment, data, and documentation tools, so governance has to assess the whole workflow rather than each connector in isolation.

What's in the full article

Descope's full blog post covers the implementation detail this post intentionally leaves for the source:

• Step-by-step setup examples for Claude Desktop, Cursor, Windsurf, and other MCP-capable clients
• Server-by-server configuration details for GitHub, Vercel, Supabase, Notion, Box, and Firebase
• Practical authentication patterns, including OAuth, API keys, service roles, and remote endpoint setup
• Specific prompt examples that show how each server is used inside a developer workflow

👉 The full Descope post covers server setup, auth methods, and workflow examples for each MCP integration.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.