MCP in 2026: architecture, auth, and enterprise readiness

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: MCP architecture and auth show that the protocol's scale and enterprise roadmap now make identity, consent, and session governance the real adoption gate.

Why it matters: IAM, PAM, and NHI teams need to understand MCP because the protocol turns AI tools into governed access paths that can expand faster than existing review and provisioning models.

By the numbers:

• The Python and TypeScript SDKs alone see roughly 97 million monthly downloads.

Context

Model Context Protocol, or MCP, is a standard that lets AI applications connect to external tools, data sources, and services through one protocol instead of custom integrations. In identity terms, that means the access path is no longer a one-off connector problem but a reusable control surface for how AI systems reach business data and actions.

WorkOS frames MCP as an ecosystem and enterprise-readiness question, not just a developer convenience. The practical issue for IAM teams is that the protocol combines authentication, consent, session state, and tool invocation in ways that expose where today’s governance assumptions still depend on static clients and human-paced approvals.

The article also shows that MCP is moving from prototype usage to operational deployment, with remote servers, OAuth-based auth, async tasks, elicitation, and UI extensions all becoming part of the model. That makes the security discussion broader than API access alone and closer to NHI governance for AI clients and their delegated access paths.

Key questions

Q: What breaks when MCP sessions rely on persistent client secrets?

A: Persistent client secrets create a standing-access model that is hard to reconcile with MCP’s stateful sessions and multi-step workflows. The result is broader authority than the user may realise at approval time, especially when one client can reach several servers. Teams should prefer session-scoped authorization and explicit revocation paths instead of assuming long-lived tokens are harmless.

Q: Why do MCP tools create a governance problem for IAM teams?

A: MCP turns each tool into a potential permission boundary, which means IAM teams must govern many small access decisions instead of one broad application login. If those boundaries are not scoped carefully, autonomous agents can accumulate effective privilege faster than traditional reviews can catch.

Q: How should teams evaluate an MCP server before production use?

A: Check maintainer identity, documentation quality, update recency, and dependency posture, then validate that the client can be limited to specific tools and actions. A directory score or popularity rank is not enough for production decisions. The real test is whether the server can be governed as a bounded identity relationship.

Q: What is the difference between MCP integration and normal API integration?

A: Normal API integration usually connects one application to one service with bespoke code and narrow, predefined calls. MCP standardises that interaction so models can discover tools and invoke them through a shared protocol, which improves portability but also expands the governance burden. Practitioners must add identity, scope, and approval controls around the protocol.

Technical breakdown

MCP architecture and delegated tool execution

MCP separates the host, client, and server so an AI application can discover tools, send requests, and receive results through a common protocol. The host is the user-facing app, the client manages the connection, and the server exposes tools, resources, and prompts to the AI. That design removes bespoke point-to-point connectors, but it also turns each tool call into a governed delegation event. The protocol supports multiple servers in one workflow, which means a single user request can span several systems with different data and action boundaries. From an identity perspective, this is less like a simple API call and more like orchestrated delegated access across many systems.

Practical implication: Treat MCP server exposure as delegated access design, not just integration plumbing.

MCP authentication, OAuth 2.1, and session scope

For remote servers, MCP uses OAuth 2.1, scoped tokens, PKCE, and consent screens so access can be limited and authorized explicitly. The 2025 spec revisions also formalised servers as OAuth resource servers and added resource indicators to reduce token reuse across servers. WorkOS notes that session-scoped authorization is emerging as a safer pattern, because access can end when the task ends instead of persisting as a reusable credential. That matters because persistent client secrets and broad tokens create the exact standing access that identity programmes try to remove.

Practical implication: Design MCP access around task-scoped sessions and token boundaries rather than durable credentials.

Stateful sessions, tasks, and elicitation change the risk model

MCP is not purely request-response anymore. Stateful sessions let servers remember context across requests, tasks let long-running work continue in the background, sampling lets servers involve the model in intermediate reasoning, and elicitation lets servers pause for user input or redirect to trusted URLs for sensitive steps. Those capabilities make workflows richer, but they also widen the window in which a client can act with authority. A session that spans many tool calls creates more opportunity for scope drift, while background tasks make it harder to reason about when access should stop. The protocol now carries more of the security burden that used to sit in the surrounding application.

Practical implication: Review where long-lived sessions or async tasks extend access beyond the user’s intended scope.

Threat narrative

Attacker objective: Use a legitimate AI-to-tool session to reach multiple systems and perform actions or data access beyond what a static, single-purpose integration would allow.

1. Entry occurs when a user or AI client establishes an MCP session with one or more remote servers through OAuth-based authorization or local host permissions.
2. Escalation happens when that session maintains state across multiple tool calls, allowing the client to reuse access within the workflow and widen its operational reach.
3. Impact follows when a permitted tool path can touch multiple systems, create records, or retrieve sensitive data through one delegated session boundary.

Breaches seen in the wild

• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP is becoming an identity architecture problem, not just a protocol choice. Once AI clients can discover tools, hold sessions, and invoke actions across multiple systems, the control point shifts from integration logic to delegated identity governance. That puts MCP squarely into the same decision space as service accounts, OAuth clients, and workload identities. Practitioners should treat the protocol as an access substrate that needs lifecycle ownership, not as a neutral transport layer.

Standing access is the wrong mental model for MCP client trust. The article makes clear that remote servers, async tasks, and stateful sessions are now normal MCP patterns. A static client secret or broadly scoped token assumes the client’s authority is stable and reviewable over time, but MCP workflows increasingly behave like short-lived, distributed execution paths. IAM programmes that still rely on periodic review of persistent credentials will miss how fast authority can be created, reused, and discarded within one workflow.

Session-scoped authorization is the right direction because it narrows the identity blast radius. WorkOS highlights this pattern as an enterprise response to MCP’s auth gap, and the underlying issue is control over when access begins and ends. The more MCP adopts async tasks, elicitation, and multi-server workflows, the more important it becomes to bind access to a specific task rather than to a reusable identity artefact. Practitioners should see this as a governance shift toward per-session authority, not a convenience feature.

Enterprise readiness for MCP will be judged by how well it fits existing IAM operations. The roadmap points toward SSO-integrated flows, client metadata, and more standardised governance, which signals that the market now expects MCP to behave like a managed enterprise surface. That changes procurement and architecture decisions: teams will need to ask how client registration, consent, token boundaries, and revocation map into their current identity stack. The category is moving from developer novelty to governed access layer, and that raises the bar for control design.

Permission inheritance in MCP is an emerging governance boundary. As hosts, clients, servers, and tasks chain together, the effective permission set is often larger than the user sees at approval time. That creates a practical need to reason about which rights belong to the host app, which belong to the server, and which are temporary within the session. Practitioners should treat inherited access in MCP as a first-class review topic, because the protocol can concentrate risk across systems even when each individual tool seems narrowly scoped.

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

Session-scoped authorization is the key governance shift. MCP is pushing identity teams away from durable credentials and toward task-bound authority that expires with the work. That matters because AI clients can now touch multiple systems in a single flow, so the control point has to move from periodic review to issuance time.

MCP turns tool access into a lifecycle problem. When a host, client, and server all participate in one workflow, revocation and offboarding have to account for every layer of the delegated path. Identity programmes that still treat integrations as static connectors will miss where authority actually persists.

Permission inheritance in MCP needs explicit review. The protocol makes it easy for one session to span several tools, but that convenience can hide how much effective access the client accumulates. Teams should inspect inherited access paths, especially where remote servers and async tasks extend authority beyond a single request.

For practitioners

• Define MCP client trust boundaries Map every MCP host, client, and server to an owner, an access purpose, and a revocation path before approving production use.
• Prefer session-scoped authorization Replace durable OAuth secrets with task-bound sessions where the agent cannot renew access without an explicit new approval.
• Inventory remote MCP servers List every server that exposes tools or resources, then classify whether it is local subprocess, remote HTTP, or user-facing UI enabled.
• Review consent and token scoping Verify that each tool call is limited to the smallest practical scope and that resource indicators prevent token reuse across servers.

Key takeaways

• MCP is no longer just an integration layer, it is an access model that needs identity governance, session control, and clear ownership across hosts, clients, and servers.
• Its authentication story has matured, but persistent secrets and broad tokens still create a standing-access problem that enterprise IAM teams cannot ignore.
• The practical response is to limit authority to the session or task boundary and to treat every server as a governed access path, not a neutral connector.

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.
• Task-scoped Authorization: Task-scoped authorization limits an AI agent’s access to the specific data, tools, and actions needed for one bounded objective. It is a stronger fit than static role assignment when the system’s behaviour can change during execution and when overreach creates immediate business risk.
• Resource Server: The component that hosts protected resources and validates whether a request is allowed to access them. In MCP deployments, the resource server should not issue tokens itself. It should verify presented credentials, enforce scopes, and rely on a separate authorization server for identity decisions.
• Permission Inheritance: The practice of allowing access on one object to flow into related objects through defined traversal rules. It reduces duplicate configuration, but it also creates hidden privilege paths that must be understood and reviewed. In complex systems, inheritance is often the real source of effective access.

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 building or maturing an IAM programme, it is worth exploring.