Think of MCP as the shipping container of enterprise AI. Before standardized containers, every port improvised its own way of loading cargo, and every route carried its own risks. Once the container arrived, global trade moved faster, but customs, inspection, and chain of custody had to catch up. MCP is doing the same thing for AI: it gives models a standard way to dock with enterprise data and tools, and now the inspection layer has to catch up too.
That shift gives security teams a new set of connections to inventory and govern. Many of those connections run as local processes on developer machines, outside the traffic that secure web gateways and legacy DLP systems inspect. Some host configurations let agents execute tools without case-by-case approval, so teams need explicit authorization and runtime controls.
MCP is the open standard behind that shift, and client support now ships inside the AI tools employees already have. That turns MCP into a governance question: the specification, the model-to-tool trust boundary, and the traffic paths agents use each create risk your existing controls weren’t built to see. This article walks through where those risks originate and what a working control model looks like in production.
Key takeaways
- MCP provides widely used AI hosts with a standard route to enterprise tools and data, but authentication, consent, authorization, and input validation remain the implementer’s responsibility.
- Enterprise exposure grows through poisoned tool metadata, excessive privileges, weak audit telemetry, and local subprocess traffic that network-centric controls may never inspect.
- Effective governance combines discovery of local and remote connections, distinct least-privilege agent identities, tool-integrity checks, runtime inspection, and attributable audit trails.
- WitnessAI positions its platform as an MCP control layer with server and agent visibility, intent-aware allow/warn/block/route policies, prompt-injection defenses, identity attribution, and audit trails.
The Model Context Protocol (MCP) explained
MCP was introduced in November 2024 as an open standard for connecting AI systems with data sources. It provides a standardized way for AI applications to connect to external systems. The official specification uses a USB-C port analogy: one standardized way to connect AI applications to external systems.
A host coordinates the MCP session architecture. Claude Desktop and Cursor are hosts. So is VS Code with an AI extension. Each client within the host has a one-to-one connection to an MCP server. Servers expose the MCP server capabilities, including tools the model can execute and read-only resources it can consult. They can also provide prompt templates that a user can invoke.
Depending on host configuration, a model may invoke a tool without case-by-case human approval. A database write or an outbound email can occur without a human in the decision path.
In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation. Anthropic, Block, and OpenAI co-founded it. Google, Microsoft, AWS, Cloudflare, and Bloomberg also back it. According to SDK download data, MCP’s Tier 1 SDKs were seeing nearly half a billion downloads per month by July 2026. Agent deployment is scaling alongside it.
How MCP architecture works
MCP runs on a three-part client-server architecture: a host application, one or more clients inside it, and the MCP servers those clients connect to. Each part has a defined job, and understanding how they fit together is the fastest way to see where control points belong.
The host is the AI application the user interacts with, such as Claude Desktop, Cursor, or VS Code with an AI extension. Within the host, each client maintains a dedicated one-to-one connection to a single MCP server. That isolation matters for governance: one compromised server doesn’t automatically bleed into the others.
MCP servers expose three primitives the model can work with. Tools are functions the model can execute, such as sending an email, querying a database, or opening a pull request. Resources are read-only data the model can consult, such as files or knowledge base entries. Prompts are reusable templates a user can invoke through the host UI.
Two transport mechanisms carry the traffic between clients and servers. Local transport runs the server as a subprocess of the host and communicates over standard input and output, which is how most developer tooling works today. Remote transport uses Streamable HTTP to reach server-hosted MCP services across the network. The transport choice determines which of your existing controls can see the traffic at all.
The benefits of MCP for enterprise AI
MCP’s core benefit is reuse: build a connector once, and any MCP-compatible host can use it. That collapses the integration matrix that used to slow every agent project down, and it gives buying committees a clearer path from pilot to production.
Before MCP, every AI application needed custom code to reach each system it touched. A new model or a new tool meant a new integration, and each integration was one more thing to maintain. MCP replaces that N×M problem with a single standard, so a server built for one host works with all of them.
For enterprise teams evaluating agent deployment, the practical benefits fall into four areas:
- Faster time to production: Teams can wire agents to Jira, Salesforce, GitHub, or an internal data warehouse using existing MCP servers, rather than building bespoke connectors. Engineering hours shift from plumbing to application logic.
- Model portability: Because MCP is model-agnostic, you can swap Claude for another model or run several in parallel without rewriting the tool layer. That protects the integration work you’ve already paid for.
- A common surface for governance: One protocol means one inventory, one authorization model, and one audit format across agent projects. Security teams stop chasing different integration patterns across vendors.
- An open ecosystem: With Anthropic, OpenAI, Google, Microsoft, AWS, Cloudflare, and Bloomberg backing the Agentic AI Foundation, MCP is unlikely to fragment the way earlier plugin standards did. That reduces the risk of committing to a dead-end format.
The tradeoff is that all of these benefits depend on the same connectivity layer that creates new risk. The next section walks through where that risk shows up.
You Can’t Secure What You Can’t See
WitnessAI gives you network-level visibility into every AI interaction across employees, models, apps, and agents. One platform. No blind spots.
Explore the PlatformWhere MCP creates risk for enterprise AI programs
MCP creates risk in three places: the specification itself, the trust model between models and tools, and the traffic paths that sit outside your existing controls. Each one shifts responsibility onto the enterprise deploying it, and each one shows up before most governance programs are ready.
The MCP specification states plainly that “MCP itself cannot enforce these principles at the protocol level,” which means authentication, consent, authorization, and input validation are yours to implement.
That gap has already produced documented attacks. Tool poisoning, where malicious instructions hide inside tool descriptions the user never sees, is one of the most widely reported MCP attack classes, and the Cloud Security Alliance’s MCP security research cataloged more than 30 CVEs between January and February 2026, along with nearly 7,000 internet-exposed MCP servers by early 2026.
The third risk is structural. MCP’s local transport runs the server as a subprocess of the host and communicates over standard input and output, so the exchange never crosses the network path that proxy-based controls monitor.
Remote MCP uses Streamable HTTP, but keyword- and regex-based approaches weren’t designed to resolve intent inside conversational payloads or agent tool calls. When an agent sends an external email or updates a customer record, the action reflects the company’s name, and compliance still requires an audit trail documenting what was done.
Knowing Which AI Tools Are in Use Is Just the Start
WitnessAI goes beyond app discovery. Observe classifies the intent behind every AI interaction across employees and agents, so you can build smarter policies based on real risk, not guesswork.
Explore ObserveHow to bring MCP under control in the enterprise
The three risks above map to three controls: know what’s connected, decide what each agent is allowed to do, and enforce that decision while the agent is working. None of these require a new team or a new budget line — they extend disciplines you already apply to human users and production APIs.
Treat this as a sequence, not a checklist. Each step narrows what the next one has to handle, and together they leave an audit trail your compliance team can hand to a regulator without a scramble.
1. Inventory MCP servers, tools, and agent connections
You can’t govern what you can’t see. If your developers are already using Claude Desktop, Cursor, or VS Code with an AI extension, you likely have MCP activity to inventory today, much of it running as local subprocesses that never touch your proxy logs.
A useful inventory covers both local sessions on developer workstations and CI/CD pipelines, as well as any remote MCP servers your agents access across the network. Capture which tools each server exposes, not just that the server exists.
2. Authorize and scope agents before they connect
Once you can see the servers, decide which agents can reach which tools, and under what conditions. Document what each agent can access and do, list its approved data sources, and review tool descriptions and metadata during that approval.
Version pinning or hash verification catches changes made after approval, which is where tool poisoning typically slips in. Give each agent its own identity, scoped to least privilege and traceable to the human who initiated it, and match the strictness of controls to the agent’s level of autonomy — light logging for read-only agents, progressively stricter controls for agents that write, spend, or send.
3. Enforce at runtime and keep the evidence
Authorization decides who can connect; runtime enforcement governs every tool call and AI interaction after the connection is established. Pre-execution checks inspect prompts and tool calls before an agent acts, and response filtering catches sensitive data on the way back.
Enforcement reads better with more options than allow or block — warning a user or rerouting a sensitive query preserves productivity while containing risk. Whatever the decision, capture it in an audit trail that ties the agent’s action back to a human identity, so compliance can answer “what did the agent do, and on whose behalf?” without having to reconstruct the session from scratch.
Blocking AI Isn’t a Strategy. Governing It Is.
WitnessAI enforces intent-based policies, routes prompts to the right models, and redacts sensitive data in real time so your teams keep moving while your data stays protected.
Explore ControlBringing MCP into the confidence layer for enterprise AI
MCP settled the integration question; governance now belongs to risk leaders. A current connection inventory and deliberate server authorization establish the control boundary.
Runtime policies create continuous audit trails that help demonstrate compliance and provide evidence for auditors. These controls also help agent projects move beyond pilot. Consistent audit trails give teams a clear view of agent activity as adoption grows.
We provide security and compliance teams, including privacy leaders, with a single framework for that work. It combines intent-based policies with runtime guardrails, extending governance across the human and digital workforce. To see how it applies to the MCP servers and agents already in your environment, schedule a demo.