MCP in 2026: architecture, auth, and enterprise readiness

At a glance

What this is: MCP is the protocol layer that standardises how AI applications connect to tools, data sources, and services, and the key finding is that its 2026 evolution is now centred on authentication, session scope, and enterprise readiness.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern AI clients and servers through the same access and lifecycle discipline used for other non-human identities, while accounting for more dynamic tool use and multi-system delegation.

By the numbers:

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

👉 Read WorkOS's full guide to MCP architecture, auth, and enterprise readiness

Context

MCP, or Model Context Protocol, solves the N x M integration problem that appears when every AI application needs bespoke connectors for each tool or data source. The practical issue for identity teams is that those connectors inherit authentication, consent, and data-access decisions into every AI workflow, which makes the protocol an identity control surface as much as an integration standard.

For IAM and NHI programmes, the central question is not whether MCP can connect models to systems, but whether those connections can be bounded by session, scope, and accountability. As AI clients become common front doors to business data and actions, MCP governance starts to look less like API enablement and more like non-human access management at scale.

Key questions

Q: How should security teams govern MCP access in enterprise environments?

A: Treat MCP as a non-human identity and authorization problem, not just an integration protocol. Give each server an owner, scope tokens to a single task where possible, and require explicit approval for new sessions. Also separate local subprocess trust from remote OAuth-based access, because the control model is not the same in both cases.

Q: Why does MCP change identity governance for AI applications?

A: MCP turns AI connectors into standardized access paths to tools and data, which means every server becomes a governed entitlement surface. The governance challenge is less about connecting systems and more about bounding what an AI client can reach, when it can reach it, and who is accountable for the action.

Q: What breaks when MCP access is left on long-lived tokens?

A: Long-lived tokens assume access is stable enough to review later, but MCP workflows often involve temporary, multi-step delegation. That creates standing trust where task-bound trust is needed, increases blast radius if a token is reused, and makes offboarding or revocation harder to prove.

Q: What is the difference between MCP and ordinary API integration for IAM teams?

A: Ordinary APIs are point-to-point connections, while MCP standardises how AI clients discover and use external capabilities across many servers. For IAM teams, the difference is that MCP adds a protocol layer where consent, scoping, and client identity must be governed consistently rather than per integration.

Technical breakdown

MCP architecture: host, client, and server roles

MCP is organised around a host application, a client inside that host, and one or more servers that expose tools, resources, and prompts. The host is the AI application the user interacts with, the client manages the connection, and the server executes against the underlying system. This design standardises how an AI model discovers and invokes capabilities without hard-coding each integration. The security consequence is that the model becomes the decision point for tool use, while the client and server form the enforcement path for access, transport, and session context.

Practical implication: map each MCP role to an explicit identity boundary before allowing tool access.

MCP authentication, OAuth 2.1, and scoped access

MCP's auth model has evolved from early client registration patterns toward OAuth 2.1, resource indicators, and client metadata documents. For remote servers, the protocol expects consent-driven access with scoped tokens, while local stdio servers inherit the host application's security boundary. That distinction matters because the same protocol can represent very different trust models depending on deployment. The current direction is toward reducing token misuse, limiting token replay across servers, and making client identity more portable across a large ecosystem of servers.

Practical implication: treat every MCP deployment as an OAuth and resource-scoping design exercise, not a generic app integration.

Tasks, elicitation, and server-side agent loops

MCP now supports asynchronous tasks, sampling, elicitation, and even server-side agent loops. Tasks let long-running work continue after an initial request, elicitation lets the server pause for user input or external authentication, and sampling lets the server call back into the model during execution. These features make MCP more collaborative, but they also make execution paths longer and less linear. From an identity perspective, the protocol is moving from simple request-response toward delegated workflows that can span multiple steps, multiple tools, and multiple consent moments.

Practical implication: review where human approval, session state, and re-authentication must interrupt long-running MCP workflows.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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 is becoming an identity governance problem before it becomes a platform problem. Once AI clients can reach multiple servers, the control question shifts from connector availability to who or what is allowed to act across those connectors. That puts MCP squarely inside NHI governance, because the protocol is defining machine access paths that behave like identities with delegated authority. Practitioners should treat every MCP server as an entitlement surface, not just an integration endpoint.

Session-scoped authorization is the right direction because persistent trust is too blunt for AI-driven access. Long-lived tokens assume access patterns that are stable enough to review and revoke later. MCP workflows, especially when they span tasks and elicitation, create more temporary access needs that are better bounded to the session that requested them. The implication is that identity programmes must distinguish between standing entitlement and task-bound access before they let AI systems touch production data.

Trust boundaries in MCP are now split across host, client, server, and external OAuth flows. That fragmentation is manageable only when each boundary has a clear identity owner and a clear consent model. Without that, the protocol's flexibility becomes a governance liability because responsibility for access decisions gets distributed across components that may be owned by different teams. Practitioners should require one accountable control point for each boundary.

AI identity governance is converging with workload identity governance, but the operational tempo is different. MCP servers are not just APIs with a new wrapper. They are interactive, stateful, and increasingly able to coordinate multi-step execution, which means provisioning, scoping, and revocation must be designed for runtime interaction rather than static registration. Teams that already manage service accounts and tokens have the baseline, but they still need new patterns for session-bound AI access.

Session-scoped access is the named concept that should shape MCP governance plans. It describes a model where AI access exists only for the duration of a specific task and cannot be renewed by the agent itself. That concept matters because MCP is pushing organisations toward ephemeral, consent-backed delegation instead of standing credentials, and that changes how review, monitoring, and revocation need to work. Practitioners should design around the session, not the token.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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.
• That visibility gap is why the next step is not more tool breadth but tighter governance, as shown in OWASP Agentic Applications Top 10.

What this signals

Session-scoped access is becoming the governance pattern to watch for MCP. The more AI systems move through multi-step tasks, the less useful standing access becomes as a control baseline. Teams should prepare to differentiate between authenticated system-to-system trust and short-lived delegated access that expires with the workflow, not the account.

MCP also pushes organisations toward stronger separation between tool discovery and tool execution. That separation matters because discovery can be broad while execution should remain tightly scoped to business need, identity, and approval context. In practice, IAM and NHI teams should expect more pressure to record which AI client accessed which server, through which scope, and under which session state.

The governance signal is clear: as AI clients become operational actors, the identity stack must begin to treat them like managed non-human workloads with traceable authority. The control objective is not simply to let AI connect, but to make each connection reviewable, revocable, and attributable across the full delegation chain.

For practitioners

• Define MCP server ownership as an identity control Assign each server a named owner for authentication, authorization, logging, and revocation so no deployment exists without an accountable control point.
• Prefer session-scoped access for AI clients Use short-lived access tied to a single task or workflow, and require a new human approval before the agent can open a fresh session.
• Separate local and remote trust models Treat stdio subprocesses as host-bound trust and remote servers as OAuth-governed services, then apply different review rules to each path.
• Review tool permissions at the server level Catalogue which tools each MCP server can invoke, what data each resource exposes, and where a single server could reach multiple business systems.

Key takeaways

• MCP standardises AI access to tools and data, but that standardisation also creates a new identity governance surface.
• The biggest control shift is from persistent connector trust to session-scoped delegation, which better matches how AI workflows actually behave.
• IAM teams should govern MCP servers as non-human identities with explicit ownership, scoped authority, and revocation paths that work at runtime.

Key terms

• Model Context Protocol: A standard that lets AI applications discover and use external tools, data sources, and services through a common protocol layer. In identity terms, it turns integrations into governed access paths, so authentication, consent, and scope control become part of the architecture rather than an afterthought.
• Session-scoped authorization: A permission model where access exists only for a specific task or workflow and ends when that session ends. For AI systems, this is more practical than persistent access because it limits blast radius, improves accountability, and matches short-lived delegated activity better than standing credentials.
• MCP server: A service that exposes tools, resources, or prompts to an AI client through MCP. It behaves like a governed access endpoint, which means it needs ownership, scoping, logging, and revocation controls just like other non-human identity touchpoints.
• Tool invocation: The act of an AI client requesting that a server execute an action such as querying data, sending a message, or updating a record. Tool invocation matters because it is the moment when read-only context turns into governed action, and that action must be bounded by policy and session state.

Deepen your knowledge

MCP auth, scope design, and session-bound delegation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending AI clients into production systems, this is the governance baseline to study.

This post draws on content published by WorkOS: Everything your team needs to know about MCP in 2026. Read the original.