[RFC] Server-Side Policy Enforcement for MCP Capabilities

[sebastianmart-sketch]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Server-side policy enforcement for MCP capabilities

I would like feedback on a draft proposal for a new MCP extension that defines a minimal, backend-neutral contract for MCP Servers to enforce policy before exposing or executing protected capabilities.

Core principle
The MCP Server that owns a protected capability should remain the final Policy Enforcement Point. The MCP Client should not be trusted by default as the authority for authorization decisions, actor validation, approval state, policy selection, enforcement mode or capability visibility.

This follows a Zero Trust-oriented posture for MCP deployments: the server should verify trusted context before exposing or executing protected capabilities, rather than assuming the client, gateway or previous authentication step is sufficient.

This is intended to complement, not replace, MCP authorization, OAuth, enterprise IdPs, gateways or client-side confirmation. Those layers are useful, but operational and enterprise deployments often also need capability-level enforcement inside the server itself.

Draft repository:
https://github.com/sebastianmart-sketch/mcp-server-side-policy-enforcement

What the draft proposes

The proposal focuses on:

• policy evaluation before protected capability execution;
• optional policy-based discovery filtering;
• fail-closed behavior when policy cannot be evaluated;
• actor and approval constraints, such as human, supervised_ai, automation or service_account;
• a minimal decision model: allow, deny, require_approval;
• optional external policy decision services while keeping the MCP Server as the enforcement point;
• non-normative examples for YAML/RBAC-style profiles, audit and delegated policy services.

What it does not propose

It does not propose:

• a new policy language;
• a required RBAC or ABAC model;
• a required audit backend;
• a required identity provider;
• a replacement for MCP authorization, OAuth, enterprise IdPs or gateways;
• a universal way to prove whether an actor is human, AI-assisted or automated.

Why this may be useful

MCP authorization can answer:

Can this client obtain and present credentials to access this MCP Server?

But enterprise and operational deployments often also need to answer:

Given this authenticated context, should this specific capability be listed, read or executed now, with these parameters, for this actor, tenant, environment and approval state?

Today, that capability-level policy enforcement is left to individual implementations. That can lead to inconsistent behavior across servers.

Motivation: cross-realm MCP deployments

One reason this may matter is that MCP’s promise is to connect applications, tools and services to AI across many environments. In practice, the MCP Client and MCP Server may operate in different security, identity, governance and audit realms.

This becomes more important as MCP Servers move beyond internal adapters. ISVs, SaaS providers, MSPs and enterprise platform vendors may expose MCP Servers as standard product features or supported interfaces. A customer-side gateway may help, but it cannot be the only assumed control. The product-owned MCP Server still needs to enforce capability-level policy, approval and audit requirements for the capabilities it exposes.

For example, an MCP Server may expose capabilities for a SaaS/PaaS platform, enterprise platform or operations tool such as a Linux management system. The MCP Client may be operated by a customer, partner, third-party agent platform or internal automation workflow.

In that model, valid credentials should not automatically make the MCP Client the authority for capability visibility, execution policy, actor validation, approval state or audit requirements.

The server still needs to answer questions such as:

• Should this authenticated client see this capability?
• Should this specific actor be allowed to execute it?
• Does this action require human approval or supervised AI control?
• Is this request allowed for this tenant, environment or risk level?
• What audit evidence must the server retain?
• Should the same capability be exposed in the same way to all clients?

Gateway enforcement can help, and in many enterprise deployments it will be necessary. However, a gateway is not always sufficient as the only enforcement point when MCP exposes heterogeneous systems with different semantics, risk levels and audit obligations.

A gateway may validate credentials, route tenants, apply coarse policy, rate-limit requests or block known unsafe patterns. But the protected MCP Server often has the best domain-specific context to decide whether a capability should be visible or executable for a given actor, tenant, environment, approval state and runtime condition.

For this reason, gateway enforcement should complement server-side enforcement, not replace it. The protected MCP Server should remain the final Policy Enforcement Point for the capabilities it owns.

Related discussions

I’m aware of related discussions, including SMCP (#689) and ExecutionGateway (#594). I have tried to keep this proposal focused on a minimal, backend-neutral enforcement contract at the MCP Server layer, rather than on a security envelope, gateway pattern or client-side control.

Requested feedback

I would especially appreciate feedback on:

1. Does this belong as an MCP extension, a SEP, implementation guidance or something else?
2. Is the scope narrow enough?
3. Should discovery filtering be part of the core proposal or an optional profile?
4. Is the decision model of allow, deny, require_approval sufficient?
5. Should actor constraints such as human and supervised_ai be standardized or left to implementation profiles?
6. Should require_approval_via: task | elicitation | none be part of the core contract or an approval profile?
7. Should the external decision contract be standardized or remain non-normative?
8. Is _other: deny useful as a reference-profile convention for fail-closed behavior on unknown or future methods?

AI usage disclosure

I used generative AI as an editorial and technical sparring partner while developing this proposal. It helped me test the structure, identify possible gaps, compare alternative framings and refine wording.
The core idea, proposal direction, final editorial judgment and decision to share this draft are mine.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other