Scoped MCP Design for Enterprise Teams

What MCP is and why enterprises are adopting it now

Before November 2024, every AI-to-tool integration was bespoke. You wanted a model to call an API, you built a connector. Different model, different connector. Different tool, start over. The combinatorial overhead was staggering, and integration work crowded out capability work.

MCP, the Model Context Protocol, solved that structural problem with a universal, stateful, bidirectional interface built on JSON-RPC 2.0. Any compliant client talks to any compliant server. Write the server once; any conformant AI client can use it. The protocol handles transport, tool discovery, and the invocation contract. You handle the logic.

Adoption has been steep. Anthropic reported server downloads climbing from roughly 100,000 in November 2024 to over 8 million by April 2025, with more than 5,800 servers available in that window. This is no longer a developer experiment.

In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, with AWS, Google, Microsoft, Salesforce, and Snowflake as founding backers. That move transformed MCP from a vendor-controlled specification into a multi-stakeholder standard, which matters enormously for enterprise procurement teams making long-term commitments. Forrester's 2026 predictions projected that 30% of enterprise application vendors would ship their own MCP servers that year. The supply side is accelerating. Organizational infrastructure needs to catch up.

How MCP servers went from personal tools to shared enterprise infrastructure

The first generation of MCP servers was built for single-player workflows. Local tools, desktop agents, personal automation. One developer, one machine, low stakes.

That phase is over. Servers are now remote, shared, and connected to production systems: live logs, analytics pipelines, cost tooling, customer data. The infrastructure went enterprise before the design patterns caught up, and that gap is where most of the damage happens.

The rush to ship produced servers that work convincingly in demos and break quietly in production. What the demos don't surface is the structural problem: MCP has no native role-based access control. If an agent can connect to a server, it can discover every tool that server exposes. There is no built-in mechanism to show the finance agent only finance tools, or to hide database administration endpoints from the support agent. Least-privilege access has to be implemented outside the protocol, in every deployment individually, or it simply doesn't exist.

This is the design gap that causes most enterprise MCP failures. The protocol itself is not immature. It fails when authorization and auditability are treated as afterthoughts rather than first-order requirements — which they almost always are when teams are racing to ship.

What the MCP specification now requires for authentication and why it still isn't enough

The March 2025 specification update introduced OAuth 2.1 support. The November 2025 version, designated 2025-11-25, formalized it as the standard for remote servers. That is a genuine maturation of the protocol's security posture.

The November spec also changed how client identity works. The default shifted from Dynamic Client Registration, which required authorization servers to maintain a registration database, to Client ID Metadata Documents. Under the new model, client identity is a URL pointing to a JSON document; the authorization server fetches metadata on demand. At scale, that is a meaningful operational improvement, though it introduces its own fetch-time failure modes worth monitoring.

The hard requirements in the November spec are specific: PKCE with S256 code challenge is mandatory, all endpoints must use HTTPS, the implicit flow is deprecated, and token passthrough is explicitly prohibited. That last item warrants a moment. When an MCP server calls an upstream API on behalf of a client, it must obtain its own token as an OAuth client rather than forwarding the client's token. Passing through the client's token creates a confused-deputy vulnerability, where the upstream system cannot distinguish between the MCP server acting on its own authority and the MCP server proxying someone else's credentials. The spec closes that hole explicitly.

What the spec does not solve is tool-level authorization. OAuth 2.1 operates at the server level: a client either has access to a server or it does not. Scope conventions for individual tools are not standardized in the MCP authorization specification. That undefined space is exactly where excessive agency vulnerabilities live. The specification provides an authentication floor; everything above it — which teams see which tools, which agents invoke which actions — is the enterprise's design responsibility. Nobody hands that to you.

How Enterprise-Managed Authorization changes who controls access decisions

Standard MCP authentication is user-scoped. Every employee authorizes every server individually. Security teams cannot enforce consistent policy centrally. Work and personal accounts blur together. At organizational scale, this produces an authorization sprawl that is effectively unauditable.

Enterprise-Managed Authorization, stable as of June 2026, addresses this by making the organization's identity provider the authoritative decision-maker. Administrators define policy once. Users authenticate with their existing organizational identity into the MCP host. The individual per-server consent screen disappears from the user's experience, because the enterprise has already made that decision at the policy layer.

The mechanism works through an Identity Assertion JWT Authorization Grant obtained from the IdP during single sign-on, which the client exchanges for an MCP access token. The IdP evaluates group membership, role, and conditional access rules before granting or denying. Enforcement is centralized, not distributed across individual agents. Okta is the first supported IdP via Cross App Access; servers supporting EMA at launch include Asana, Atlassian, Figma, Linear, and Slack. Anthropic implemented EMA in Claude; Visual Studio Code added IDE support.

The MCP access token under EMA is not an identity token and not a session proxy. It represents authentication already completed upstream, expressed as explicit, time-bound permissions the server can verify locally. What flows is a structured claim about what that identity is permitted to do, issued by an authoritative source and scoped to a specific window. That design is both more secure and more governable than the alternative — and the direction any serious enterprise deployment should be moving.

Why a single ungoverned registry creates both security and duplication problems

OWASP's Top 10 for LLM Applications identifies excessive agency as one of the most critical risks in agentic systems. The root causes map directly to ungoverned MCP deployments: tools the agent doesn't need, permissions broader than the task requires, and high-impact actions taken without human oversight.

The security failure is straightforward. In a single shared server without explicit scoping, a customer support agent discovers ERP write endpoints it was never meant to reach. Not because anyone granted access. Because nothing denied it. The absence of an explicit boundary is not neutral; it is an implicit grant.

The duplication problem is less dramatic but equally costly. Without a governed registry, five teams independently rebuild the same integration. The same prompt logic gets written five times. The same OAuth edge cases get solved five times, usually badly. Engineering time goes to repeat work rather than new capability, and nobody on team six knows that teams one through five already solved this.

A team that can't trust the shared registry won't use it. A registry that no one trusts accumulates shadow implementations scattered across team repositories. Those shadow implementations are ungoverned by definition, which creates more security exposure, which further erodes trust in the central registry. You end up with more risk and more duplication simultaneously, and each compounds the other. Breaking that cycle requires deliberate scope design before the first agents go into production — not after the second incident.

How to scope an MCP server at the team boundary

Scope design is a contract. It defines what a client may request and what a server will execute. Each MCP method corresponds to one or more scopes, making authorization explicit and enforceable at the method boundary. The client declares what it needs; the authorization layer evaluates that declaration against enterprise identity and policy before issuing a token. The client does not decide what it is allowed to do — the policy layer does.

The most tractable implementation pattern is virtual servers at the team boundary. A finance team accesses ERP functionality through a read-only virtual server scoped to their workflows. An operations team works in a separate environment connected to supply chain tooling. Neither team can see or invoke the other's tools, not because of runtime filtering, but because the server they connect to never exposed those tools to them. The boundary is structural, not enforced at runtime.

There is a cohesion principle that governs the right shape of a server. Grouping everything from one system into one server feels efficient, but it creates a reliability problem alongside the security problem. When a single server handles sales workflows, support tickets, and administrative operations, the same request can map to multiple valid interpretations, and the model chooses between them probabilistically. The fix is not a better model; it is fewer, clearer tools with unambiguous scope.

An emerging pattern reinforces this further: session-scoped authorization, where access is time-limited to a specific task's duration. When the session ends, access ends. The agent cannot renew on its own authority. A human must explicitly approve a new session. That design makes the agent's scope of action legible and auditable at every point in its lifecycle, which looks like overhead until you need it in a post-incident review.

Tool-level RBAC and why OAuth alone doesn't provide it

Production agents in mature deployments connect to dozens of MCP servers exposing hundreds of tools. Most setups still rely on a single credential that grants access to everything in the connected fleet. That is not an access control architecture; it is the absence of one.

Tool-level role-based access control binds each agent to a narrow allow-list of specific tools rather than to a server, a session, or a static API key. The mechanism for this in governed deployments is the MCP Tool Group: a named policy bundling specific tools from multiple MCP servers, resolved at the request layer rather than at the server layer. Think of it as a security group for AI agents, operating on the same conceptual logic as network security groups in infrastructure design. You define what the entity is allowed to reach, not what everything it can connect to happens to expose.

The design principle that makes this work in practice is restraint. When multiple tools look similar, the model chooses between them probabilistically. Providing three slightly different database query tools does not give the agent flexibility — it gives it ambiguity, and ambiguity in agentic systems produces inconsistent and sometimes dangerous behavior. Fewer, clearer tools with unambiguous scope is simultaneously a user experience decision and a security decision.

MCP servers are reasoning interfaces, not execution interfaces. They present structured choices to a reasoning system. The quality of those choices — their clarity, their cohesion, their bounded scope — determines the quality of what the reasoning system can do. A bloated tool surface doesn't make an agent more capable. It makes the agent's decision space harder to govern and harder to audit.

The MCP gateway as a central enforcement point for multi-team deployments

Without a gateway, every agent manages its own connections and credentials. There is no central point of enforcement, no unified audit log, no coherent policy surface. At small scale that is tolerable. At organizational scale it becomes untenable — usually when your security team asks for an audit trail and you realize you can't produce one.

A gateway centralizes authentication, enforces access control, logs every tool invocation, and provides a single choke point for policy enforcement. The architectural value is that you can reason about what your agents are doing at the organizational level, not just the individual agent level.

AWS AgentCore Gateway uses a Cedar-policy engine that evaluates every tool request before execution, with deny-by-default semantics. The absence of an explicit grant is a denial, not a gap. Microsoft Copilot Studio currently enforces data loss prevention at the whole-server level for MCP servers: an allowed server exposes its full tool surface to the agent, and per-tool blocking is on the roadmap but not yet available, according to Microsoft's Copilot Studio documentation. The practical implication today is that narrower-surface servers carry lower risk in Copilot Studio deployments. For Azure-based organizations, Entra ID integration with managed identities eliminates manual OAuth 2.0 token management entirely, removing credential rotation from the operational burden.

At RSA Conference 2026, Cisco announced dedicated MCP security tooling. That is a signal worth noting: the "this is just a developer tool" phase has formally ended. Enterprise security vendors are treating MCP as production infrastructure, which means the governance and enforcement tooling is maturing in parallel with adoption.

Gateway logging is where the accountability picture comes together. For any given invocation, teams need to be able to show who triggered it, whether the agent acted within policy, and how permissions propagated across systems. Without a gateway, reconstructing that picture from distributed agent logs is both difficult and unreliable.

Multi-tenant MCP servers and what isolation actually requires

Multi-tenancy in MCP means a single server instance serving multiple customers, with each customer's credentials, data, and tool access isolated from every other customer's. The economics are compelling: running a shared server across many tenants versus running single-tenant instances at equivalent scale can differ by an order of magnitude or more in cost before operational overhead. That cost pressure is real, and it's why multi-tenant architectures are attractive. It is also why isolation requirements have to be taken seriously from the start, not retrofitted after the first incident.

Three properties must hold simultaneously. Tenant isolation: a token issued to one customer cannot read another customer's data under any code path. Credential opacity: the model and the client never see raw API tokens; the server handles upstream authentication internally. Scope enforcement: tools are constrained to what the customer's authorization and plan actually permit, not what the server technically exposes. All three, all the time. Let one slip and you have a problem; let two slip and you have a breach.

The failure modes are specific. Insufficient access controls on underlying data stores let one tenant's queries return another's results. Context sharing across invocations leaks a prior tenant's data into the current session. Vector database queries without enforced tenant-ID filters return embeddings from across the tenant population. Tool outputs that aggregate results across tenant boundaries are a particularly insidious failure: the output looks correct but contains information from multiple tenants that no single tenant should see. That last one surfaces in production rather than in testing — exactly the wrong place.

The token passthrough prohibition from the specification is especially critical in multi-tenant deployments. Confused-deputy vulnerabilities in multi-tenant contexts don't just expose a single credential; they create paths for cross-tenant data access. The spec's explicit ban closes the most common version of that vulnerability. The rest of the isolation surface is the implementer's responsibility, and there is a lot of isolation surface.

What a governed MCP registry looks like when scoping is done right

A governed registry is the organizational answer to both failure modes at once. Skills captured once, published with explicit permissions, discoverable by any team that has access. Not rebuilt department by department. Not scattered across repositories nobody else knows exist.

Every entry in a governed registry carries its scope definition: which teams can call it, which tools it exposes, which actions require human approval before execution. Permissions are inherited from the connected data sources, so when someone queries an agent, the answer draws only from what that person already has access to. No manual redefinition is required when a new team onboards. The access model follows the identity model.

Version control is not optional. Every change to a registered skill is tracked. Rollback is possible. Audit trails show which version of a skill was running at the time of any specific invocation. When something goes wrong in production — and something will go wrong in production — you need to be able to reconstruct the exact state of the system at the moment of the incident. A registry without version control cannot provide that. Regulators in most industries will eventually ask for it, and the answer "we don't track that" is not an answer they will accept.

The security case and the efficiency case are the same case. A narrowly scoped, well-labeled skill in a shared registry is safer because it presents a smaller attack surface and has clear ownership; it is also more reusable because it is findable, documented, and trusted enough for other teams to build on. Five ad-hoc implementations scattered across team repositories are neither safe nor efficient. They are technical debt accumulating interest in two directions simultaneously.

Treating scope as a configuration detail rather than an architectural decision is the mistake that compounds with every server added to the fleet. The boundary you draw around what an agent can see, call, and share is the foundational governance decision in any agentic deployment. Get it wrong at the start and you spend the next six months unwinding it — while your fleet keeps growing and the unwind gets harder.