MCP has great potential. Let’s enable enterprises to enforce policy
Although the Model Context Protocol (MCP) has garnered tremendous interest from the enterprise AI community, widespread enterprise adoption still remains scant because of concerns mainly related to enforcing policy. For example, the MCP standard recommends the use of OAuth, and does not specify which options within OAuth should - or must - be used. Enforcing such policies to ensure basic access security is critical to assurances that enterprises need in order to unlock the power represented by LLMs in combination with enterprise data. With such integration, one can easily envision a future where autonomous AI bots are able to do a large part of basic tasks that, today, we rely on humans for. To be sure, I am not commenting here on the societal impact of such a transformation, but the technology potential is already here, and so I’m only arguing that if / when it is adopted, it needs to be done in a safe manner.
MCP currently provides an authorization specification that recommends OAuth 2.1 with certain options like Dynamic Client Registration (DCR). However, its broad applicability makes it difficult for the core specification to restrict options that might be unsafe in enterprise scenarios involving sensitive data. For example:
Profiles is a proposed way of addressing these concerns. A profile is simply a specification of behaviors and properties. It exists at a “Profile Specification URL”. An MCP server advertises the profiles it can support at a “well known” location. The MCP client can optionally consult the server’s supported profiles, and request a certain set of profiles to be used in a session. The MCP server finally specifies the profiles it will use during the session in the response. If the client and server cannot agree on a set of profiles to be used, the initialization of the session fails. This is described in detail in the Profiles “Specification Enhancement Proposal” (SEP) here.
To demonstrate how it can solve the problem, let’s consider a couple of use cases.
Assume a large enterprise named “Wholesale Chips” wants to ensure that all MCP servers they use, including those that are developed by third-party SaaS vendors need to follow certain security rules. For this purpose, they define a “Require Client Credentials” profile as shown in the appendix of this blog. Since this profile is specific to their enterprise, it is hosted at a Profile Specification URL within the Wholesale Chips domain (i.e., at, say: https://wholesalechips.co/mcp-profiles/require-client-credentials).
Any MCP server that is able to support this profile, must declare support for it (and optionally other profiles it supports) in their well-known profile metadata document as follows:
[
{
"profileURL": "https://wholesalechips.co/…/require-client-credentials",
"minMcpVersion": "2025-08-13"
},
{
"profileURL": "https://modelcontextprotocol.io/…/another-magical-profile",
"minMcpVersion": "2026-01-01"
}
]
Wholesale Chips then deploys MCP clients that are configured to request this profile whenever they connect to any MCP server. If the server cannot support this profile, the MCP client will drop the connection, and not use the server. So all connections from the MCP client will necessarily use this profile, and work with the security properties described in the profile.
Now if a third-party SaaS service that serves multiple enterprises, including Wholesale Chips, wants to do business with Wholesale Chips, they will have to have a MCP server metadata that is specific to the Wholesale Chips tenant. If the SaaS service is, say, saasrus.com, and their Wholesale Chips client is located at: wholesalechips.saasrus.com, then the metadata document located at https://wholesalechips.saasrus.com/.well-known/mcp-supported-profiles will have the “require client credentials” profile, whereas other tenants’ MCP clients, which might or might not support profiles, will appropriately be served the right metadata documents that are specific to their tenant.
When those tenants’ MCP clients connect to the SaaSRUS service, they will either not request any profile to be used, or request their choice of profiles. The SaaSRUS service can determine how to respond on a per-tenant basis.
As can be seen in this example, profiles can be used effectively to enforce security or other requirements in one enterprise while not requiring any new work from other enterprises that do not support profiles. A SaaS service can also selectively support profiles on a per-tenant basis.
If a consumer facing video streaming MCP server (named, say, “VidsRUS”) supports profiles, it can tune its behavior based on how a client connects to it. Say a video service supports a “standard” profile, where it limits the resources that can be used in a request, does not provide latency guarantees, and provides non-HD video output. It also supports a “premium” profile, where it offers low-latency and HD output, and has larger limits on resource utilization per request. Such an MCP server can provide a metadata document that declares support for both profiles:
[
{
"profileURL": "https://vidsrus/mcp-profiles/standard",
"minMcpVersion": "2025-08-13"
},
{
"profileURL": "https://vidsrus/mcp-profiles/premium",
"minMcpVersion": "2026-08-13"
}
]
Now, if an MCP client connects to the server when a user that is permitted to use premium is logged in, the response from the MCP server (in the InitializeResult of the Model Context Protocol) will communicate that it is using the “premium” profile for this session. In this way, the MCP client will be able to adjust its behavior to expect specific results.
As usage of profiles grows, some may be considered as being useful to everyone in the MCP community. These can be managed within the MCP repository as “Standard Profiles”. The MCP repository has a well defined governance structure, which can be followed to define, adopt and evolve these Standard Profiles
Individual enterprises may want to define profiles for their own use (either with their homegrown MCP servers, or with 3rd party SaaS services that the enterprise uses). These are managed outside of the MCP repository, and therefore called “Custom Profiles”.
Similarly, a SaaS service may want to define its own Custom Profiles for any client that wants to connect to it.
All of these possibilities are achievable through the use of profiles as described in the SEP.
The use of profiles is optional, and MCP servers can simultaneously serve clients that support profiles and those that do not. When an enterprise requires the use of specific profiles, the protocol can ensure that sessions that are successfully established between clients and servers do so with the requisite profiles.
Profiles are not just useful where certain security properties are required. They can also be useful to determine resource usage, service tiers, auditing features, etc.
The ability to define custom and standard profiles, combined with the ability for clients and servers to select mutually agreeable profiles is a huge step in unblocking enterprise adoption of MCP. The “profiles” idea is currently under consideration by the MCP developer community. If you would like to weigh in, you can do any or all of the following:
title: Require Client Credentials Profile
## Overview
This profile specifies the minimum required authentication behavior of any MCP server, internal or external, being used by Wholesale Chips Inc.
## Motivation
Because MCP is being used to integrate Wholesale Chips' AI agents with enterprise data sources, it is important to ensure that the authentication is performed using secure practices, in order to avoid data leakage.
## Specification
### MCP Client Requirements
All MCP clients being used by Wholesale Chips MUST support the Client Credentials flow (Section 1.3.4 of {{RFC 6749}}), using TLS mutual authentication {{RFC8446}}, to the OAuth 2.1 server located at: `https://oauth.wholesalechips.co`. The MCP Client MUST authenticate itself using client credentials issued using SPIFFE, using the enterprise SPIRE server located at: `https://spire.wholesalechips.co`.
### Authorization Server Requirements
The Authorization Server located at `https://oauth.wholesalechips.co` SHALL reject any authorization request in which the client is unable to authenticate itself using mutual TLS using a trusted credential.
### MCP Server Requirements
MCP Servers SHALL reject any API call from an MCP Client that does not present an authorization token issued by the Authorization Server located at `https://oauth.wholesalechips.co`.
Want more of the latest identity-first security topics and trends delivered to your inbox? Helpful and insightful content, no fluff.