DEV Community

kirandeepjassal-crypto
kirandeepjassal-crypto

Posted on • Originally published at prepstack.co.in

MCP Deep Dive, Part 11: The Protocol Was Never the Blocker — Rolling MCP Across the Enterprise

#mcp #enterprise #ai #dotnet

There are already tens of thousands of MCP servers in the world. Getting even one of them into a real company still tends to mean per-user OAuth, a consent screen, and an IT ticket — per connector, per employee. That's the actual blocker, and it was never the protocol. It's identity.

This is Part 11 of a 15-part deep dive on Model Context Protocol (MCP). Everything so far — the server, the client, tools, auth, authorization, security, streaming, observability — was about making MCP work. This part is about making it ship company-wide, which is a different problem entirely: identity, provisioning, and governance.

TL;DR

Concern Ad-hoc MCP (before) Enterprise MCP (after)
Access to a connector per-user OAuth + IT ticket provisioned once, inherited on login
Which servers are allowed whatever a dev wires up one vetted catalog
Third-party servers trusted blindly reviewed + checksum-pinned
Policy scattered per agent provisioned via IdP groups
Cost / data ungoverned budgets + DLP + residency + audit
Rollout big-bang staged by risk tier, platform-owned

The enterprise MCP architecture 

                    Identity Provider (Entra / Okta)
                    admins provision connectors -> groups
                                   |
                           (login: inherit connectors + scopes)
                                   v
Agents (every team) --> [ ORG MCP GATEWAY / BROKER ] --> approved MCP servers
                          - auth (IdP tokens)             (from the VETTED CATALOG)
                          - catalog / entitlements         mattrx-analytics
                          - policy (group -> scopes)       mattrx-reports
                          - budgets + DLP + residency      partner-crm  (pinned)
                          - org-wide audit                 docs-search  (pinned)
Enter fullscreen mode Exit fullscreen mode

1. Enterprise-Managed Authorization — provision once, inherit on login

Every employee, for every connector, doing per-user OAuth behind an IT ticket doesn't scale: onboarding 500 people to 20 connectors is 10,000 individual grants and a permanent queue. Instead, an admin provisions the connector once in the IdP and assigns it to a group. On login, employees inherit the connector and its scopes — no ticket, no consent, no per-user OAuth.

// Admin action, ONCE: grant a connector to a group with a scope set, in the IdP.
public sealed class ConnectorProvisioning(IIdentityProvider idp, IMcpCatalog catalog)
{
    public Task ProvisionAsync(string connectorId, string group, IReadOnlySet<string> scopes)
        => idp.AssignAppRoleAsync(connectorId, group, scopes);

    // At login: the employee's token already carries the connectors + scopes their groups grant.
    public IReadOnlyList<GrantedConnector> ForUser(ClaimsPrincipal user)
        => catalog.ResolveGrants(user.Groups());   // inherited, not requested
}
Enter fullscreen mode Exit fullscreen mode

The employee's real dependency was never the connection — it's an identity and a policy, provisioned centrally and inherited on login. Enterprise-Managed Authorization turns "a ticket plus a per-user OAuth per connector" (days) into "log in and it's there" (seconds). Revoking access is removing a group membership, not chasing down a token.

2. A central MCP catalog, not a free-for-all

At org scale, an ungoverned connector is shadow IT with a network route into your data. One org catalog of vetted connectors — agents get their entitled toolset from the registry, never from whatever a developer decided to wire up.

// One org catalog of approved connectors. Agents are entitled to a subset by group membership.
public sealed class McpCatalog(ICatalogStore store) : IMcpCatalog
{
    public async Task<IReadOnlyList<ConnectorRef>> EntitledAsync(AiPrincipal p, CancellationToken ct)
        => (await store.ApprovedAsync(ct))
            .Where(c => p.Groups.Overlaps(c.AllowedGroups))   // approved AND entitled
            .ToList();
}
Enter fullscreen mode Exit fullscreen mode

"What can our agents reach?" becomes a query against the registry, not a survey of every team.

3. Vet and pin third-party servers

A public MCP server is untrusted code returning untrusted data, now inside your agent loop. A server enters the catalog only after a security review and a checksum pin (the rug-pull guard from Part 8), tiered by risk.

// A third-party server is admitted only after review + a pinned checksum.
public async Task<AdmissionResult> AdmitAsync(ExternalServer server, CancellationToken ct)
{
    var review = await security.ReviewAsync(server, ct);         // data access, egress, license, residency
    if (!review.Approved) return AdmissionResult.Rejected(review);

    var pin = await Checksum(await server.ListToolsAsync(ct));   // pin tool defs (rug-pull guard, Part 8)
    await catalog.AdmitAsync(server, pin, review.Tier, ct);
    return AdmissionResult.Admitted(pin);
}
Enter fullscreen mode Exit fullscreen mode

A changed tool definition pulls the connector for re-review instead of silently reaching every agent. The per-agent rug-pull guard from Part 8 becomes an org admission process.

4. Provision the policy through the IdP

Part 7 built the identity-and-policy per agent; Part 11 provisions it at org scale. A user's IdP group maps to the scopes their agents inherit.

IdP group           ->  inherited connector scopes
---------               --------------------------
"Analysts"          ->  { campaigns:read, events:read }
"Report Editors"    ->  { campaigns:read, reports:create }
"Admins"            ->  { admin:flags } + step-up

Change the group, change the policy — for everyone in it, instantly, from one place.
Enter fullscreen mode Exit fullscreen mode

Move someone to a new team, and their agents' permissions follow — no ticket, no deploy. One edit, org-wide, audited (Part 10), reversible in seconds.

5. Govern cost, data, and audit at the platform

An enterprise will not ship agents it cannot govern. Governance is a platform capability: per-team token budgets, DLP and data-residency rules per connector, and one org-wide audit.

// Governance is a platform capability, not a per-team afterthought.
gateway.SetTeamBudget(team, monthlyTokens);          // cost governance
gateway.RequireRegion(connector, allowedRegions);    // data residency
gateway.RequireDlp(connector, dlpProfile);           // redaction / DLP
// Every call across every connector lands in one org-wide audit (Part 10).
Enter fullscreen mode Exit fullscreen mode

Per-team budgets stop runaway spend, residency keeps regulated data in-region, DLP stops sensitive data leaving, and the org-wide audit answers "who did what." Governance is precisely what turns a promising pilot into a company-wide rollout — and its absence is why so many pilots never graduate.

6. Roll out by risk tier, not big-bang

"Turn on MCP everywhere" fails the way every big-bang does — the first incident freezes the whole program. Instead, a platform team owns the shared gateway and catalog; connectors roll out by risk tier.

Tier 1 (read-only, low-risk)   -> analytics, docs, search       -> broad, self-service
Tier 2 (write, reversible)     -> create report, update ticket  -> scoped groups + audit
Tier 3 (destructive/regulated) -> admin, finance, PII           -> step-up + review + narrow groups

Platform team owns the gateway + catalog; teams self-serve WITHIN the guardrails.
Enter fullscreen mode Exit fullscreen mode

Governance first, breadth second. Low-risk read-only goes broad so value shows up fast; write and destructive stay gated by scoped groups, step-up, and review.

The numbers, in one place

Concern Ad-hoc MCP (before) Enterprise MCP (after)
Connector onboarding IT ticket + per-user OAuth (days) inherited on login (seconds)
Approved-server visibility unknown / shadow IT one vetted catalog
Third-party trust blind reviewed + checksum-pinned
Policy changes per-agent config + deploy IdP group edit, org-wide
Cost / data governance none budgets + DLP + residency
Audit scattered one org-wide trail

The model to carry forward

Connectors were the easy 80%; identity, policy, and governance are the 20% that decide whether agents ship inside a company at all. Provision the identity-and-policy once through your IdP and let employees inherit it on login. Put every connector behind one governed gateway and one vetted catalog. Govern cost, data, and audit as platform capabilities. Then the protocol — the part everyone obsesses over — really does become the easy part.

Three habits that make MCP ship enterprise-wide:

  1. Provision identity + policy centrally through the IdP. Once, inherited on login — never per-user, per-connector.
  2. Put a vetted catalog and a governed gateway between agents and servers. No ad-hoc connections, no unreviewed servers.
  3. Roll out by risk tier with a platform team. Read-only broad, destructive gated, self-service within guardrails.

Originally published at prepstack.co.in. Part 12 comes back down to the code: building MCP servers in C# and .NET 9.

Top comments (0)