The MCP identity layer: how buy-side firms are solving user-level entitlement when agents call expert-network endpoints

By mid-2026, the interesting question about expert-network MCP connectors is no longer whether they exist. Guidepoint, GLG, AlphaSense, FactSet, and Aiera have all shipped MCP endpoints exposing transcript libraries or research content into Claude, Perplexity, and Bloomberg agent surfaces. The content is wired up. The binding constraint has moved one layer down, into identity: when an analyst's agent calls a Guidepoint server to pull a transcript, which seat-licensed user is actually asking, what are they entitled to see, and whose audit trail does the call land in.

Our read is that the identity layer, not the content layer, is what will determine whether MCP graduates from demoware to a production workflow inside a buy-side firm. Expert-network contracts are priced per seat and audited per user. A shared service-account token collapses both of those. The commercial model and the compliance model both live or die on per-user identity propagation, and the reference pattern for that propagation is now OAuth 2.1-based delegated authorization, added in the March 2025 spec revision and refined again in June 2025.

Why identity became the binding constraint

For most of 2024 and the first half of 2025, the interesting engineering question about MCP was whether vendors would expose their content at all. That question is now closed for the top of the expert-network and financial-data market. Anthropic's own integrations catalog lists dozens of enterprise-grade MCP servers, and the expert-network cohort is over-represented in that list relative to its share of the software market. The reason is straightforward: transcript libraries and analyst research are, structurally, exactly the kind of retrieval workload that agent surfaces are good at, and vendors read the demand signal early.

What the first wave of demos hid, and what production deployments have surfaced, is that content retrieval is the easy half. A transcript request from Claude Desktop, sent to a Guidepoint MCP endpoint, has to answer four operational questions before it is allowed to return a payload. Which human is behind this call. What is that human's entitlement scope inside the vendor's system. Is the request logged against that human's per-seat audit trail. And can the vendor cut off access when the human leaves the firm or the seat is reassigned. None of those questions are answerable if the host and the server share a single service-account API key, which is how most pre-MCP integrations were wired.

The compliance dimension is not theoretical. Expert-network compliance teams exist specifically to keep a per-user audit trail of who consumed which transcript, what questions were asked, and whether MNPI screening applied. That trail is the artifact a regulator or an internal review team asks for during a review. If a hedge fund's analyst tier is fronted by an agent using a shared token, the vendor has no way to attribute the request to a person, the fund has no way to attribute the request to a seat, and both sides of the contract lose the audit primitive their compliance frameworks assume. The MCP identity problem is a compliance problem wearing a protocol hat.

What the OAuth 2.1 baseline actually specifies

The March 2025 MCP spec revision was the first to formalize authorization, and the June 2025 update is the current reference. The design decision worth noticing is that MCP does not invent its own auth model. It profiles OAuth 2.1 and delegates the hard parts to the existing OAuth ecosystem, which is the correct call given the maturity gap between MCP hosts and the OAuth libraries already deployed inside enterprise identity stacks.

The baseline requires that MCP servers acting as OAuth resource servers support authorization-server metadata discovery, that clients support the authorization code flow with PKCE, and that access tokens carry the scopes needed to enforce entitlements at the resource server. In practice, this means the flow looks like a standard third-party SaaS OAuth handshake. The analyst opens Claude Desktop, adds the Guidepoint connector, and is redirected through Guidepoint's authorization server, which in a buy-side deployment is itself federated to the firm's identity provider. Once the analyst authenticates, Claude Desktop receives a scoped access token bound to that human's seat. Every subsequent MCP call carries the token, and Guidepoint's resource server enforces entitlements and logs the call against the correct user.

Two pieces of the June 2025 revision matter more than they initially read. The first is dynamic client registration, which allows an MCP host to register itself as an OAuth client with a resource server it has never seen before, without a human at the vendor manually provisioning client credentials. Without dynamic registration, every new host-server pair requires a support ticket, which does not scale when a buy-side firm is wiring five to ten connectors across three hosts. The second is the resource-indicator parameter, which lets the client explicitly declare which resource server the token is intended for. This closes a class of token-confusion attacks where a token issued for one MCP server could be replayed against another, and it is the piece of the spec that lets a security team sign off on an architecture where a single authorization server fronts multiple resources.

Where the spec is still soft

The spec does not prescribe how scopes should be named, which entitlements a vendor should expose, or how token refresh should behave across long-running agent sessions. Those are vendor-by-vendor decisions, and they are where the current variance lives. Guidepoint's scope model for transcript access does not look the same as FactSet's scope model for a research feed, and Claude Desktop's handling of a refresh token does not look the same as Perplexity's. The spec gives everyone the same handshake; the semantics of what a token authorizes remain a vendor concern.

The vendor implementation gap

The interesting variance across the five vendors named above is not whether they support OAuth. It is how cleanly their entitlement scopes map onto the seat and product tiers the buy-side already pays for.

An expert-network transcript library has a natural entitlement grain. A firm's contract covers a set of industries, a set of geographies, a per-seat call quota, and sometimes a per-project scope tied to a specific research theme. Exposing those as OAuth scopes is not conceptually hard, but it requires the vendor to have already modeled entitlements as first-class objects rather than as rules buried in a billing system. Vendors whose entitlement engine was already API-addressable, because they built one to power their web app, are shipping cleaner MCP scopes. Vendors whose entitlement logic lives inside a monolithic web application are shipping coarser scopes and pushing more enforcement to their resource server at query time.

FactSet is the interesting case here because the underlying product surface already has to model entitlements across a wide catalog of datasets sold in different combinations to different clients. That entitlement engine can be reused. An expert network shipping its first machine-readable entitlement API alongside an MCP endpoint is doing more net-new work, and the scope model tends to be coarser as a result. The prediction we would make is that the vendors with a mature developer platform, meaning documented REST APIs, existing OAuth flows, and an entitlement engine that is already an API surface, will ship the deeper MCP integrations, because they are reusing plumbing rather than inventing it.

The host side has its own variance. Claude Desktop, Perplexity, and Bloomberg's agent surfaces each implement the OAuth handshake slightly differently, especially around how they handle multiple simultaneous connectors, how they surface consent screens to the user, and how they persist refresh tokens across host restarts. None of these are protocol violations; they are the kind of implementation-detail drift that always shows up when a spec is new and library support is still maturing. The operational cost lands on the buy-side IT team asked to support all three hosts and all five to ten connectors.

How buy-side IAM teams are absorbing the load

The response inside buy-side identity and access management teams is the interesting operational story of 2026. MCP connectors are being classified, correctly, as a new category of SaaS integration, and the governance treatment is starting to look like what Slack, Salesforce, and Zoom got when they went from shadow-IT adoption to sanctioned enterprise tools.

That means three things in practice. First, MCP connectors go through the same third-party risk review as any other SaaS vendor, which is a slow process and is why some deployments that look ready on the vendor side are still queued inside their prospective customers. Second, SCIM provisioning is being demanded, so that when a seat is created or revoked in the firm's identity provider, the change propagates to the MCP vendor's entitlement system automatically rather than through a support-ticket workflow. Third, audit-log coverage is being extended: the firm's security operations team wants to ingest MCP call logs into the same SIEM that already ingests Slack and Salesforce logs, and vendors without a streaming audit-log API are being asked to build one.

The SSO story is the piece that is dragging the longest. In the reference deployment, the vendor's OAuth authorization server is federated to the customer's identity provider, so the analyst signs in once with their firm credentials and receives tokens for every connector. In the current deployment, several vendors are still requiring a separate credential on their own domain, and buy-side IT teams are pushing back hard, because the whole point of the identity investment is single sign-on and centralized deprovisioning. Our read is that federated SSO will become table stakes for MCP connectors sold into the buy-side within the next four quarters, and vendors who cannot support SAML or OIDC federation to a customer's identity provider will lose deals to those who can.

The commercial second-order effects

If the identity layer is where the differentiation is landing, three commercial consequences follow.

The first is that per-seat pricing survives the transition to agent workflows, which is not a given. There has been an open question in the expert-network market about whether agent-mediated access breaks the seat model, because an agent can plausibly serve a whole team from one credential. OAuth-based delegated auth, correctly implemented, resolves the question by binding every call to a human. The seat model survives because the audit primitive survives. Vendors who ship clean per-user auth are protecting their pricing model, not just their compliance story.

The second is that the vendor selection criteria the buy-side applies to MCP connectors is starting to look like the criteria applied to any enterprise SaaS: SSO federation, SCIM provisioning, audit-log streaming, scoped access tokens, and a security questionnaire that passes a third-party risk review. Content quality is necessary and no longer sufficient. Two vendors with comparable transcript libraries will be differentiated on identity and governance plumbing, and the one that ships SAML federation and a streaming audit-log API will win the enterprise deal.

The third is that the host layer becomes an identity broker. Claude Desktop, Perplexity, and Bloomberg's agent surface each hold refresh tokens for every connected MCP server their user has authorized, which makes them a concentrated identity surface inside the firm. Security teams are noticing. Our expectation is that the next iteration of the MCP spec, or a vendor-side profile of it, will address host-side token storage, hardware-backed key protection, and admin-level revocation of host-held tokens. The current reference pattern is workable for individual power users; it is not yet the pattern a CISO wants for an eight-thousand-person hedge fund.

Three scenarios for how the identity layer settles

The base case is that OAuth 2.1 with dynamic client registration and resource indicators becomes the settled standard by end of 2026, and the interesting variance moves entirely into scope semantics and audit-log surface. The buy-side gets what it wants: federated SSO, SCIM provisioning, and centralized deprovisioning across every MCP connector. Vendors with mature developer platforms ship the cleanest integrations. The market bifurcates between vendors who treat MCP as a first-class product surface and vendors who ship a minimum viable endpoint and lose enterprise deals on the governance questionnaire.

The bull case for the standard is that a common entitlement scope vocabulary emerges, at least within a vertical. Expert networks converge on a shared taxonomy for industry, geography, and per-project scopes. Financial data vendors converge on a shared taxonomy for dataset entitlements. Buy-side IAM teams can then write a single SSO federation and SCIM policy that applies across vendors, rather than integrating each one bilaterally. This is the outcome we would bet on over a two-year horizon if the vendor community organizes around an industry working group; without one, it drifts.

The bear case is that host implementations diverge enough that the OAuth handshake becomes a de facto per-host contract, and vendors end up maintaining separate MCP profiles for Claude, Perplexity, and Bloomberg. That fragments the developer experience, doubles the integration work for vendors, and pushes the buy-side back toward host-specific deployments rather than a portable identity layer. This outcome is possible if the spec working group moves slowly and the hosts prioritize product velocity over conformance.

Questions a research analyst should be asking now

When an analyst evaluates an expert-network or data vendor's MCP posture, the content questions are the wrong opener. The questions that separate a production-ready vendor from a demoware vendor are:

• Does your MCP server support OAuth 2.1 with dynamic client registration, and can it federate to our identity provider via SAML or OIDC?
• Do your OAuth scopes map to the entitlement grain in our contract, meaning industries, geographies, and per-seat quotas, or is enforcement happening opaquely at the resource server?
• Do you support SCIM provisioning, so that a seat revoked in our identity provider is revoked in your entitlement system within minutes rather than days?
• Do you expose a streaming audit-log API that we can ingest into our SIEM, and does every MCP call carry the user identity, timestamp, and scope used?
• What is your posture on the resource-indicator parameter, and how do you prevent token replay across your MCP server and any other endpoints you operate?

The vendors who can answer those five questions cleanly are the ones whose MCP endpoints will still be running inside the buy-side in eighteen months. The rest are pilots.