MCP security considerations and mitigation strategies for enterprise

Understanding the MCP interaction model

Before diving into specific threats, it’s important to understand how MCP changes system interactions, especially compared with traditional APIs.

Traditional API integrations typically encode available endpoints, credentials, and call logic in application code or integration layers (Figure 1).

MCP standardizes discovery and invocation of external capabilities through a host-client-server architecture: the host coordinates the AI experience and security policy, creates one MCP client per server connection, and controls context and capability exposure across those boundaries.²

In Claude Code, the application is the host. It can create clients for local or remote MCP servers exposing tools, resources, or prompts; each client connects to one server. The host governs connection permissions, consent, context aggregation, and policy enforcement. Under the 2026-07-28 specification, requests are stateless and carry the protocol version and relevant client capabilities.² ³

Security implications of stateless MCP

Do not infer authorization or trust from an open connection, a long-lived stdio process, or prior requests. Authorize protected operations against trusted identity and resource context on each request. The self-reported clientInfo field is useful for display, logging, and debugging, but not as an authentication or authorization identity.³ ⁵

This model creates distinct user-to-host, host-to-server, and server-to-downstream trust boundaries, with materially different risks for local and remote servers.

Local and remote MCP servers create different trust models

Local / stdio: the MCP OAuth authorization flow is not the default security model. A local server is executable software on the developer endpoint and commonly receives credentials through its process environment. Review package provenance, OS privileges, filesystem/network reach, and secret exposure accordingly. ⁴ ¹⁰ ¹¹

Remote / HTTP: review transport security, server/operator trust, authorization-server discovery, resource-bound access tokens, egress paths, and downstream authorization. A valid MCP access token should authorize the MCP resource, not silently become a bearer credential for an upstream service.⁴ ⁶

Unpacking the MCP threat landscape: Unique risks for the enterprise

MCP does not invent every underlying vulnerability; it changes how identity, untrusted content, model decisions, tool execution, and downstream systems compose.

The practical enterprise threat model is five risk classes ⁶:

Compromising identity, connections and servers

For protected remote HTTP MCP servers, credentials and authorization artifacts are high-value targets. MCP authorization is optional overall; when used for HTTP transports, the 2026-07-28 authorization specification defines OAuth-based discovery, resource binding, and token handling. Stdio deployments generally use environment-provided or implementation-specific credentials instead, so their primary exposure is local process and secret hygiene rather than the HTTP authorization flow. ⁴

OAuth token theft and abuse

If an attacker obtains an access or refresh token used by an MCP client or protected remote server, requests made with that token may appear legitimate to the protected resource.

• Use short-lived access tokens where practical; securely store refresh tokens and ensure revocation/deprovisioning works.

• Bind tokens to the intended MCP resource and validate the audience at the server.

• Keep upstream service tokens separate from tokens presented by the MCP client; the MCP authorization guidance explicitly prohibits token passthrough.

MCP server compromise

An MCP server may hold, broker, or obtain credentials depending on its architecture. If the server is compromised, the blast radius depends on the permissions it can exercise, the data it can retrieve, its network reachability, and whether downstream systems independently enforce the user’s authorization.

• Access connected systems using any credentials or delegated permissions available to the compromised component.

• Invoke tools or APIs in ways that appear to originate from an approved integration.

• Exfiltrate data or manipulate responses returned to the host.

• Persist access if token rotation, revocation, or server redeployment processes are weak.

Manipulating model and tool behavior

Tool descriptions, repository files, issue text, documentation, web pages, browser output, test fixtures, and other external data can influence model decisions. In coding workflows, the same context can shape changes to build scripts, dependency manifests, CI/CD configuration, infrastructure-as-code, and application code.⁶ ⁸

Coding-agent-specific amplification: repository content can persist future behavior; authenticated browser sessions can expose live application privileges; developer environments may contain cloud or package-manager credentials; and generated changes can propagate through pull requests, CI/CD, or infrastructure automation. Secure SDLC review, branch protection, CI gates, and production separation therefore remain relevant. ⁸

Prompt injection and tool poisoning

• Tool poisoning: malicious or misleading instructions are embedded in tool metadata or descriptions so that the model is nudged toward unsafe behavior.

• Tool shadowing or naming collisions: a malicious or unexpected tool appears similar to an approved capability and is selected in place of the intended tool.

• Indirect prompt injection: instructions are embedded in content the coding agent reads - for example, repository files, issue text, documentation, web content, browser output, or test fixtures.

• Cross-tool influence: data returned by one tool can steer the model toward invoking another tool with broader permissions or external side effects.

Retrieved-content deception

The practical risk is cross-capability escalation: content read through one path can steer the model toward a separate tool with broader permissions or side effects. Design controls so a read path never implicitly authorizes a write path.

Indirect prompt injection across MCP trust boundaries

Exploiting tool execution

The execution layer of MCP tools is one of the most critical and sensitive areas in the agent-tool interaction lifecycle. Once a model is authorized to call a tool, weak controls at the execution layer can lead to serious risks, including privilege escalation, data exfiltration, and infrastructure compromise.

Remote code execution (RCE) / command injection

MCP does not make classic command-injection vulnerabilities disappear. If a tool constructs shell commands, file paths, SQL statements, URLs, or other executable inputs unsafely, attacker-controlled content can cross from the model layer into a conventional software vulnerability.

• Prefer structured APIs and parameterized operations over shell construction.

• Validate inputs against explicit schemas and allowlists, not only string sanitization.

• Run local MCP servers and tool-execution processes with the minimum filesystem, network, and OS privileges they require.

Abuse of legitimate filesystem and shell capabilities

A model does not need to exploit a software bug to cause harm if it already has a legitimate tool capable of writing files, executing commands, changing configuration, or calling external systems. Prompt injection, user error, or excessive permissions can turn a valid capability into an unsafe action.

• Writing or modifying shell, build, CI/CD, or application configuration in a way that changes future execution behavior.

• Adding credentials, keys, or configuration that creates unauthorized persistence.

• Sending source code, secrets, or other sensitive data to an external destination through an otherwise legitimate network-capable tool.

Data exposure and governance challenges

Agentic workflows can combine context across systems and move data between tools at runtime, creating governance paths that are less explicit than conventional integrations.

• Credential exposure: tool responses, environment variables, repository files, logs, or generated commands may contain secrets that should never enter model context or telemetry.

• Excessive permission scope and data aggregation: broad scopes increase the amount of data available to a compromised account, server, or agent workflow.

• Cross-system data movement: a workflow may read from one system and write to another, creating new data-loss paths even when each system is individually well controlled.

• Audit and privacy trade-offs: detailed tool and prompt logs can support investigations, but indiscriminate capture can also create a secondary repository of source code, customer data, credentials, and personal information.

Supply chain vulnerabilities

MCP supply-chain risk differs by deployment mode. Local servers introduce executable packages, binaries, plugins, and dependency trees onto the developer endpoint; remote servers introduce operator, endpoint, update, and authorization dependencies. In both cases, a previously approved integration can change over time. ⁶ ¹⁰ ¹¹

• Untrusted server packages or binaries: a local MCP server runs as code on the developer endpoint and may inherit substantial user privileges.

• Compromised updates or dependencies: a previously approved server can change after an update, dependency resolution, image rebuild, or endpoint change.

• Configuration drift: a project-level .mcp.json, plugin, command-line override, or user setting can add or alter server connections if organizational policy does not constrain those sources.

Building a secure MCP foundation: A multi-layered mitigation framework

A secure MCP deployment needs controls across the host, connection, server, execution environment, and downstream systems.

Establishing secure communication channels and architecture

Secure transport layer

Protect transport confidentiality and integrity across remote MCP connections and downstream integrations.

• Use TLS for remote HTTP-based MCP communications and validate certificates correctly.

• For local servers, stdio can reduce network-listener exposure because the client launches the process directly. That is not equivalent to "safe by default": the server is still executable software on the developer endpoint and may inherit filesystem, network, process-environment, and user privileges. ⁴ ¹¹

• Apply connection timeouts, request limits, and bounded retries to reduce denial-of-service and runaway execution risk.

• Treat custom transports as security-sensitive engineering work; they must preserve protocol guarantees and should have an explicit threat model.

Claude Code host and execution boundaries

Claude Code permission rules govern tool use, while Bash sandboxing can add OS-level filesystem and network isolation for Bash execution. Local MCP processes are separate executables and require their own containment when the risk model calls for stronger isolation.⁸ ⁹ ¹⁵

• Use Bash sandboxing and directory boundaries for shell commands; isolate or wrap local MCP processes separately when they need stronger filesystem, network, or OS boundaries. ⁸ ¹⁵

• Do not use bypassPermissions for normal enterprise workflows; managed settings can disable bypass mode and, where policy requires deterministic approval behavior, auto mode. ⁹ ¹³

Credential hygiene for local MCP servers

Do not place static API keys or shared credentials in managed-mcp.json; Anthropic notes that users on the machine can read it. Prefer per-user OAuth, environment expansion, or connection-time credential helpers. For stdio servers, CLAUDE_CODE_SUBPROCESS_ENV_SCRUB can remove Anthropic and cloud-provider credentials from subprocess environments where appropriate. ¹⁰ ¹²

Network security controls

Because MCP servers and tools can span internal systems and public endpoints, network controls should limit lateral movement, outbound reach, and runaway tool activity.

• Segment MCP server infrastructure, restrict east-west reachability, and constrain outbound destinations through egress controls or proxies where appropriate.

• Apply rate limits and concurrency controls to tool calls and downstream APIs.

• Forward security-relevant events into existing monitoring platforms but avoid copying sensitive payloads into telemetry by default.

Robust identity, authentication, and authorization

MCP-specific authorization requirements

For protected remote HTTP MCP servers, use the current MCP OAuth profile rather than generic token handling. Authorization is optional for MCP overall; stdio servers should not use this HTTP flow by default. ⁴

• Discover and validate the authorization server using Protected Resource Metadata and issuer checks.

• Bind access tokens to the intended MCP resource and validate the resource/audience at the server.

• Keep MCP access tokens separate from upstream API credentials; obtain a distinct upstream token when the server acts as an OAuth client.

• Use exact redirect-URI validation, PKCE/state protections, short-lived tokens, and secure token storage.

Enterprise-managed authorization

Where supported end to end, the Enterprise-Managed Authorization extension can use the organization identity provider as the MCP access control point for onboarding, offboarding, and role/group policy. It is opt-in, not a universal MCP capability. ⁷

Identity context management

Preserve trusted attribution for the initiating human/workload, managed Claude Code environment, and executing MCP server/downstream system. Do not use self-reported clientInfo as an authenticated identity. ⁵ ¹⁴

• User/workload identity: tie actions to an authenticated principal with appropriate entitlements.

• Execution attribution: record the managed Claude Code environment and distinct server/downstream service identities where operationally useful.

Least privilege implementation

• Align scopes and downstream permissions to the minimum capabilities required for the approved use case.

• Separate read-only tools from write, administrative, external-communication, or destructive operations.

• Authorize every protected request against trusted identity and resource context; do not rely on connection continuity, tool descriptions, clientInfo, or annotations.³ ⁴ ⁵

Hardening tool interactions

Input validation and sanitization

Validate tool inputs deterministically before execution; model-generated arguments should not bypass conventional application-security controls.

• Validate all parameters against defined schemas and business rules before execution.

• Constrain file paths to allowed roots and use path canonicalization rather than simple character stripping.

• Validate URLs, schemes, redirects, and destination networks; block private, link-local, metadata, or otherwise disallowed targets where not required.

• Use parameterized commands or APIs and secure execution environments instead of interpolating model-generated strings into shell commands.

Output handling

Minimize tool outputs to the data required for the task and apply provenance controls where downstream tool selection or execution could be affected.

• Standardize error handling so failures do not disclose internal paths, credentials, stack traces, or unnecessary system details.

Tool annotations and descriptions

Tool annotations such as read-only or destructive hints can inform UX and policy, but authorization and validation must not rely on them.

Claude Code permission rules for MCP tools

Claude Code lets teams apply allow, ask, and deny rules to tools, including canonical MCP tool names. MCP tools use names such as mcp__<server>__<tool>; deny and ask rules can match broad patterns such as mcp__*, while allow rules can be scoped to a specific server prefix such as mcp__github__get_*. Permission rules are enforced by Claude Code, not by the model.⁹

• Prefer narrow tool-specific rules over blanket approval of every tool from a server. Use the canonical MCP tool name that Claude Code evaluates. ⁹

• Apply deny or ask rules to the specific MCP tools that perform writes, deletes, external sends, credential changes, deployments, or administrative operations; do not assume those semantic categories exist as built-in policy labels. ⁹

• Pair tool permissions with managed MCP allowlists or a fixed managed server set so users cannot simply add an unreviewed server that exposes equivalent capabilities.

Implementing operational safeguards and visibility

Risk-based human approval

Approving every low-risk action creates prompt fatigue; removing approval from high-risk actions creates unacceptable exposure.

• Prompt for confirmation on sensitive or irreversible operations such as credential changes, destructive file operations, production deployment, access-control changes, or external transmission of sensitive data.

• Show the user which tool will run, the material inputs, target system, and expected side effect before approval.

Privacy-aware logging and auditing

Observability should support accountability without creating a secondary archive of source code, credentials, customer data, prompts, or tool outputs.

• Log the identity, tool, decision, approval state, outcome, timestamp, and security-relevant metadata needed for investigation.

• Redact sensitive payloads, enforce retention/access controls, and use tamper-resistant storage for security-relevant audit events.

• Align logging to applicable control and evidence requirements; logging alone does not establish compliance with frameworks such as SOC 2, ISO 27001, or HIPAA.

Monitoring and response

• Alert on unusual MCP server additions, denied-server attempts, abnormal tool usage, repeated authorization failures, unexpected egress destinations, or high-risk commands. Claude Code OpenTelemetry can attribute tool activity to sessions/users and, when configured, include MCP server and tool details for SIEM analysis.¹⁴

• Maintain playbooks for revoking credentials, disabling a server, removing a configuration, isolating an endpoint, and identifying downstream actions taken during the incident window.

• Test the response path periodically; the ability to disable an MCP server quickly is a core operational control.

Ensuring supply chain integrity

Secure MCP selection

Treat MCP servers as maintained software dependencies whose operator, code, endpoint, and update path can change over time.

• Use MCP servers from trusted providers or verified internal sources, and document who operates and maintains each approved server. An Anthropic Directory listing is not a security certification: Anthropic states that it reviews connectors against listing criteria but does not security-audit or manage MCP servers. ⁸

• Verify package, binary, image, or repository provenance; pin versions and apply integrity/signing controls where supported.

• Review server permissions, network access, installation commands, dependencies, update mechanism, and incident-response contact before enterprise approval.

Claude Code enterprise controls

Claude Code supports several enterprise governance patterns; choose one explicitly rather than allowing unrestricted user configuration. ¹⁰ ¹³

• For exclusive control, deploy a fixed managed-mcp.json server set. For an approved-catalog model, use allowedMcpServers with allowManagedMcpServersOnly: true so user/project allowlists cannot broaden the managed policy. ¹⁰

• Use deniedMcpServers for explicit blocks and allowManagedPermissionRulesOnly: true when organization-managed allow/ask/deny tool rules must be authoritative. Set permissions.disableBypassPermissionsMode to "disable"; consider permissions.disableAutoMode where enterprise policy should prevent auto mode. ⁹ ¹⁰ ¹³

• Keep project-level .mcp.json under source-control review. Treat it as executable integration configuration, and use managed policy so repository configuration cannot broaden the organization’s MCP or permission boundary. ¹⁰ ¹¹

• Monitor which servers and tools are actually used so the approved catalog can be reviewed, retired, or tightened over time; Claude Code can export this activity through OpenTelemetry when configured. ¹⁰ ¹⁴

Layered enterprise controls for Claude Code + MCP : Current control surfaces

Enterprise recommendations for secure MCP adoption

Fractal recommends seven actions for moving from experimentation to managed deployment:

1. Establish an enterprise-grade MCP governance and server-catalog policy

2. Harden identity and access as a strategic foundation

3. Make input/output validation a baseline engineering control

4. Apply risk-based human oversight to high-impact actions

5. Build privacy-aware observability and incident response into the core

6. Institutionalize periodic security reviews and configuration governance

7. Enable technical teams through role-specific training and continuous learning

Fractal practitioner checkpoint: pilot exit criteria

A working demo is not a production-ready control model. Validate all six before production connectivity.

What this means in Claude Code

Use this checklist to move from a working Claude Code + MCP demo to an enterprise decision.

Before connecting an MCP server

• Who operates and maintains the server, and can its package/endpoint, version, dependencies, update path, and security review be verified? ⁸

• Is it local or remote, which capabilities does it expose, and what filesystem, network, browser, repository, SaaS, or API reach does it gain?

• For local/stdio servers, are credentials per-user and kept out of readable managed/project configuration files; can the use case remain read-only where possible? ¹⁰ ¹²

Before approving enterprise use

• Are user/workload identities attributable, permissions least-privilege, and revocation/deprovisioning centrally testable?

• Are high-risk writes, deployments, external sends, and credential changes explicitly constrained, with deterministic input/path/URL validation?

• Can the organization disable the server, revoke credentials, reconstruct material activity, isolate the workflow, and test that response against malicious content or a compromised server?

For Claude Code specifically

• Where hard enforcement is required, are managed MCP/permission rules authoritative - including allowManagedMcpServersOnly, allowManagedPermissionRulesOnly, and permissions.disableBypassPermissionsMode? ⁹ ¹⁰ ¹³

• Is Bash sandboxing enabled where appropriate, and are local MCP processes separately isolated when their privileges or data access warrant it? ⁸ ¹⁵

• Can project-level .mcp.json or user configuration broaden the organization MCP boundary, or is managed policy authoritative?

• Do approval prompts show the tool, target, material inputs, and expected side effect? Are temporary workshop/test servers removed afterward?

Navigating the future of agentic AI securely

The governing principle is simple: security must be designed in from day one. Start with a small, approved set of use cases and expand only after identity, validation, human oversight, observability, and recovery controls work under normal, failure, and adversarial conditions. ¹ ² ⁸