MCP profiles could tighten enterprise policy enforcement

At a glance

What this is: This is an analysis of how MCP profiles could let clients and servers negotiate required authentication and session behaviours, with the key finding that policy enforcement can happen without changing the protocol itself.

Why it matters: It matters because IAM, NHI, and platform teams need a way to bind enterprise controls to MCP sessions, especially when AI agents and third-party services are connecting to sensitive data.

Context

MCP profiles are a governance layer for the Model Context Protocol, allowing a client and server to agree on required behaviours before a session begins. The core problem is that the base protocol can recommend OAuth options without forcing the enterprise-grade choices many organisations need for sensitive data and AI-connected workflows.

That gap matters because policy is only useful when it is enforceable at session start, not after a connection is already established. In practice, enterprises need tenant-scoped rules, authentication constraints, and predictable session behaviour for MCP servers that may be used by AI agents, users, and third-party SaaS providers.

Key questions

Q: What breaks when an MCP server cannot enforce required profiles?

A: The session falls back from policy to compatibility, which is where enterprise risk starts. If the server cannot require a specific profile, the client may connect without the authentication or session behaviours the organisation expected. That leaves policy unenforced at the exact point where trust should be established.

Q: Why do profile-based MCP controls matter for enterprise governance?

A: Because they turn session setup into an explicit policy decision instead of an implied protocol assumption. Enterprises can require stronger authentication, tenant-specific metadata, or service-tier behaviour before the connection is accepted, which gives governance teams a place to enforce rules without modifying MCP itself.

Q: How do you know if MCP security controls are actually working?

A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.

Q: What is the difference between standard and custom MCP profiles?

A: Standard profiles are governed within the MCP repository for community-wide adoption, while custom profiles are defined by individual enterprises or SaaS providers for their own requirements. The practical difference is who owns the policy, who approves changes, and who is responsible for retirement or revision.

Technical breakdown

How MCP profiles change session negotiation

MCP profiles are a specification of behaviours and properties published at a profile specification URL and advertised by servers through well-known metadata. A client can request one or more profiles, the server can accept or decline, and the session only initializes if both sides agree. That makes profiles a pre-session policy mechanism rather than a post-connection enforcement check. In practical terms, the profile becomes part of the contract governing how the session may proceed.

Practical implication: Treat profile negotiation as a policy gate, not a discovery feature.

Why enterprise authentication requirements need profiles

The article's enterprise example shows why broad protocol guidance is not enough: one tenant may require client credentials, mutual TLS, JWT-based authentication, or tenant-specific metadata, while another tenant may not. A single MCP server can expose different supported profiles per tenant, allowing a SaaS provider to enforce different security terms without redefining the whole protocol. This is especially relevant where AI agents are connecting to enterprise data through shared external services.

Practical implication: Use profiles to express tenant-specific authentication and authorization requirements explicitly.

How standard and custom profiles split governance responsibility

Standard profiles can live in the MCP repository under community governance, while custom profiles can be defined by an enterprise or SaaS provider outside the repository. That split matters because it separates ecosystem-wide interoperability from organisation-specific control requirements. It also means profile governance is not just a protocol feature; it is an operational decision about who owns the policy definition, versioning, and acceptance path.

Practical implication: Assign ownership for custom profiles before they are allowed to govern production MCP traffic.

Breaches seen in the wild

• 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

Profile negotiation is becoming the control plane for MCP governance. The article shows that enforcement is shifting from the base protocol to a negotiated session contract. That matters because the enterprise can now require specific behaviours without forking MCP or weakening compatibility. The practitioner implication is that policy logic, not protocol syntax, becomes the meaningful security boundary.

Tenant-scoped metadata is the practical answer to shared MCP exposure. The SaaS example makes clear that one server may need to present different supported profiles to different tenants. That is a governance model, not a cosmetic configuration choice. The practitioner implication is that shared services must prove per-tenant control separation before they can be trusted for regulated or sensitive workloads.

Custom profiles create a new identity governance decision point for AI-connected systems. When an enterprise defines its own profile, it is defining what authentication, session behaviour, and service expectations are acceptable for that identity context. That is directly relevant to NHI and AI-agent governance because access is no longer just a token issue; it becomes a negotiated policy state. The practitioner implication is that teams need lifecycle ownership for profiles, not just for credentials.

Standards-backed profiles could reduce the need for brittle exceptions in enterprise MCP adoption. Standard profiles and custom profiles solve different problems, and that distinction is important. The former can support interoperability across the ecosystem, while the latter can encode enterprise-specific constraints. The practitioner implication is that organisations should decide which controls belong in community standards and which must remain tenant-owned.

Protocol compatibility is not the same as policy compliance. The article's central point is that MCP can remain backwards compatible while still allowing stricter sessions for enterprises that require them. That is useful, but it also means success depends on whether organisations actually enforce profile selection and reject non-compliant sessions. The practitioner implication is that compliance teams must verify negotiation outcomes, not just protocol support.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

MCP profiles are a policy enforcement pattern, not just an interoperability feature. Enterprises that treat negotiation as optional will keep discovering that protocol support does not equal control enforcement. The programme-level change is to make acceptance criteria explicit at initialization, then prove that non-compliant sessions fail closed.

Profile ownership becomes part of the identity lifecycle. Once an enterprise defines custom MCP profiles, those definitions need versioning, review, and retirement just like credentials and entitlements. Without that governance layer, the profile catalogue will drift into an informal exception register rather than a control mechanism.

Model Context Protocol adoption will be limited until session behaviour is governable. A protocol that can connect AI systems to enterprise data is only enterprise-safe when the organisation can specify which authentication path, which tenant context, and which service tier is acceptable. The implication is that governance teams should focus on the enforceability of the negotiated session, not the existence of the protocol alone.

For practitioners

• Define enterprise MCP profiles for required controls Specify the minimum authentication and session behaviours your organisation expects, such as client credentials, mutual TLS, or tenant-scoped metadata, and publish them as profile definitions under your control.
• Require profile negotiation before session establishment Configure MCP clients and servers so a session fails closed when the requested and supported profiles do not match, rather than falling back to a weaker default.
• Separate standard profiles from tenant-specific profiles Reserve shared profiles for controls that should apply broadly, and keep tenant-specific requirements isolated so third-party SaaS services can enforce different rules per customer.
• Validate authentication behaviour at the tenant boundary Test whether each tenant-specific metadata document actually returns the intended profile set and whether the server enforces the same requirements after initialization.
• Track profile ownership through identity governance Assign a clear owner for each custom profile, including review cadence, version control, and retirement rules, so policy does not drift away from the identity programme.

Key takeaways

• MCP profiles move enterprise control from protocol preference to negotiated enforcement, which is the distinction that matters for governance.
• The article shows that tenant-specific session rules can be enforced without changing the underlying protocol, but only if clients and servers actually reject mismatches.
• For practitioners, the real task is to govern profile definitions, ownership, and acceptance behaviour as part of the identity programme.

Key terms

• MCP Profile: A profile is a named set of behaviours and properties that a Model Context Protocol client and server agree to use during a session. In enterprise settings, profiles let organisations require specific authentication, scope, or service behaviour without changing the base protocol.
• Profile Negotiation: Profile negotiation is the exchange in which a client requests supported profiles and a server confirms which ones will govern the session. It matters because the security posture is decided at initialization, and a failed agreement should stop the connection rather than silently downgrading controls.
• Tenant-Scoped Metadata: Tenant-scoped metadata is protocol information tailored to a specific customer or environment rather than a one-size-fits-all default. For NHI governance, it allows an enterprise to enforce different access and authentication requirements for different business units, tenants, or service relationships.
• Custom Profile: A custom profile is an organisation-defined MCP profile managed outside the shared protocol repository. It is used when a business needs local control over authentication, session behaviour, or service constraints, and it must be governed like any other identity policy artifact because it changes how access is granted and enforced.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.