MCP adoption is moving from novelty to durable developer usage

At a glance

What this is: This is a recap of MCP Night 2.0 that shows developer adoption of the Model Context Protocol accelerating as installation friction drops and context-rich servers become the most used.

Why it matters: It matters because IAM teams now need to govern MCP-connected tools, secrets, and access paths with the same discipline used for NHI workloads and emerging agentic workflows.

👉 Read WorkOS's MCP Night 2.0 recap on developer adoption patterns

Context

Model Context Protocol is an integration layer that lets AI tools and developer environments connect to external systems, documents, and data sources. In practice, that turns protocol adoption into an identity problem as much as a developer-experience problem, because every connection carries tool permissions, data exposure, and authentication assumptions.

The article’s core signal is not that MCP exists, but that developers keep using it once access becomes low-friction and context-rich. That shifts the governance question from whether teams will experiment with MCP to how they will scope, review, and revoke the identities and secrets behind those connections.

Key questions

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

A: Treat each MCP server as a governed non-human identity with explicit ownership, scoped permissions, and a lifecycle. The critical tasks are to record what data it can access, what actions it can take, and how it is revoked when the use case ends. Without that, convenience turns into unmanaged access.

Q: Why do MCP connections change the identity risk surface for engineering teams?

A: MCP connections pull live data and tool access into one session, which expands the effective blast radius beyond a single application. The risk is not just the server itself, but the combination of credentials, scopes, and downstream systems it can reach. That creates a broader governance boundary than traditional point-to-point integrations.

Q: What do security teams get wrong about OAuth-enabled developer tools?

A: They often assume OAuth automatically makes access safe to delegate. In practice, OAuth only delegates trust. If scopes are broad, consent is weak, or revocation is missing, the connected tool can retain more access than the workload actually needs.

Q: How can organisations tell whether an MCP integration is safe to keep in production?

A: A safe MCP integration has a named owner, documented scopes, observable activity, and a working offboarding path. If any of those are missing, the integration is still experimental from a governance perspective, even if developers already rely on it.

Technical breakdown

MCP server adoption follows access friction, not protocol novelty

MCP adoption behaves like most identity-enabled platform shifts: the easier it is to connect tools, the faster usage grows. One-click install and OAuth reduce the operational cost of trying a server, which removes the biggest barrier between curiosity and routine use. That matters because the protocol is not just a transport layer. It is a permissioned path into data, tooling, and workflows, so adoption speed directly changes governance pressure.

Practical implication: Treat low-friction onboarding as an access expansion event and review the underlying scopes, consent flows, and approval records.

Context-rich MCP servers change the identity security surface

The most-used servers in the recap are not abstract infrastructure tools. They are documentation, database, browser, design, and issue-tracking connectors that pull live context into the developer session. That means the relevant security question is no longer only what the tool can do, but what data and permissions it inherits once connected. In NHI terms, each server creates a distinct trust boundary around credentials, tokens, and downstream system access.

Practical implication: Inventory MCP servers by the data sources and permissions they inherit, then map each one to a specific identity owner and review cadence.

OAuth makes MCP easier to adopt, but not easier to govern

OAuth support lowers integration friction, but it does not solve scope design, consent quality, or revocation hygiene. If the connected account is over-scoped, the protocol simply makes that overreach easier to operationalise at scale. For identity teams, the architectural issue is that a convenient authorisation layer can hide poor entitlement design underneath it. That is a classic NHI failure mode: access is authenticated correctly but governed too loosely.

Practical implication: Audit OAuth-authorised MCP connections for scope creep, stale grants, and missing offboarding controls before adoption spreads further.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.

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 adoption is becoming an NHI governance problem before it becomes an agentic AI problem. The article shows developers using MCP as a practical bridge to documents, databases, browser state, and project systems. That means the first-order risk is not autonomous behaviour, but non-human access that is easy to create and hard to inventory. Practitioners should read MCP as an identity expansion pattern, not just a tooling trend.

Low-friction onboarding creates privilege growth faster than most entitlement programmes can absorb. One-click install and OAuth reduce the time between tool discovery and live access, which shortens the period in which governance can intervene. That is the same structural pattern seen in other NHI sprawl events: convenience beats review cadence. The practitioner conclusion is that onboarding controls must be designed as access governance, not product usability.

Context-aware developer tooling widens the identity blast radius. A documentation server, a database connector, and a browser automation server each bring different trust assumptions into the same session. Once those systems are chained together, the effective privilege surface is larger than any single connector suggests. The practical takeaway is that MCP governance has to follow the chain of access, not the label on the first tool.

Ephemeral usage signals do not eliminate the need for durable governance. Stable week-over-week adoption is the important finding here because it shows the protocol is becoming operational infrastructure rather than a demo artifact. That changes the control expectation from pilot oversight to lifecycle management, recertification, and least-privilege discipline across connected services. Practitioners should treat MCP as something that will need ongoing ownership, not one-time enablement.

Context assembly is the named concept here, and it is what makes MCP security different. MCP servers do not merely expose an API. They assemble live context from multiple systems into a single working session, which expands the identity and data boundary at runtime. The implication is that teams need to understand the governance of assembled context, not just the security of each individual integration.

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.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the same research.
• For a broader view of how AI-connected tooling changes identity governance, see OWASP Agentic Applications Top 10.

What this signals

Context assembly is becoming the operational pattern to watch. As MCP servers bring documentation, database, browser, and project context into one working session, identity teams need to govern the assembled access path rather than each connector in isolation. That means ownership, scope review, and revocation have to follow the session boundary, not just the service boundary.

The adoption signal is durable, not episodic. Once a developer protocol moves from demo use to weekly operational use, the programme shifts from experimentation to lifecycle management. Teams should prepare for recertification, consent review, and offboarding controls that can keep pace with developer tooling that is now part of day-to-day delivery.

AI-connected tooling is exposing a familiar non-human identity pattern in a new form. When convenience lowers the barrier to access, governance usually trails usage. The practical response is to bring MCP servers into the same control set used for other non-human identities, including scope control, credential hygiene, and periodic access review.

For practitioners

• Map every MCP connection to an identity owner Assign a named business and technical owner for each MCP server, including the OAuth client, underlying service account, and downstream systems it can reach. Review ownership whenever the tool or data source changes.
• Review OAuth scopes before broad rollout Compare each MCP server’s granted scopes with the minimum data and action set required for its job. Remove broad, inherited, or rarely used permissions and require reapproval for scope expansion.
• Track connected context as a governed asset Record which documentation, repository, database, and browser sources each MCP server can assemble into a live session. This makes it possible to recertify access against actual usage rather than assumed intent.
• Build offboarding into MCP lifecycle controls Revoke MCP access when a team, workspace, or use case changes, and verify that cached credentials, app consents, and service tokens are actually removed from the connected environment.
• Separate experimental servers from production paths Keep new MCP integrations isolated until their permissions, data flows, and logging are understood. That prevents a convenience feature from becoming an unmanaged production dependency.

Key takeaways

• MCP is no longer just a developer protocol. It is an identity governance surface because every connected server inherits permissions, data access, and revocation risk.
• The adoption pattern is being driven by reduced friction and richer context, which means governance gaps will widen fastest where onboarding is easiest.
• Practitioners should manage MCP servers like other non-human identities, with named ownership, scoped access, and lifecycle controls from the start.

Key terms

• Model Context Protocol: A protocol that lets applications, assistants, and developer tools connect to external systems and context sources. In identity terms, it creates a governed access path into data and tools, so the security question is not only connectivity but who can authorise, scope, and revoke that access.
• Context assembly: The act of combining live data from multiple systems into a single working session or tool context. This matters because it expands the effective trust boundary at runtime, making the session itself the unit of governance rather than any one connector or endpoint.
• MCP server: A service that exposes external capabilities or data sources through the Model Context Protocol. For security teams, each server behaves like a non-human identity boundary because it can hold credentials, inherit scopes, and transmit access into downstream systems.
• OAuth consent scope: The set of permissions an application receives when a user or service authorises access through OAuth. In practice, scope quality determines how much power a connected tool gains, so broad consent can turn a convenient integration into an over-privileged identity.

Deepen your knowledge

MCP server governance and non-human identity lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your teams are connecting developer tools to live systems, the course is a practical next step.

This post draws on content published by WorkOS: MCP Night 2.0 Demo Recap on how Cursor users are embracing the Model Context Protocol. Read the original.