Enterprise IG: Enterprise Pain Points Catalog v0.1 (Draft for Review) #2761
Replies: 1 comment
-
|
@raghu-chandra-mcp — following up on the enforced-vs-declared point from the thread. Three items for the v0.1 → v1.0 pass, all inside audit/identity (3.x) and my EU AI Act category (7). Place and number as you see fit. 1. Proposed new entry (suggest 3.4): 3.4 Governance That Passes Audit but Is Not Enforced on the Read PathContributed by: Camilo Ayerbe Posada Problem: Data-handling obligations in MCP — erase-on-request, retention limits, PHI/tenant scoping — are declared (by labels, policy engines, or audit logs) but not verified as enforced at retrieval. Current mechanisms confirm an action was requested and logged, not that the data is absent or contained. Canonical failure: a deletion that passes its own audit yet returns the deleted content at full confidence on the next retrieval, because it survived in a derived or replicated store the action never reached — summaries, embeddings, KV-cache, replicas, or a downstream tool that re-derived it from raw. Every layer has an admission gate (content entering is classified, tagged, logged); none has an eviction gate (content leaving, provably, across derivations). Impact: Compliance dashboards read "satisfied" off the declaration layer while the data is live at the retrieval layer. A classification or deletion applied at the first hop does not hold across a multi-step MCP chain — derived artifacts and downstream tools inherit the data without inheriting the policy. Regulated enterprises can show an obligation was requested, not met, which fails third-party verification. This is the enforcement-verification counterpart to the signed-record (3.1), PHI-classification (3.2), and identity-primitive (3.3) gaps: those make actions attributable and tagged; this makes the effect of a governance action verifiable. Spec Gap: No protocol-level mechanism to verify, on the read path, that a declared data-handling obligation (deletion, retention, classification) was enforced across all derived and replicated stores — and to emit a record of that enforcement checkable by an independent party without re-disclosing the protected content. Empirical demonstrator available: a "delete" that passes its own audit yet returns the content at confidence 1.0 on retrieval. This threads 3.1/3.2/3.3 rather than duplicating them. It's also the use case @SamMorrowDrums' tool-annotations-ig asked for — I'm writing the annotation-facing version up for them separately and will cross-link. 2. Date corrections to my existing entries (the Digital Omnibus moved the AI Act timeline):
The high-risk tranche (incl. Annex III credit scoring) shifted from 2 Aug 2026 to 2 Dec 2027; only the Art. 50 transparency obligations hold at Aug 2. The delay was granted because compliance standards/tooling aren't ready — which is exactly what 3.4 and Category 7 point at. GDPR Art. 17 remains the always-on driver underneath. 3. Attribution: please set my organization to Ulissy s.r.l. / GNS Foundation in both places it appears — the participants table (currently "Decentralized identity startup, Rome") and the Category 7 champion line (currently "GNS-Foundation"). Happy to draft spec-gap language or a worked example for any of these. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
MCP Enterprise Interest Group - Enterprise Pain Points Catalog
Version 0.1 (Draft)
Date: May 20, 2026
Source: First Monthly Meeting + Discord Contributions
Overview
This catalog documents enterprise pain points identified by practitioners deploying the Model Context Protocol in production environments. It serves as the Enterprise IG's first deliverable and provides an evidence base for prioritizing MCP specification work.
Pain points are organized by category and attributed to the contributing organization. Each entry describes the problem, the real-world impact, and where applicable, the gap in the current MCP specification.
1. Enterprise Authentication and Identity Visibility
Champion: Aaron Parecki (Okta)
1.1 MCP Server Connections Are Invisible to Enterprise Admins
Contributed by: Aaron Parecki, Okta
Problem: Enterprise administrators can control who logs into SaaS applications (e.g., Jira, Salesforce) through their identity provider, but they have no visibility or control over who connects MCP servers to those same applications. An employee can connect an MCP server to Jira without the enterprise admin knowing it exists.
Impact: The enterprise loses its security boundary. Access control policies that apply to human users do not extend to MCP tool connections, creating an unmonitored data access path that bypasses existing governance.
Spec Gap: No protocol-level mechanism for enterprise administrators to discover, authorize, or revoke MCP server connections within their organization.
1.2 Shadow AI and Credential Mismatch
Contributed by: Varun Wadhwa, TraceForce
Problem: Employees sign into AI clients (ChatGPT, Claude) using enterprise credentials but connect to MCP servers using personal credentials, or vice versa. This creates an identity mismatch where the enterprise session and the MCP session are linked to different identities.
Impact: Audit trails cannot reliably attribute MCP tool calls to a specific enterprise user. Policy enforcement breaks because the MCP connection operates under a different identity context than the enterprise session.
Spec Gap: No standardized mechanism to enforce that MCP connections inherit and maintain the enterprise identity context of the parent AI client session.
2. Identity Propagation Across Agent Chains
Champion: Anishma Reddy (EmpowerID)
2.1 Recursive Agent Delegation and Identity Lineage
Contributed by: Anishma Reddy, EmpowerID
Problem: When a parent agent delegates tasks to child agents, and those child agents spawn further agents, there is no standardized way to maintain identity lineage across the chain. Least-privilege enforcement requires knowing which human or system identity authorized the original action, but this information is lost as delegation recurses.
Impact: If the parent agent's authorization is revoked, the entire chain of child agents must also be revoked, but there is no protocol-level mechanism to propagate revocation at the speed required for security enforcement. The problem compounds across trust domain boundaries.
Spec Gap: No identity lineage or delegation chain tracking in the MCP specification. No standardized revocation propagation across agent hierarchies.
2.2 Identity Propagation and Session Context
Contributed by: Varun Wadhwa, TraceForce
Problem: Verified identity is not reliably surfaced and conveyed across MCP clients, servers, and downstream services. When an MCP tool call reaches a downstream service, the service cannot verify which human identity authorized the action or whether the authorization is still valid.
Impact: Policy enforcement and audit at downstream services operate without reliable identity context, making it impossible to answer "who authorized this action" at any point in the chain.
Spec Gap: No standardized mechanism for identity propagation across MCP connection boundaries.
3. Audit, Compliance, and Verifiable Records
Champion: Aman Sharma (Blue Shield of California)
3.1 No Standardized Audit Record Format
Contributed by: Camilo Ayerbe Posada
Problem: Current audit capabilities in MCP are limited to operator-controlled server logs and gateway captures. These are first-party records that prove what the operator sees, but in regulated environments, enterprises need standardized records where the actor signs the action, including who, what, with what arguments, what results, and when, that are verifiable by an independent third party.
Impact: Regulated enterprises cannot produce audit evidence that satisfies third-party verification requirements. Compliance teams cannot reconstruct the full chain of actions across multiple MCP servers with confidence that the records have not been altered.
Spec Gap: No protocol-level standard for signed, verifiable audit records that include actor identity, action, arguments, results, and timestamps.
3.2 PHI Compliance Across Multi-Step MCP Chains
Contributed by: Aman Sharma, Blue Shield of California
Problem: In healthcare environments, a single user query can trigger a multi-step MCP chain: summarization, EHR data retrieval, de-identification, and other processing steps that may touch five to seven different tools or services. The entire chain must maintain PHI (Protected Health Information) compliance, but there is no protocol-level signal that identifies content as PHI when it crosses between chain steps.
Impact: Enterprise teams cannot clearly identify the boundaries of what PHI goes in and what comes out at each step in the chain. Audit trails for PHI-bearing workflows are incomplete. HIPAA compliance is difficult to demonstrate when the protocol itself provides no content classification mechanism.
Spec Gap: No protocol-level content classification or tagging mechanism (e.g., "this content contains PHI") that persists across MCP tool call chains.
3.3 Identity Primitives for End-to-End Process Tracking
Contributed by: Camilo Ayerbe Posada
Problem: Identity primitives do not follow the entire MCP process from initiation to completion. The human-to-agent and agent-to-tool relationships are not captured in a way that allows the full process to be reconstructed with cryptographic certainty.
Impact: Compliance with regulations like the EU AI Act (enforcement beginning August 2, 2026) requires attributable and auditable AI operations. Without identity primitives that persist through the full MCP chain, enterprises cannot demonstrate compliance.
Spec Gap: No end-to-end identity primitive that travels with the MCP request through all processing steps.
4. Gateway and Proxy Behavior
Champion: TBD (Derek Lewis, Silex Data Solutions and Lin Sun, Solo.io contributed via Discord)
4.1 OBO Token Exchange Patterns
Contributed by: Derek Lewis, Silex Data Solutions (via Discord)
Problem: Two conflicting patterns exist for On-Behalf-Of (OBO) token exchange in enterprise MCP deployments. Some gateways delegate the OBO token exchange to the MCP server itself, while others perform the exchange upstream of the MCP server. There is no standard for which approach is correct.
Impact: Interoperability between enterprise MCP deployments breaks when gateways and servers expect different OBO patterns. Enterprises building multi-vendor MCP infrastructure cannot guarantee consistent token handling.
Spec Gap: No specification for how OBO token exchange should be handled in gateway/proxy deployments.
5. Configuration Portability
Champion: TBD
5.1 Cross-Client Credential and Configuration Management
Contributed by: Elisheba Anderson, Mass Ave Labs
Problem: Deploying the same MCP server across different clients (VS Code, Cursor, Claude Code, Claude Desktop) requires setting up API credentials and configurations separately for each client. There is no shared or portable configuration format.
Impact: Developer experience degrades as MCP adoption grows. Enterprises deploying MCP servers to hundreds of developers must maintain multiple configuration formats, increasing the risk of credential exposure and misconfiguration.
Spec Gap: No standardized portable configuration format that works across MCP clients.
6. Scalability and Resilience
Champion: Peder H P (Saxo Bank, contributed via Discord)
6.1 Interceptors and Enterprise Middleware
Contributed by: Peder H P, Saxo Bank (via Discord)
Problem: Enterprises need middleware capabilities for PII redaction, hallucination detection, and compliance enforcement, but the MCP specification does not support standardized interceptor patterns. Saxo Bank built a non-MCP solution for this, but it is not portable or interoperable.
Impact: Every enterprise deploying MCP middleware builds a custom solution. These solutions are not portable across MCP implementations, creating vendor lock-in and increasing maintenance burden.
Spec Gap: No interceptor or middleware specification in MCP.
7. EU AI Act Compliance
Champion: Camilo Ayerbe Posada, cayerbe (GNS-Foundation contributed via Discord)
7.1 Attributable and Compliant AI Operations
Contributed by: Camilo Ayerbe Posada
Problem: The EU AI Act, with enforcement beginning August 2, 2026, requires that AI operations in regulated environments be attributable and auditable. MCP connections must be compliant with these requirements, but the protocol does not provide the identity, audit, or traceability mechanisms needed.
Impact: European enterprises deploying MCP in regulated environments face compliance risk. Without protocol-level support for EU AI Act requirements, each enterprise must build custom compliance layers.
Spec Gap: No alignment between MCP specification and EU AI Act requirements for attributable AI operations.
Participants Contributing to This Catalog
MCP Enterprise Interest Group
Co-facilitated by Raghu Chandra and Yann Jouanin
Charter PR: #2626
Beta Was this translation helpful? Give feedback.
All reactions