MCP servers expand AI tool access, but identity controls lag

At a glance

What this is: This is a Descope tutorial on MCP servers, showing how they standardise AI access to external tools while exposing identity and authorisation gaps across developer workflows.

Why it matters: It matters because IAM, IGA, and platform teams have to govern AI-mediated access as a cross-tool identity problem, not just a convenience layer for developers.

Context

Model Context Protocol, or MCP, gives LLMs a standard way to interact with external tools, data, and prompts through servers that expose specific actions and resources. In practice, that turns a developer workflow into an identity and authorisation problem because the AI can now move across code, deployment, data, and documentation systems from one session.

Descope’s tutorial is really about the governance implications of that shift. Once an AI assistant can query GitHub, trigger Vercel deployments, read Supabase data, or update Notion pages, the control plane has to account for scope, session elevation, and auditability across multiple services, not just one application at a time. This is an operational pattern many teams are only starting to formalise.

Key questions

Q: What breaks when MCP servers are exposed without identity controls?

A: Without identity controls, anyone with a link, key, or copied credential can reach tools and data outside policy. That breaks visibility, weakens compliance evidence, and makes it difficult to separate approved use from shadow AI activity across SaaS and internal systems.

Q: Why do AI tool chains increase authorisation risk in development environments?

A: Because the assistant can combine small, legitimate permissions into a larger delegated act. A code search, a deployment trigger, and a documentation update may each seem harmless on their own, but together they create operational power that traditional approval steps were not designed to track in real time.

Q: How should teams implement session elevation for MCP-based workflows?

A: Use read-only sessions by default, then require explicit approval for writes that affect users, flows, deployments, or records. Keep the elevated window short, log every privileged tool call, and revoke the state as soon as the task is complete so the assistant does not retain standing write authority.

Q: Should organisations treat MCP connectors like ordinary integrations?

A: No. MCP connectors often carry delegated access into multiple tools and data stores, which makes them part of the identity control plane. They should be registered, scoped, monitored, and offboarded like any other privileged machine identity, otherwise a compromise in one connector can expand into broader system access.

Technical breakdown

MCP server architecture and the new access boundary

MCP splits interaction into resources, tools, and prompts. That makes integration simpler because an AI assistant no longer needs bespoke code for every platform, but it also creates a new boundary: the server becomes the broker for what the model can see and do. In practical terms, the identity decision is no longer limited to login. It now includes what the server is allowed to expose, which tool calls are allowed in a given session, and how much downstream authority the AI inherits when it chains actions across systems.

Practical implication: treat each MCP server as a separately governed access surface, not as a harmless integration shortcut.

Session elevation and per-tool authorisation in AI workflows

The article shows a pattern where sessions begin read-only and then require explicit elevation for write actions such as user creation, flow changes, or tenant updates. That matters because AI-mediated work collapses the traditional boundary between viewing and acting. If the same assistant can inspect configuration, search documentation, and then modify production settings, the authorisation model must distinguish between low-risk and high-risk tool use at runtime. This is where session-scoped privilege becomes more important than static connector approval.

Practical implication: separate read and write capabilities by session state and require explicit elevation before any tool can change production identity data.

Cross-tool orchestration and identity blast radius

Combining MCP servers can chain actions across GitHub, Vercel, Notion, Supabase, and other services. That workflow value is real, but so is the blast radius if the assistant has excessive scope or a compromised token. A request that starts as code review can end in deployment, documentation updates, and database queries. The identity risk is not just whether each tool is individually secure, but whether the combined workflow creates emergent authority that no single system owner has reviewed end to end.

Practical implication: review cross-server combinations as a single delegated workflow and define the maximum authority any chained action is allowed to accumulate.

Threat narrative

Attacker objective: The objective is to gain effective control over cross-tool development workflows by abusing delegated AI access and turning convenience into broad operational authority.

1. Entry begins when an AI assistant is granted MCP access to multiple development systems through a standardised connector and token-based authentication.
2. Privilege expands when the same session can move from read-only inspection into elevated write operations across tools such as code, deployment, and documentation systems.
3. Impact occurs when cross-tool orchestration lets the assistant trigger changes faster than traditional approval and review checkpoints can track them.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

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 has turned tool integration into an identity governance problem. The protocol’s value lies in standardising how models reach external systems, but that also standardises how privilege can be delegated across many services at once. Once an AI assistant can touch code, data, and deployment from the same workflow, IAM cannot stay app-specific. Practitioners should treat MCP as a control-plane issue, not an integration convenience.

Access scopes are no longer the whole control story when AI can chain tools. A token that looks narrow in one service can become broad when the assistant combines tools across GitHub, Vercel, Supabase, Notion, and Box. That means effective governance depends on the combined workflow, not just the permissions of the first server in the chain. The practitioner implication is to review delegated authority end to end, not connector by connector.

Session elevation is the right pattern, but only if the elevated window stays tightly bounded. Read-only by default and explicit confirmation for writes is a stronger baseline than unconditional write access, yet the model only works if elevation is time-scoped and auditable. If the elevated session is long-lived or opaque, the control is cosmetic. Teams should make the elevated state itself the governed object.

Cross-tool AI workflows create identity blast radius that most change-control processes do not measure. An assistant that can update code, deploy it, and revise documentation can produce faster drift than human review cycles are designed to catch. That does not mean the workflow is inherently unsafe, but it does mean the governance model must observe the chain as one delegated act. The practical conclusion is to align approval, logging, and rollback around the full chain, not the individual tool call.

Workflow-standardised identity needs lifecycle rules that are different from human access and older service-account thinking. The common assumption that access can be granted once and reviewed later breaks down when the actor is a conversational system moving across tools on demand. That assumption was designed for stable, reviewable privileges. It fails when the actor can switch context, initiate actions, and terminate access within one session. The implication is that identity governance has to move closer to issuance and session state.

From our research library:

• 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.
• Read next: MCP Security Guide

What this signals

Cross-tool delegation is the real control gap. The practical risk is not that an AI assistant can call one tool, but that it can combine several low-risk actions into a higher-risk workflow before a human notices. Governance needs to move from single-system approval to chain-level authority management.

MCP makes identity review a session problem, not just an account problem. Read-only defaults, explicit elevation, and bounded write windows matter because the assistant’s authority can change inside one task. Access review processes that assume stable privileges will miss the real decision point, which is issuance and elevation time.

Identity blast radius is now a design variable. When GitHub, deployment, database, and documentation systems are all reachable through one conversational interface, the safe unit of analysis is the full delegated workflow. Teams should define what one assistant session is allowed to accumulate before it crosses into production-impacting authority.

For practitioners

• Govern each MCP server as a discrete access surface Inventory every server, its tools, and its exposed resources before enabling it in the IDE. Map each one to a business owner, a permission boundary, and an approved use case rather than allowing default adoption across teams.
• Split read and write permissions by session state Start all AI-assisted sessions in read-only mode and require explicit elevation for any action that changes users, flows, deployments, data, or documentation. Make the elevated state time-bounded and traceable.
• Review chained workflows as one delegated act Assess combinations such as code review plus deployment, or documentation updates plus database queries, as a single authority chain. Set limits on what one assistant session can accumulate across systems.
• Log and recertify AI-assisted write actions Capture which assistant session triggered each write operation, what was approved, and which downstream systems were affected. Use those records in access review and incident investigations.

Key takeaways

• MCP servers reduce integration friction, but they also turn AI-assisted development into a delegated identity problem across multiple systems.
• The core governance issue is not whether one connector works, but whether chained tool use creates authority that no single control reviews end to end.
• Teams need session-scoped elevation, chain-level review, and complete logging if they want AI tool access without expanding blast radius.

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.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Session Elevation: Session elevation is the temporary grant of higher privilege within an active identity session. For AI agents, it is especially sensitive because the privilege can be tied to a task, a conversation, or a workflow segment, then revoked automatically when that window closes.
• 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.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.