Model Context Protocol (MCP) & Third-Party Risk

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.

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. 

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 security risks should organizations consider when using MCP?

MCP can increase the impact of an AI system by allowing an AI application to connect models to external data sources and expose resources, prompts, and tools that can perform actions. Security teams should evaluate not only the model, but also the host, client, servers, identities, credentials, and downstream systems that make up the MCP workflow.

Key risks include:

• Prompt injection, including indirect prompt injection: Malicious instructions embedded in MCP prompts, resources, tool metadata, or tool outputs can influence model behavior and trigger unsafe tool use
• Excessive permissions: Broad resource or tool permissions, especially write or administrative access, can increase the blast radius of a compromised workflow
• Credential exposure: Tokens, API keys, and secrets may be exposed, logged, stored insecurely, over-scoped, or reused across services
• Tool poisoning: Malicious or compromised servers can alter tool names, descriptions, schemas, or behavior to mislead the model or user
• Command or code execution: Vulnerable or overly powerful tool implementations may allow arbitrary command execution, code execution, server-side request forgery (SSRF), or unintended system changes
• Sensitive-data exposure: MCP resources, prompts, or tool results may introduce confidential or regulated data into model context or downstream systems
• Authorization failures: Missing token audience validation, token passthrough, or confused-deputy weaknesses can allow credentials to be used against unintended services
• Insufficient logging and change visibility: Limited telemetry or untracked changes to server code, tools, and permissions can make misuse and incidents difficult to investigate

Organizations should treat MCP as agentic integration infrastructure and a security trust boundary, not simply as an AI feature.

Can MCP introduce third-party risk?

Yes. A vendor-operated or externally maintained MCP server can become another third-party integration with access to enterprise systems, data, credentials, or workflows.

Risk can come from:

• Vendor-operated MCP servers
• Community-developed or open-source servers
• Vulnerable software dependencies
• Downstream APIs and SaaS services
• Changes to tools or permissions after initial approval
• Compromised packages, malicious updates, or changes to tool descriptions, capabilities, or permissions after initial approval

Security teams should incorporate externally operated MCP servers and their critical dependencies into existing third-party risk processes by identifying ownership, verifying source and update provenance, reviewing data handling and access requirements, assessing authentication and authorization controls, and monitoring security posture, threat activity, and material changes over time.

This is especially important because third-party risk is increasingly tied to broader digital ecosystems and supply chains, where organizations may have limited direct control over external environments. A mature approach should assess both underlying security posture and current threat context, including exposed vulnerabilities, breach and ransomware activity, compromised credentials, and deep and dark web signals across organizations and dependencies supporting the MCP workflow.

How do you assess the security of an MCP server?

Start with two questions: What can the server and the identity under which it operates access, and what can they do?

Review its access

Inventory:

• Connected systems and APIs
• Data sources and sensitive information
• Credentials, authentication methods, token scopes, and intended token audiences
• Network and filesystem access, including the privileges of local server processes
• Downstream services and trust relationships

Review its capabilities

Determine whether the server can:

• Read data
• Modify records
• Execute commands or code
• Change infrastructure
• Initiate external transactions
• Perform privileged administrative actions

Then assess transport security; authentication and authorization; token storage and audience validation; protection against token passthrough and confused-deputy attacks; input and output validation; SSRF protections; dependency security; logging; rate limiting; and update provenance.

For protected HTTP-based servers, verify applicable OAuth controls, including PKCE, resource indicators, audience-bound access tokens, and rejection of tokens intended for other resources.

Finally, test the complete workflow across the host, client, server, model, and downstream services for scenarios such as direct and indirect prompt injection, privilege escalation, credential theft, command injection, SSRF, confused-deputy attacks, and data exfiltration.

What governance policies should enterprises establish for MCP?

Enterprise MCP governance should define who can deploy, approve, connect, modify, and monitor MCP hosts, clients, and servers.

Core policies should cover:

• MCP inventory and ownership: Maintain a registry of approved hosts, clients, servers, tools, versions, and accountable owners
• Approved use cases: Define where MCP can and cannot be used
• Data governance: Specify which data classifications may enter model context or be shared with servers, tools, and downstream services, including applicable retention and egress requirements
• Access control: Establish identity-bound authentication, authorization, token validation, and least-privilege requirements
• Tool approval: Define which tools may execute automatically, which users can review or deny tool calls, and which actions require explicit human approval
• Third-party review: Assess externally operated MCP servers and their critical dependencies before deployment
• Change management: Reassess servers when server code, tool descriptions, schemas, capabilities, permissions, or dependencies change
• Logging and incident response: Define monitoring, retention, investigation, and response requirements for server connections, capability discovery, authorization decisions, approvals, and tool calls

What security controls help reduce MCP-related risk?

A defense-in-depth approach works best:

Control access

Use strong authentication, least privilege, scoped credentials, and proper token validation. For protected HTTP-based MCP servers, apply the current MCP authorization requirements, including OAuth-based flows, PKCE, resource indicators, and token audience validation. Do not pass MCP client tokens through to downstream APIs; use separate, audience-restricted credentials for upstream services.

Restrict agent capabilities

Allowlist approved hosts, servers, and tools, monitor changes to tool descriptions and schemas, separate read-only access from write or administrative privileges, and ensure users can review and deny tool calls, with explicit confirmation required for sensitive or irreversible actions.

Treat context as untrusted

Treat MCP prompts, resources, tool descriptions, and tool outputs as untrusted. Apply prompt-injection defenses, data classification, DLP, secret scanning, and egress controls to information retrieved through MCP. Separate retrieved content from trusted instructions and prevent untrusted content from directly authorizing tool use.

Isolate risky execution

Sandbox local MCP server processes and any command or code execution. Restrict filesystem, network, environment-variable, and operating system access based on the use case.

Monitor activity

Log server connections, capability discovery, server and tool versions, changes to tool metadata, tool calls, authorization decisions, approvals, failures, and relevant identity context. Avoid indiscriminately logging sensitive arguments or outputs; apply appropriate redaction, access controls, and retention policies. Integrate meaningful events into existing SIEM, SOAR, and incident response workflows.

These controls help reduce the likelihood that a compromised server, malicious prompt, authorization failure, or overly permissive tool can escalate into a broader security incident.

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.