Model Context Protocol (MCP): Enterprise Architecture, Security

Model Context Protocol (MCP) is an open standard for AI integration — connecting AI applications to external tools and data through a common interface. It reduces the need for bespoke model-to-system connectors, but it does not solve agent orchestration, agent-to-agent collaboration, data semantics, or governance on its own.

This article covers what MCP actually solves, the concrete risks and documented security incidents organizations need to plan for before adopting it, and where it fits alongside the newer standards — A2A, WebMCP, OSI — now filling in the parts of agentic AI that MCP was never built to cover.

What is Model Context Protocol (MCP)?

Anthropic introduced the Model Context Protocol (MCP) on November 25, 2024, to solve a critical challenge in AI deployment: connecting language models to the diverse systems where real-world data resides (Anthropic — “Introducing the Model Context Protocol”). Released as an open standard, MCP enables developers to build secure, two-way connections between data sources and AI-powered tools.

Key features of MCP:

• Standardized interface for data access
• Secure communication between models and external systems
• Real-time data retrieval and integration
• Simplified AI deployment in complex environments

What problem does MCP solve?

As AI assistants became more advanced, they remained largely isolated from the actual data and tools organizations use daily. Each time a developer wanted to connect an AI model to a new database, API, or content repository, they had to write custom integration code. This created a fragmented landscape of one-off connectors, making it hard to scale AI across many contexts.

Business implications of the M×N problem:

1. High integration costs and developer overhead

When every AI model requires a custom-built connector to each tool, integration effort scales exponentially — each connector demands engineering resources, maintenance, testing, and security review.

2. Information silos and limited model utility

Without seamless access to live systems, even advanced AI models remain disconnected from actual operations, producing stale outputs and ineffective automation.

3. Fragmentation and lack of standardization

A patchwork of one-off connectors creates a brittle architecture that is non-reusable, hard to audit, and fragile to change — slowing AI rollout across teams.

4. Inhibited ROI on AI investments

Integration bottlenecks and data silos keep organizations from capitalizing on their AI infrastructure, undermining stakeholder confidence and delaying broader adoption.

MCP as a universal standard and where that metaphor stops being useful

Anthropic calls MCP “a USB-C port for AI applications” , and that’s a fair comparison. USB-C didn’t change what a monitor or a hard drive does; it just meant every device could use the same port instead of its own special cable. MCP does the same thing for AI: instead of building a custom connection for every database, CRM, or file system, a model can reach any of them the same way.

But the comparison only goes so far. USB-C just moves power and data between two devices, it doesn’t say how two laptops should work together on a task, or how a browser should let an outside program control it. MCP has the same kind of limit: it only handles one AI application talking to one tool. It doesn’t cover AI agents talking to each other, actions happening inside a browser, or making sure data means the same thing across different platforms. Those are separate, newer standards, covered further down.

MCP’s actual competitive position

MCP, LangChain/CrewAI, and OpenAPI solve three different kinds of things and aren’t in competition with each other. MCP is a tool-integration protocol, LangChain and CrewAI are agent orchestration frameworks, and OpenAPI is an API description specification.

An application can (and often does) use MCP for tool access, LangGraph or CrewAI for orchestration, and OpenAPI-described endpoints wrapped behind an MCP server, all at once.

MCP vs. A2A vs. RAG vs. API: what each one actually does

Because MCP gets compared to almost everything in the AI-integration space, it helps to line up the four terms people most often conflate.

The practical reading: these four are not alternatives to choose between. A production agentic system commonly uses RAG for grounding, MCP for tool and data access, A2A for coordinating with agents it doesn’t own, and plain APIs underneath all of it.

MCP gains industry traction

By open-sourcing MCP, Anthropic fostered a collaborative ecosystem where developers and organizations build and share MCP-compatible connectors, eliminating the need to maintain proprietary connectors for each data source.

In March 2025, OpenAI adopted MCP across its product suite, starting with the Agents SDK. Microsoft had already embedded MCP into Azure AI services, and Google DeepMind confirmed MCP support within the Gemini SDK. What has changed materially since is governance: MCP is no longer an Anthropic-led open-source project that other vendors chose to support — it is now jointly stewarded, a distinction covered in the next section.

Model Context Protocol (MCP) structure

MCP Host — the user-facing application where you interact with AI models (Claude Desktop, Cursor, Windsurf, chatbots). It manages multiple MCP Clients, each maintaining a one-to-one connection with a specific MCP Server.

MCP Client — a bridge within the MCP Host that maintains a one-to-one connection with a specific MCP Server, handling communication, capability discovery, protocol negotiation, and resource subscriptions.

MCP Server — a program that exposes external systems to AI models, running locally or remotely, providing three capabilities:

• Tools (invokable functions)
• Resources (readable data sources)
• Prompts (predefined interaction templates)

How MCP works

1. The AI assistant (host) wants to get information or do something for you.
2. It talks to an MCP client inside the app, which knows how to connect to MCP servers.
3. The MCP client connects to an MCP server that knows how to get data or perform tasks from a specific place.
4. The MCP server tells the client what it can do.
5. The AI assistant asks the client to request that capability from the server.
6. The server performs the task and sends the result back.
7. The AI assistant uses this fresh information to give a better response.

What does MCP mean for AI applications?

• Enhanced AI capabilities – real-time access to external data, tools, and applications.
• Reduced vendor lock-in – organizations can swap MCP-compatible models without rebuilding architecture.
• Simplified development – one protocol instead of many bespoke integrations.
• Lower barriers to entry – smaller companies can plug into any MCP-compatible system.

Considerations, risks, and challenges of adopting MCP

1. Ecosystem maturity and tooling gaps

Documentation, SDKs, and developer tooling still vary in quality across languages, and community-contributed connectors vary in security posture. Early adopters should be prepared to contribute to the ecosystem or build custom infrastructure to fill gaps.

2. Security and access control complexity

This is no longer a theoretical risk. Since 2025, security researchers and vendors have documented specific, named attack patterns against MCP deployments — prompt injection, tool poisoning, rug pulls, confused-deputy attacks, tool shadowing, and token passthrough — along with real incidents affecting Asana, GitHub’s MCP server, a WhatsApp integration, and a malicious npm package impersonating Postmark.

3. Operational overhead and resource management

Hosting and managing multiple MCP servers in production introduces operational complexity; resource subscriptions, tool availability, and concurrency need careful management, and observability across a distributed setup is non-trivial.

4. Standardization trade-offs

MCP is a general-purpose protocol. Highly specialized or real-time, stateful integrations (multiplayer editors, live dashboards) may exceed what its current abstraction comfortably supports.

MCP Governance Update: The Agentic AI Foundation (2026)

Why this matters in practice for enterprises evaluating MCP:

• Vendor neutrality. MCP’s roadmap and stewardship are now structured through a multi-stakeholder foundation model rather than a single-vendor project. Roadmap and spec decisions go through Linux Foundation governance processes, the same model used for Kubernetes, PyTorch, and Node.js.
• Long-term stability signal. Foundation stewardship materially reduces the “what if the sponsor abandons this” risk flagged in the ecosystem-stability consideration above — a real concern for any single-vendor open standard.
• Momentum, quantified. At the time of the donation, Anthropic reported more than 10,000 active public MCP servers and adoption across ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code.

The Broader Agentic Protocol Stack: MCP, A2A, WebMCP, and OSI

By 2026, MCP sits alongside — not above — a small set of complementary open standards, each solving a different layer of the agentic-AI problem.

Here’s how they divide:

The practical takeaway: For many organizations, MCP is likely to be the first agent-protocol layer they encounter, because current workloads frequently involve tool and data access. A2A becomes relevant once you’re coordinating multiple independently-built agents rather than one agent with many tools. WebMCP and OSI are both still early, worth watching, not yet worth building a production dependency on.

Native MCP Support Across Major Cloud & Data Platforms (2026)

MCP adoption has moved from developer tooling into the core agent-infrastructure products of every major cloud and data vendor:

• AWS Bedrock AgentCore – the AgentCore Gateway exposes MCP servers as first-class targets, supporting OAuth (two-legged, three-legged, and on-behalf-of token exchange) and IAM SigV4 authentication, with the gateway able to broker access to hundreds of enterprise SaaS MCP servers behind a single control point.
• Microsoft – MCP support runs through Azure AI Foundry and Copilot Studio, letting enterprise agents call MCP-exposed tools alongside native Microsoft 365 connectors; Microsoft co-authored the C# SDK from MCP’s earliest days.
• Google – the Gemini/Vertex AI Agent Builder stack supports MCP alongside A2A for agent-to-agent coordination, reflecting Google’s dual role as an A2A originator and MCP adopter.
• Databricks – MCP servers are governed through Unity AI Gateway, which controls access and monitors activity from a single control plane, while Unity Catalog enforces permissions and manages credentials so agents reach only the tools and data an admin has explicitly granted.
• Snowflake – offers a managed MCP server exposing Cortex Search and Cortex Analyst, usable directly from external agent runtimes such as Bedrock AgentCore, in addition to Snowflake’s own Cortex Agents.

The common thread across all five: MCP is being treated as a connectivity layer that sits underneath each platform’s own governance and catalog system, which is precisely the argument for pairing MCP adoption with a real data-governance layer.

MCP Adoption by the Numbers (2026)

Adoption has moved from early experimentation into selective production deployments though available surveys vary materially by sample size, industry cohort, and what each one counts as “production,” so treat any single percentage as directional rather than definitive.

Server and ecosystem counts, each a snapshot as of a specific date rather than a stable figure:

SDKs are officially available in Python, TypeScript, C#, and Java. All figures above: Digital Applied.

MCP Security Incidents and Attack Taxonomy

MCP’s security risks are not hypothetical. Since its release, researchers and vendors have documented a consistent set of named attack patterns, several with real-world incidents attached. The table below maps each risk to what it means in practice and the control that addresses it:

Documented incidents:

• April 2025 — Rug pull / tool shadowing. Invariant Labs demonstrated the WhatsApp MCP exploit: a malicious trivia-game MCP server used tool poisoning to redirect an agent into pulling WhatsApp chat history through a separate, trusted WhatsApp MCP server and leaking it as normal traffic. (Source: Invariant Labs)
• May 2025 — Prompt injection (confused deputy). Researchers at Invariant Labs showed that a single malicious issue in a public GitHub repository could use hidden instructions to make an agent using GitHub’s MCP server exfiltrate private repository contents and personal data. (Source: Invariant Labs)
• June 2025 — Multi-tenant isolation failure. A logic flaw in Asana’s newly launched MCP integration exposed project data across organizational boundaries for roughly two weeks before a fix; no credentials were stolen, but confidential data crossed tenant boundaries as designed features interacted incorrectly. (Source: Checkmarx)
• July 2025 — Confused deputy. The Supabase–Cursor incident showed how a Cursor agent with privileged, service-role database access could be manipulated via user-supplied text in support tickets — a case of privilege amplification through legitimate access. (Source: Simon Willison)
• August 2025 — Supply chain / RCE. CVE-2025-6514, a critical (CVSS 9.6) OS command-injection flaw in mcp-remote, a widely used OAuth proxy, allowed a malicious server to trigger remote code execution on the client machine via a crafted authorization_endpoint value; the package had over 437,000 downloads at time of disclosure. (Source: JFrog)
• September 2025 — Supply chain rug pull. postmark-mcp, an unofficial npm package impersonating a Postmark email integration, shipped 15 clean versions before version 1.0.16 added a hidden line of code that BCC’d every outgoing email to an attacker-controlled address — the first widely documented malicious MCP server found in the wild, estimated to have reached roughly 300 organizations. (Source: Snyk)
• Late 2025–early 2026 — Access-control bypass / RCE chain. A chain of three CVEs (CVE-2025-68143, -68144, -68145) in Anthropic’s own mcp-server-git reference implementation — reported June 2025, patched December 2025, publicly detailed January 2026 — allowed a configured repository-path restriction to be bypassed and, chained with the Filesystem MCP server, achieved remote code execution via prompt injection. (Source: The Hacker News)

MCP and the Enterprise Semantic/Data Layer

Plugging MCP into a data engineering or BI platform surfaces a problem that doesn’t show up in a typical developer-tool integration: whether different teams mean the same thing by “revenue” or “active customer.”

MCP standardizes how an agent connects to a tool or dataset, but it says nothing about the meaning of the data once the agent gets there. Give an agent MCP access to five data sources, and you can get five technically-correct but different answers to the same business question.

Two initiatives are beginning to address this semantic-consistency problem: Unity Catalog governs access to datasets: who can use them and under what controls, the Open Semantic Interchange initiative – now incubating at the Apache Software Foundation as Apache Ossie – aims to standardize the metric definitions themselves.

Regulatory Considerations: EU AI Act and Agentic AI Accountability

As a general matter, the EU AI Act (Regulation (EU) 2024/1689) does not contain a separate “agent” category. Its obligations apply based on a system’s purpose, risk classification, deployment context, and capabilities — the same framework applies whether an agentic system is built on MCP, a different protocol, or no standardized protocol at all.

Two provisions of that framework are the ones most likely to actually apply to an MCP-connected agent in practice, which is why they’re worth knowing specifically:

• Article 50, in effect from August 2, 2026: where it applies, people interacting directly with an AI system must be informed that they are interacting with AI, unless this is already obvious from the context and circumstances of use. For a customer-facing support bot or booking assistant, disclosure should normally be made clearly at the start of the interaction, and content-labeling duties may apply too. This turns on whether the specific system is in scope, not simply on whether it’s “an agent.”
• Chapter III, on a separate and later timeline: if your agent operates in a “high-risk” domain, more requirements apply. This is a different, harder question – whether the specific use case falls under Annex III’s list of high-risk categories (things like employment decisions, credit scoring, law enforcement). An agent can trigger Article 50 without triggering Chapter III, or vice versa, or both, or neither – the two need to be checked separately, not treated as one deadline.

In practice: build in logging, permission controls, monitoring, and a way for a human to step in – early, especially for anything touching a regulated workflow. Don’t wait to be told it’s required. But which specific rules apply to you depends on details a lawyer needs to check — whether you’re the one building the system or the one deploying it, and which exact provisions your use case falls under. There’s no single rule that says “you’re an agent, therefore X”.

Practical MCP use cases

MCP is just the connection in each of these. What actually makes them production-ready is everything covered earlier in this article: reliable pipelines, data governance, semantic definitions, monitoring, and approval gates. These aren’t hypothetical — variations are already running: PayPal uses an MCP server for commerce APIs, Sentry surfaces error-tracking data to AI assistants, and Block and Apollo connect AI to analytics dashboards and payment processors through MCP.

Decision framework: Is MCP right for your organization?

Adopting MCP is a foundational decision about how your organization scales AI capabilities across systems, teams, and workflows.

MCP adoption should form part of a broader plan for successfully implementing agentic AI in your organization, covering business use cases, infrastructure, data access, governance, observability, and organizational readiness.

A phased approach to MCP adoption

• Phase 1 — Assess integration pain points. Audit current AI projects and the systems they rely on; identify repetitive or brittle connectors slowing development.
• Phase 2 — Pilot with low-risk, high-value systems. Select a small number of systems (GitHub, Postgres, Slack) and expose them via MCP servers using existing MCP hosts.
• Phase 3 — Standardize internal AI integration strategy. Develop internal governance for MCP use, evaluate open-source vs. proprietary components, and build or contribute reusable connectors.
• Phase 4 — Scale and operationalize. Roll out MCP across additional teams, implement observability and role-based access, and align with IT/security on compliance and uptime — with traceability, logging, and human-intervention controls incorporated into governance from the outset, particularly for EU-facing or regulated use cases.

Questions executives should ask their technical teams

1. Where are we spending the most time building one-off AI integrations?
2. How often do we repeat similar connector logic across teams or tools?
3. Are our AI assistants limited by lack of access to real-time tools or data?
4. Do we have multiple AI models or platforms that need to interact with the same systems?
5. What’s our current strategy for managing AI access to internal systems securely — and can we produce an audit trail of what an agent did and why?
6. Could a shared, protocol-based approach reduce our integration and maintenance burden?

The future of MCP

MCP’s trajectory since 2024 mirrors how foundational internet protocols matured: initial single-vendor release, rapid multi-vendor adoption, then transition to neutral, multi-stakeholder governance. With that governance transition now complete and adjacent standards (A2A, WebMCP, OSI) filling in the layers MCP was never meant to cover, the more useful question for 2026 planning isn’t “will MCP win” — that’s largely settled — but which combination of protocols and governance layers a given architecture actually requires, and how the security and governance controls described above get built in from the start rather than retrofitted after an incident.

References

• Model Context Protocol — official specification: modelcontextprotocol.io
• Anthropic — “Introducing the Model Context Protocol” (Nov 25, 2024): anthropic.com/news/model-context-protocol
• Anthropic — “Donating the Model Context Protocol and establishing the Agentic AI Foundation” (Dec 9, 2025): anthropic.com/news
• Linux Foundation — “Announces the Formation of the Agentic AI Foundation (AAIF)”: linuxfoundation.org/press
• Linux Foundation — A2A protocol project and one-year adoption milestone: linuxfoundation.org/press
• W3C Web Machine Learning Community Group — WebMCP Draft Community Group Report
• Apache Software Foundation — Apache Ossie (incubating), formerly Open Semantic Interchange
• AWS documentation — Amazon Bedrock AgentCore Gateway, MCP server targets
• Microsoft Learn / Azure Databricks — MCP tools and Unity AI Gateway documentation
• Databricks documentation — MCPs and agent tools
• Snowflake developer guides — Snowflake Managed MCP Server with Cortex Search/Analyst
• Invariant Labs — “WhatsApp MCP Exploited” and GitHub MCP prompt-injection research (April–May 2025)
• Snyk / Koi Security — postmark-mcp backdoor disclosure (September 2025)
• Stacklok — “State of MCP in Software 2026” survey report
• Digital Applied — “MCP Adoption Statistics 2026” (GitHub/registry server counts): digitalapplied.com/blog
• European Commission — AI Act Service Desk FAQ and Article 50 transparency guidance

Sources reflect publicly available information as of August 2026. Product availability, protocol versions, and ecosystem adoption may change over time.