Understanding the Model Context Protocol (MCP)

The Model Context Protocol (MCP) is becoming one of the most important architectural patterns in enterprise AI because it changes how AI assistants connect to business systems. For cybersecurity leaders, the key point is simple: MCP is not just a developer convenience. It is a new integration layer where identity, authorization, data exposure, tool execution, logging, and third-party risk all intersect.

MCP gives AI applications a standardized way to discover and use external context, such as files, tickets, cloud resources, databases, code repositories, and business applications. This guide explains how MCP works, why it was created, and how to implement it safely in production environments.

What is MCP?

Model Context Protocol (MCP) is an open standard that defines how LLM applications connect to tools, data, and workflows through a standardized interface.

If you are wondering “what is MCP?” in an enterprise security context, think of it as a protocol that lets an AI application communicate with tools and data sources through a consistent interface. Security depends on how the host, server, transport, identity, and authorization layers are implemented.

In the Model Context Protocol MCP architecture, a host application, such as an AI coding assistant or enterprise agent platform, connects to one or more MCP servers. Each server can expose capabilities such as tools, resources, and prompts. The official MCP architecture describes a client-server model in which an MCP host creates one MCP client for each MCP server it communicates with. Each client communicates with exactly one server, preserving a one-to-one client-server relationship. Under the current specification, the protocol core is stateless: each request is self-contained and carries its protocol version and client capabilities.

That isolation matters. From a security perspective, MCP becomes a control point for deciding which data and actions an agent can see, request, execute, or pass downstream.

Why was Model Context Protocol created?

Anthropic introduced MCP in November 2024 as an open standard for connecting AI assistants to the systems where data lives, with the goal of replacing fragmented one-off integrations with a common protocol. Without a standard, every connection between an AI system and an enterprise tool becomes a custom integration. That creates engineering overhead, inconsistent security controls, and governance gaps.

Anthropic framed the problem as one of information silos: even capable models are constrained when they cannot reach the relevant data behind content repositories, business tools, development environments, and legacy systems. MCP addresses that by providing a universal, open standard for connecting AI systems with data sources. 

For security teams, SOC managers, and GRC teams, the deeper purpose is not merely “connectivity.” It is controlled interoperability. MCP gives organizations a repeatable way to connect AI agents to enterprise systems while applying policies around access, authorization, and monitoring.

How does Model Context Protocol work?

At a high level, MCP works through three participating roles:

• MCP host: The AI application the user interacts with. Examples include AI IDEs, coding agents, desktop assistants, or enterprise agent platforms.
• MCP client: The component inside the host that communicates with exactly one MCP server and routes protocol messages between that server and the host.
• MCP server: The program or service that exposes tools, resources, and prompts to the AI application.

The protocol uses a data layer and a transport layer. The data layer defines JSON-RPC-based communication, including discovery, version negotiation, capabilities, tools, resources, prompts, and notifications. The transport layer defines how messages move between participants, including stdio for local processes and Streamable HTTP for remote communication. MCP’s authorization specification applies to HTTP-based transports.

A typical flow looks like this:

1. The AI host connects to an approved MCP server.
2. The MCP client discovers what that server offers.
3. The host determines how the available capabilities are used. Tools are typically model-controlled, resources application-controlled, and prompts user-controlled.
4. The client requests a tool invocation or resource retrieval.
5. The MCP server performs the approved action or returns the requested context.
6. The AI application uses that result to produce an answer, complete a workflow, or request further approval.

This is why MCP can feel powerful: it allows agents to move from answering questions to taking action. It is also why security teams should treat MCP as an agentic execution surface, not a passive data connector.

What are the main components of MCP?

The main components of MCP are best understood as architectural elements and functional primitives.

Architectural elements include:

• Hosts that coordinate the AI experience and manage user interaction
• Clients that maintain one-to-one relationships with MCP servers
• Servers that expose approved capabilities
• Transports such as local standard input/output or remote HTTP-based communication
• Authorization flows for restricted servers, especially when HTTP-based transports are used

Functional primitives include:

• Tools: Executable functions the model can invoke, such as querying a database, opening an issue, retrieving a log, or calling an API
• Resources: Data sources that provide context, such as file contents, database records, schemas, tickets, API responses, or cloud asset metadata
• Prompts: Reusable templates that structure model interactions for specific tasks

The MCP documentation identifies tools, resources, and prompts as the core primitives that servers expose. Tools are especially sensitive because they enable models to interact with external systems, including databases, APIs, and computational services. 

What is an MCP server?

An MCP server is a program that makes a system’s capabilities available to an AI application through MCP. It can run locally on a user’s machine or remotely on service infrastructure. Google Cloud’s MCP documentation describes local servers as typically using standard input/output for same-device communication, while remote MCP servers expose HTTP endpoints for AI applications. 

In practice, an MCP server might connect to:

• A GitHub organization or code repository
• A SIEM or log analytics platform
• A cloud provider account
• A vulnerability management system
• A ticketing or case management system
• A data warehouse
• A document repository
• A secrets, identity, or configuration management platform

For security teams, the MCP server is where policy should become enforceable. It should not expose “everything the backend API can do.” It should expose narrowly scoped, auditable, purpose-built capabilities.

How is MCP different from an API?

A common question is: How is MCP different from an API?

An API is usually a service-specific interface. It defines how software can interact with one application, database, cloud service, or platform. Each API has its own authentication model, schemas, endpoint design, rate limits, error handling, and semantics.

MCP is a protocol for making those capabilities discoverable and usable by AI applications in a standardized way. It does not replace APIs. Instead, an MCP server often wraps APIs, databases, filesystems, or internal services and exposes them as model-friendly tools and resources.

The difference is especially important for governance:

• Traditional APIs are typically designed for explicit software-to-software calls.
• MCP is designed for AI-assisted context exchange and tool use.
• APIs generally assume the caller knows what endpoint to call.
• MCP allows the AI application to discover available capabilities through methods such as tool listing.
• APIs often expose broad service functionality.
• MCP servers should expose curated, policy-aware actions suitable for agentic use.

In short, MCP does not replace APIs. It standardizes how AI applications discover and use context and actions across systems, often by exposing capabilities that are backed by existing APIs.

Is Model Context Protocol open source?

Yes, MCP is an open standard/open protocol, with openly developed specifications, SDKs, and reference implementations. Anthropic’s launch announcement described MCP as open-sourced and introduced the specification, SDKs, local Claude Desktop support, and an open-source repository of MCP servers. 

That said, “open source” should not be interpreted to mean every MCP server is safe, transparent, or community-audited. Individual servers may be vendor-operated, internally developed, community-maintained, or proprietary. Security teams should evaluate each MCP server as they would any privileged integration component.

MCP benefits for enterprise security teams

The most important MCP benefits are not limited to developer productivity. When implemented carefully, MCP can improve governance and reduce integration sprawl.

Key benefits include:

• Standardized integration patterns: Teams can reduce the number of bespoke AI connectors.
• Reusable control points: A single MCP server can expose approved tools to multiple AI hosts.
• Better visibility: Tool calls, context retrieval, and authorization events can be logged and monitored.
• Least-privilege design: Servers can expose only the actions needed for a workflow.
• Vendor flexibility: MCP can make tools portable across hosts that support the protocol.
• Faster security automation: SOC and DevSecOps teams can connect agents to curated data sources such as alerts, asset inventories, cases, and code repositories.

However, these benefits depend on disciplined implementation. MCP does not automatically make AI integrations safe. It gives organizations a structure within which security controls can be designed, enforced, and audited.

What tools support MCP?

MCP support has expanded across developer tools, AI agent SDKs, enterprise agent platforms, and cloud ecosystems.

Examples include:

• Visual Studio Code, which states that it implements the full MCP specification and supports MCP capabilities such as tools, prompts, resources, elicitation, authentication, and server instructions.
• OpenAI Agents SDK, which supports multiple MCP transports and can reuse existing MCP servers or connect agents to filesystem, HTTP, or connector-backed tools. 
• Microsoft Copilot Studio, which supports connecting agents to MCP servers and currently supports MCP tools and resources.
• Google Cloud remote MCP servers, which provide MCP-based access to Google and Google Cloud services with governance, security, IAM, authorization, and toolset controls.
• GitHub’s official MCP server, which can use many GitHub APIs and supports enabling or disabling specific toolsets and individual tools. 

Security teams should maintain an approved list of MCP hosts and servers rather than relying on ad hoc developer configuration. Unapproved MCP servers can become a form of shadow IT with direct access to sensitive data and actions.

What industries are adopting MCP?

MCP adoption is strongest where AI assistants need controlled access to internal systems: software development, enterprise productivity, cloud operations, business applications, and data workflows.

The security implications extend far beyond software engineering. In May 2026, the NSA noted that real-world MCP adoption had accelerated across products used in business, finance, legal, software development, and other industries, including sensitive tasks such as querying personally identifiable information. 

For regulated organizations, that means MCP should be reviewed through the same lenses as cloud access, SaaS integration, privileged automation, and data loss prevention.

Can MCP access sensitive company data?

Yes, MCP can access sensitive company data if an MCP server exposes that data and the connected identity has permission to retrieve it. MCP does not inherently bypass IAM, network controls, or application authorization. However, effective access depends on the identities, credentials, and permissions used by the MCP server and any downstream systems it calls.

Sensitive exposure scenarios include:

• A coding agent reading private repositories or secrets accidentally committed to code
• A support agent retrieving customer records or case notes
• A SOC assistant querying security logs that contain PII, credentials, or session tokens
• A cloud operations agent listing resources, changing configurations, or accessing metadata
• A compliance agent pulling regulated records into a model context where retention and access controls are unclear

This is why MCP access should be governed at the server, identity, tool, resource, and workflow levels. The question is not only “Can the model see this?” but also “Can the model cause a tool to retrieve it, write it, delete it, forward it, or combine it with other context?”

How can organizations secure MCP deployments?

A successful MCP strategy starts with outcomes, not tools. Organizations should define what they want AI agents to accomplish, which data they should use, and where human decision-makers must remain in control. From there, MCP becomes a mechanism to expose the right capabilities in a controlled way.

Securing MCP deployments requires treating them as agentic integration infrastructure. Traditional controls still matter, but they must be adapted for dynamic tool invocation, prompt injection, context sharing, and implicit trust relationships. The NSA specifically warned that MCP introduces risks involving dynamic tool invocation, implicit trust relationships, and context sharing that cannot be solved only at the endpoint or interface layer. 

A practical MCP security program should include the following controls.

1. Build an MCP inventory

Track every MCP host, client, server, transport, owner, data source, tool, and environment. Include local developer configurations, remote servers, and vendor-managed servers. Shadow MCP servers should be treated as a governance risk.

2. Enforce least privilege

Expose only the tools and resources required for a specific workflow. Avoid all-purpose servers with broad read-write access. Use toolsets, allowlists, and scoped permissions wherever possible. Google Cloud, for example, documents toolsets as a way to limit the tools available to an agent and reduce context overload.

3. Validate identity and authorization

HTTP-based MCP authorization is based on established OAuth specifications. The MCP authorization uses OAuth 2.1 and defines requirements for protected resource metadata, authorization-server discovery, resource indicators, and access-token validation for protected MCP servers.

4. Prevent token passthrough and confused deputy issues

Do not allow an MCP server to accept a token meant for another resource and pass it downstream. The MCP authorization specification explicitly requires servers to reject tokens not intended for them and not pass through tokens received from MCP clients.

5. Require human approval for high-risk tools

Human approval should be required for destructive, financial, privileged, external, or irreversible operations. The MCP tools specification says there should always be a human in the loop with the ability to deny tool invocations and recommends confirmation prompts.

6. Treat prompt injection as a first-class threat

Tool outputs, documents, tickets, web pages, emails, and logs can all become indirect instruction channels. OWASP describes prompt injection as a vulnerability that can manipulate model behavior and lead to unauthorized data access, exfiltration, or unauthorized actions through connected tools and APIs.

7. Sandbox local MCP servers

Local MCP servers can run with the same privileges as the user or host application. The MCP security guidance recommends explicit consent before executing local server commands, showing the exact command, warning users about dangerous operations, and using sandboxing or restricted access to files, networks, and system resources. 

8. Monitor and log every tool call

Security teams should log tool discovery, tool invocation, relevant invocation metadata, approvals, failures, identity context, server version, and policy decisions. Where arguments or outputs are recorded, apply appropriate redaction, access controls, and retention policies so telemetry does not become a secondary source of sensitive-data exposure. Feed those logs into SIEM, SOAR, UEBA, and audit workflows. Lack of telemetry makes MCP incidents difficult to reconstruct.

9. Apply data classification and DLP

Classify which MCP resources may contain secrets, PII, PHI, PCI, source code, regulated records, or privileged operational data. Apply redaction, masking, egress filtering, and retention controls before content enters model context.

10. Red team MCP workflows

Test for prompt injection, tool poisoning, excessive agency, SSRF, command injection, token theft, privilege escalation, and data over-sharing. OWASP’s MCP Top 10 highlights risks such as token mismanagement, privilege escalation via scope creep, tool poisoning, command injection, insufficient authorization, lack of telemetry, shadow MCP servers, and context over-sharing. 

How to think about MCP in modern engineering systems

In cloud-native environments, teams already wrestle with microservices, event streams, and complex identity models. MCP adds another layer, but it can also simplify the picture by standardizing how models access capabilities. A minimum viable MCP implementation might expose a small set of read-only tools backed by non-sensitive data. A mature deployment will include write-capable tools, fine-grained authorization, human-in-the-loop controls, and continuous monitoring. 

The bottom line on MCP adoption

MCP is best understood as a new control plane for AI-to-system interaction. It can help organizations standardize how agents access tools and data, but it also concentrates risk in the servers, credentials, schemas, prompts, and workflows that define what agents can do.

For security leaders, the goal should not be to block MCP outright. The goal should be to govern it deliberately:

• Approve trusted MCP servers
• Limit tool scope
• Bind access to identity
• Validate tokens and audiences
• Require human approval for sensitive actions
• Monitor tool use continuously
• Treat all retrieved context as untrusted
• Test agent workflows before production deployment

MCP can become a foundation for safer enterprise AI automation, but only if it is deployed with the same rigor applied to APIs, cloud access, privileged automation, and third-party integrations. In that sense, the Model Context Protocol is not just an AI protocol. It is a cybersecurity architecture decision.

How Bitsight simplifies and scales MCP-centric AI risk management

Bitsight specializes in quantifying and managing cyber risk across complex ecosystems. As organizations adopt MCP to connect AI agents to internal and external systems, they need a reliable way to understand how these new connections change their exposure. Bitsight's security ratings and analytics provide an external, continuously updated view of an organization's cyber posture, including third-party risk.

Bitsight can help teams evaluate the external security posture of organizations and dependencies involved in MCP-enabled workflows, continuously monitor third-party risk, and bring Bitsight cyber risk intelligence into customer-owned agents, LLM-enabled tools, and AI workflows through MCP and similar integration patterns. Bitsight Security Ratings and analytics are also backed by research demonstrating correlation with real-world cybersecurity outcomes.

Bitsight's experience with governance, data quality, and correlation to real-world breach outcomes helps teams design MCP deployments that are aligned with measurable risk reduction, not just automation for its own sake.