MCP Security: The Complete Enterprise Guide to Securing AI Agent Tool Calls

AI agents are no longer just answering questions. They're executing code, querying databases, modifying records, and calling third-party APIs on behalf of your users and employees. The protocol making this possible at scale is the Model Context Protocol (MCP) -- and with that power comes an entirely new class of security risk.

MCP security is the practice of controlling, monitoring, and hardening every interaction between AI agents and the tools they invoke through MCP. It covers authentication, authorization, supply chain integrity, runtime isolation, prompt-layer defense, and governance.

This guide is for platform engineers, security leaders, and architects evaluating how to deploy MCP safely in production. It covers the protocol's architecture, the specific attack vectors that matter, the best practices that mitigate them, and the infrastructure patterns that make security enforceable rather than aspirational.

What Is MCP Security?

MCP security refers to the full set of controls, policies, and architectural patterns that protect the Model Context Protocol layer in agentic AI systems. It governs how agents discover MCP servers, how they authenticate, what tools they can invoke, what data flows through those invocations, and how every action is logged and audited.

To understand why MCP security is distinct from traditional API security, you need to understand the protocol itself.

MCP Architecture Overview

The Model Context Protocol defines a client-server architecture with four key components:

• MCP Hosts are the applications where the AI model runs -- Claude Desktop, an IDE with an AI assistant, or a custom agent framework.

• MCP Clients live inside the host and manage connections to one or more MCP servers. Each client maintains a 1:1 session with a specific server.

• MCP Servers are lightweight programs that expose tools, resources, and prompts through the standardized protocol. They act as the bridge between the AI agent and external systems.

• Tools are the actual capabilities exposed by MCP servers -- things like "search Jira tickets," "query a Postgres database," or "send a Slack message."

The flow works like this: a user sends a prompt to the AI host. The host's MCP client knows what tools are available across connected MCP servers. It sends the prompt and tool descriptions to the LLM, which decides which tool to call and with what parameters. The MCP client routes that call to the correct MCP server, which executes the action and returns results. The LLM processes the results and generates a response.

MCP servers can run locally on a user's machine or remotely as hosted services. Both deployment models carry security risks, but the nature of those risks differs significantly.

Why Traditional Security Controls Fall Short

Traditional API security assumes a deterministic caller. A human or application makes a request, and the server validates credentials, checks permissions, and processes the call. The request path is predictable. The caller's intent is explicit.

MCP breaks this model in several ways:

• The caller is non-deterministic. An LLM decides which tools to invoke based on natural language input. The same prompt can produce different tool calls depending on context, model state, and available tools.

• Instructions and data are blurred. In traditional systems, the instruction (the API call) and the data (the payload) are clearly separated. In MCP, the LLM treats tool descriptions, user prompts, and returned data as a single context stream. Malicious content in any of these can influence tool invocation.

• The attack surface is dynamic. Every new MCP server added to an environment expands what agents can do. Unlike traditional APIs, where endpoints are deployed through change management, MCP servers can be installed by individual developers with no central approval.

• Audit is structurally harder. When an agent chains multiple tool calls across multiple MCP servers to complete a task, the causal chain from user intent to system action becomes difficult to trace without purpose-built observability.

These properties mean that securing MCP requires controls that operate at the agent-tool boundary, not just at the network or application layer.

How the Model Context Protocol Works

Understanding MCP's operational flow is essential for identifying where security controls need to be placed.

Client-Server Architecture Flow

Every MCP interaction follows a structured sequence:

1. Discovery. The MCP client connects to configured MCP servers and retrieves their capabilities -- what tools they offer, what parameters those tools accept, and what resources they expose.

2. Selection. When a user sends a prompt, the MCP client packages the prompt along with available tool descriptions and sends everything to the LLM. The model analyzes the request and selects the appropriate tool.

3. Invocation. The MCP client sends the tool call (with parameters) to the relevant MCP server. The server executes the action against the underlying system -- a database query, an API call, a file operation.

4. Response. The MCP server returns results to the client, which passes them back to the LLM. The model generates a natural language response for the user.

5. Iteration. For complex tasks, the LLM may chain multiple tool calls in sequence, using results from one call to inform the next.

Each step in this flow is a potential security control point. Discovery can be restricted. Selection can be governed. Invocation can be authorized and logged. Responses can be filtered and redacted.

Local vs. Remote MCP Servers

Local MCP servers run on the user's own machine -- often started via a command like npx or uvx and connected through standard I/O (stdio). They have direct access to the local filesystem, environment variables, and running processes. This makes them powerful but also dangerous: a compromised or malicious local server can execute arbitrary commands with the user's privileges.

Remote MCP servers run as hosted services, accessed over HTTP with Streamable HTTP transport. They don't have direct access to the user's machine, but they do hold authentication tokens for the services they connect to. A compromised remote server becomes a proxy for accessing every system those tokens authorize.

Both models require security controls, but the controls differ. Local servers need sandboxing and execution isolation. Remote servers need strong authentication, token management, and network-level protections.

The Role of MCP in Agentic AI Systems

MCP is rapidly becoming the standard integration layer for agentic AI. Major platforms -- including Claude, VS Code with GitHub Copilot, Cursor, and enterprise agent frameworks -- support MCP natively. This means MCP servers are the primary mechanism through which AI agents interact with production systems.

When an agent uses MCP to query your CRM, update your ticketing system, or access your cloud infrastructure -- whether that's an AI agent deployed for workforce productivity or a customer-facing integration -- it's not just reading data. It's performing actions with real consequences. A single misconfigured or malicious tool call can modify records, delete resources, exfiltrate data, or trigger downstream systems.

This is why MCP security is not an enhancement to existing security programs. It's a new discipline.

Why MCP Security Matters for Enterprise Teams

AI Agents Executing Real Actions on Production Systems

The core risk is straightforward: AI agents connected via MCP are performing real operations on real systems. They're not generating suggestions for humans to review. They're executing. When an agent calls a tool that modifies a database record, sends an email, or deploys infrastructure, that action happens immediately. The gap between "the AI suggested something" and "the AI did something" has closed.

For enterprise teams, this means every MCP server in your environment is effectively a privileged service account that an AI controls. If the agent's decision-making can be influenced -- through prompt injection, tool poisoning, or compromised context -- those privileged actions can be weaponized.

Centralized Token Stores as High-Value Targets

MCP servers typically hold OAuth tokens, API keys, or other credentials for the services they connect to. A single MCP server might store tokens for GitHub, Salesforce, Slack, and your internal databases. This concentration of credentials makes MCP servers high-value targets.

If an attacker compromises one MCP server, they don't just gain access to that server's functionality. They gain access to every downstream system those tokens authorize. This is the "keys to the kingdom" scenario that security teams have spent decades trying to prevent -- and MCP re-creates it at a new layer.

Regulatory and Compliance Implications

When AI agents access, modify, and transmit data through MCP, every tool call becomes a compliance event. SOC 2 requires demonstrable access controls and audit trails. GDPR requires knowing what personal data is being processed and by whom. HIPAA requires access logging and minimum necessary access.

Without purpose-built MCP security controls, enterprises cannot demonstrate that their AI agent interactions meet these requirements. The governance gap widens with every new agent connection that lacks audit coverage. The audit question isn't "Do you use AI?" It's "How do you govern what AI agents do with your data?"

The Difference Between MCP and Traditional API Security

Top MCP Security Risks and Attack Vectors

Security researchers and organizations including OWASP, the MCP specification authors, and enterprise security teams have identified seven primary attack vectors.

Prompt Injection Attacks

Prompt injection is the most widely documented MCP security risk, flagged by 8 of 9 top-ranking sources on the topic.

The core vulnerability: LLMs cannot reliably distinguish between legitimate user instructions and malicious instructions embedded in consumed content. When an AI agent reads data through an MCP server -- an email, a document, a web page, a database field -- that content enters the model's context alongside the user's actual instructions.

An attacker can embed instructions in any content the agent consumes. A seemingly innocent email could contain hidden text that instructs the agent to forward sensitive documents to an external address. A Jira ticket description could include commands that trigger the agent to modify permissions in a connected system. A document shared via Google Drive could contain instructions that cause the agent to exfiltrate data from a connected database.

The blurred boundary between "reading content" and "executing instructions" is what makes prompt injection in MCP environments particularly dangerous. In traditional systems, reading a malicious email doesn't trigger actions in your CRM. In an MCP-connected agent, it can.

Mitigation: Input/output validation on all tool calls. Content moderation guardrails between the LLM and MCP servers. PII redaction on returned data. Strict tool scoping to limit what actions an agent can take regardless of what it's instructed to do.

Tool Poisoning and Rug Pull Attacks

Tool poisoning exploits the trust relationship between LLMs and tool descriptions. Every MCP server provides descriptions of its tools -- what they do, what parameters they accept. The LLM uses these descriptions to decide which tool to call.

A malicious MCP server can provide deceptive tool descriptions that instruct the LLM to behave in harmful ways. The tool description might appear normal on the surface, but include hidden instructions that cause the agent to exfiltrate data, bypass security checks, or prefer the malicious tool over legitimate alternatives.

The "rug pull" variant is even more insidious. An MCP server might operate legitimately for weeks or months, building trust. Then, in a quiet update, the server's tool descriptions or behavior changes. A tool originally described as "search customer records" begins silently exfiltrating data. Because the server was previously trusted, many organizations won't catch the change.

As Atlassian's security team noted, slight naming variations can also mislead agents into selecting malicious tools over legitimate ones -- a vector called naming collision or impersonation.

Mitigation: Version-pin all MCP servers. Monitor for tool description changes. Use cryptographic signing to verify server integrity. Implement a gateway that validates tool metadata before exposing tools to agents.

Token Theft and Credential Compromise

MCP servers store OAuth tokens and API credentials for the services they connect to. These token stores represent single points of failure. If an attacker compromises an MCP server -- through a vulnerability in the server code, a supply chain attack on its dependencies, or exploitation of a misconfigured deployment -- they gain access to every connected downstream service.

The centralization of tokens across services also creates cross-service data aggregation risks. An attacker with access to tokens for both your email system and your CRM can correlate data across systems in ways that individual service compromises wouldn't allow. Calendar data combined with email content and file storage access enables sophisticated social engineering and spear-phishing campaigns.

Unlike traditional credential compromise that might trigger suspicious login alerts, token theft through MCP can appear as legitimate API access, making detection significantly harder.

Mitigation: Use short-lived, scoped credentials rather than long-lived tokens. Implement just-in-time credential injection rather than storing tokens in MCP server configurations. Centralize secrets management. Never log credentials in plaintext. Auto-rotate credentials on a defined schedule.

Supply Chain Attacks on MCP Servers

MCP servers are executable code. The ecosystem is growing rapidly, with community-built servers for nearly every major SaaS product, database, and developer tool. Many of these servers are installed directly from GitHub repositories or package registries -- often by individual developers, without security team review.

The supply chain risks mirror those of any open-source ecosystem, but with higher stakes. A compromised MCP server doesn't just run on a developer's machine. It runs with access to every system the developer's agent can reach.

Specific supply chain risks include:

• Typosquatting and poisoned packages. Malicious actors publish MCP servers with names similar to popular legitimate servers.

• Dependency compromise. A vulnerability or backdoor in a transitive dependency of an MCP server propagates to every installation.

• Unsigned builds. Without cryptographic signing, there's no way to verify that the server binary matches the published source code.

• No version pinning. If MCP servers auto-update, a malicious update can propagate instantly across all installations.

Security researchers analyzing the MCP ecosystem have found command injection flaws in 43% of analyzed servers, underscoring the immaturity of security practices in the ecosystem.

Mitigation: Use only verified, audited MCP servers from trusted sources. Pin server versions by digest, not tag. Implement automated scanning with tools like MCP-Scan. Require security review before any new MCP server is approved for your environment. Apply the same SAST and SCA practices you use for any other software dependency.

Server-Side Request Forgery (SSRF)

MCP servers that make HTTP requests on behalf of the AI agent can be exploited as SSRF amplifiers. The MCP specification's security documentation details this risk extensively in the context of OAuth metadata discovery.

During OAuth flows, MCP clients fetch URLs from several sources that could be controlled by a malicious MCP server -- resource metadata URLs, authorization server URLs, token endpoints. A malicious server can populate these fields with URLs pointing to internal resources:

• Cloud metadata endpoints like 169.254.169.254 that expose IAM credentials and instance information on AWS, GCP, and Azure.

• Internal network services on private IP ranges that are normally unreachable from outside the network perimeter.

• Localhost services like databases, admin panels, or caches running on the same machine.

Because the MCP client makes these requests on behalf of the agent, the malicious server effectively uses the client as a proxy to bypass network perimeter controls. Error messages from failed requests can also leak information about internal network topology.

Mitigation: Enforce HTTPS for all OAuth-related URLs in production. Block requests to private and reserved IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16). Validate redirect targets. Use egress proxies for server-side MCP client deployments. Be aware of DNS rebinding attacks where domains resolve to safe IPs during validation but internal IPs during actual requests.

Excessive Permissions and Scope Creep

When MCP servers request OAuth scopes, the path of least resistance is to request broad permissions. A server that needs read access to customer records might request full read-write access to the entire CRM. A server connecting to a cloud provider might request administrator-level scopes.

This creates the confused deputy problem -- a well-understood security vulnerability now manifesting at the MCP layer. The MCP server acts on behalf of the user, but with the server's own (often broader) permissions. If the server is compromised or tricked through prompt injection, those excessive permissions become the attacker's permissions.

The blast radius of any security incident scales directly with the breadth of granted permissions. A stolen token with files:read access is a data exposure incident. A stolen token with files:*, db:*, admin:* access is a full environment compromise.

The MCP specification explicitly warns against scope inflation: publishing all possible scopes in scopes_supported, using wildcard or omnibus scopes, or bundling unrelated privileges to avoid future consent prompts.

Mitigation: Request only the minimum scopes required for each tool's function. Implement progressive scope elevation -- start with read-only access and request write permissions only when a specific operation requires them. Use per-client consent flows so users explicitly approve each client's access. Audit scope usage and revoke unused permissions.

Session Hijacking and Impersonation

MCP's Streamable HTTP transport uses session IDs to maintain state between clients and servers. If an attacker obtains a valid session ID -- through network interception, log exposure, or brute force -- they can impersonate the legitimate client.

The MCP specification documents two session hijacking variants:

Session hijack via prompt injection. In multi-server environments with shared event queues, an attacker who knows a session ID can inject malicious events into the queue. When the legitimate client polls for events, it receives and acts on the attacker's payload -- potentially executing malicious tool calls or receiving poisoned tool definitions.

Session hijack via impersonation. An attacker obtains the session ID and makes direct API calls to the MCP server. If the server relies solely on the session ID for authentication (without additional authorization checks), it treats the attacker as the legitimate user.

Mitigation: Use cryptographically secure, non-deterministic session IDs (e.g., UUIDs from secure random generators). Bind session IDs to user-specific information so a valid session ID alone is insufficient for impersonation. Rotate and expire session IDs. Never use sessions as the sole authentication mechanism -- always verify authorization on every inbound request.

MCP Security Best Practices

Enforce Strong Authentication and Authorization

Authentication and authorization are the foundation of MCP security. Every MCP server interaction should be authenticated, and every tool invocation should be authorized against a defined policy.

Recommended standards:

• OAuth 2.1 for remote MCP server authentication, following the MCP Authorization specification. OAuth 2.1 mandates PKCE for all clients and prohibits the implicit grant, closing several known attack vectors.

• Mutual TLS (mTLS) for server-to-server communication in high-security environments, ensuring both client and server identities are verified.

• Short-lived, scoped credentials rather than long-lived API keys. Tokens should expire and require re-authentication on a defined schedule.

• Per-client consent flows where users explicitly approve what each MCP client can access. Consent decisions should be stored server-side, bound to specific client IDs, and protected against CSRF attacks.

Authorization should be enforced at the tool level, not just the server level. A user authorized to access an MCP server for CRM data should still be constrained to specific operations -- read vs. write, specific record types, specific tenants.

Isolate MCP Server Execution

Every MCP server should be treated as untrusted code running with the minimum privileges necessary.

For local MCP servers:

• Run in a sandboxed environment (container, chroot, or application sandbox) with restricted filesystem and network access.

• Execute as a non-root user with no access to sensitive system directories (home directories, SSH keys, system configs).

• Use stdio transport to limit access to only the MCP client process.

• Display the exact command that will be executed before a user approves a new local server connection, without truncation.

For remote MCP servers:

• Containerize with CPU and memory limits and a read-only filesystem where possible.

• Apply network egress controls so servers can only reach approved endpoints.

• Isolate each server's credential store -- one compromised server should not expose another server's credentials.

Harden the Supply Chain

Treat MCP server adoption with the same rigor as any other software dependency entering your production environment.

• Source from verified providers. Use curated registries and verified publishers rather than unvetted GitHub repositories.

• Cryptographic signing and verification. Require that server builds are signed by the publisher and verify signatures before deployment.

• Version pinning by digest. Pin to immutable content hashes, not mutable tags. A tag can be re-pointed to different code; a digest cannot.

• Automated scanning. Integrate MCP server dependencies into your existing SAST and SCA pipelines. Tools like MCP-Scan can check for known MCP-specific vulnerabilities.

• Change monitoring. Alert when a pinned server's tool descriptions, capabilities, or behavior change -- this catches rug pull attacks.

Implement Runtime Monitoring and Observability

Every tool call through MCP should be logged with sufficient detail for incident investigation and compliance.

What to log:

• Who initiated the action (user identity)

• Which agent performed it (agent identity)

• What MCP server was called

• What tool was invoked with what parameters

• What data was returned

• Timestamp and duration

• Success or failure status

Beyond logging:

• Behavioral anomaly detection. Establish baselines for normal tool usage patterns. Alert when an agent suddenly accesses tools it hasn't used before, calls tools at unusual frequency, or requests data outside its normal scope.

• Audit trails for compliance. Structure logs for export to your SIEM (Splunk, Sentinel, Chronicle, Datadog). Pre-build views for SOC 2, GDPR, and ISO 27001 control mapping.

• Correlation IDs. Assign unique identifiers to each agent session so multi-tool-call chains can be reconstructed end-to-end.

Defend the Prompt Layer

The prompt layer -- where user input, tool descriptions, and returned data converge in the LLM's context -- is the primary attack surface for prompt injection.

• Pre-call validation. Before a tool call executes, validate that the parameters match expected types, ranges, and formats. Flag calls that deviate from the tool's documented schema.

• Post-call filtering. After a tool returns results, scan for sensitive data (PII, credentials, internal URLs) and redact before the data enters the LLM's context.

• Content moderation. Apply safety classifiers to both inputs and outputs to catch malicious instructions embedded in consumed content.

• Strict tool scoping. Limit what tools are available to each agent based on role and task context. An agent handling customer support queries shouldn't have access to infrastructure management tools.

Require Human-in-the-Loop for Critical Actions

Not every tool call needs human approval. But destructive, irreversible, or high-sensitivity actions should require explicit confirmation before execution.

Actions that warrant approval gates:

• Data deletion or modification in production systems

• Credential creation or permission changes

• External communications (sending emails, posting messages, creating tickets)

• Financial transactions or contract modifications

• Infrastructure changes (deployment, scaling, configuration)

Implement risk-scored routing: low-risk read operations execute automatically. Medium-risk modifications trigger a notification. High-risk actions block until a human explicitly approves.

Protect Secrets End-to-End

Credential management is the single highest-leverage MCP security control. If secrets are well-managed, the blast radius of any compromise shrinks dramatically.

• Just-in-time credential injection. Don't store tokens in MCP server configuration files. Inject credentials at runtime from a centralized secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault).

• Auto-rotation. Rotate credentials on a defined schedule. Short-lived tokens that expire and require re-issuance limit the window of exposure for stolen credentials.

• Never log secrets. Sanitize logs, tool outputs, and error messages to ensure credentials never appear in plaintext.

• Redaction at the boundary. If an MCP server returns data that includes secrets, API keys, or connection strings, redact those values before they enter the LLM's context.

MCP Security Governance Framework

Security controls without governance are point solutions. A governance framework makes MCP security systematic, repeatable, and auditable. If you're looking for a deeper dive into how governance applies across your full application stack, see how enterprises govern AI agents across enterprise apps.

Governance Workflow

A mature MCP security governance program follows a lifecycle:

1. Submission. Teams request to add a new MCP server to the environment. The request includes the server's source, purpose, required scopes, and connected systems.

2. Automated scanning. The server is scanned for known vulnerabilities, dependency issues, and MCP-specific risks (tool poisoning, excessive scope requests, unsigned builds).

3. Security review. A security engineer reviews the scan results, evaluates the server's tool descriptions, and assesses the blast radius of the requested scopes.

4. Staged rollout. Approved servers deploy first to a sandbox environment with limited access. Behavior is monitored against baselines before production deployment.

5. Continuous re-validation. Approved servers are periodically re-scanned for new vulnerabilities, dependency changes, or tool description modifications. Any change triggers re-review.

Recommended Roles and Responsibilities

Compliance Mapping

MCP security governance maps directly to existing compliance frameworks:

• SOC 2 (Trust Services Criteria): CC6.1 (Logical access), CC6.3 (Authorized access), CC7.2 (Monitoring), CC8.1 (Change management)

• ISO 27001: A.9 (Access control), A.12 (Operations security), A.14 (System development security), A.15 (Supplier relationships)

• GDPR: Article 25 (Data protection by design), Article 30 (Records of processing), Article 32 (Security of processing)

• HIPAA: 164.312(a) (Access control), 164.312(b) (Audit controls), 164.312(d) (Person authentication)

The Role of an MCP Gateway in Enterprise Security

An MCP gateway is a centralized enforcement layer that sits between MCP clients and MCP servers. It mediates every tool call, applying security policies before requests reach the server and filtering responses before they return to the agent.

What an MCP Gateway Does

• Policy enforcement. Every tool call is evaluated against defined policies -- authorized tools, allowed scopes, permitted parameters, approved data types -- before execution.

• Call logging and audit. Every request and response is logged with full context: who, what, when, which agent, which server, what data. Immutable, tamper-evident logs support compliance and incident investigation.

• Signature verification. The gateway validates that MCP server builds match their cryptographic signatures, catching supply chain tampering before tools are exposed to agents.

• Secret management. Credentials are injected at the gateway layer rather than stored in individual server configurations. The gateway handles token refresh, rotation, and revocation centrally.

• Tool allowlisting. Only approved MCP servers and tools are discoverable by agents. Unapproved servers are invisible, not just blocked.

• Egress control. The gateway restricts outbound traffic from MCP servers to approved endpoints, preventing data exfiltration through nested tool calls or indirect routing.

• Pre/post-call interceptors. Validate arguments before execution. Redact sensitive data from responses. Apply content moderation. Transform outputs to meet data governance requirements.

Gateway vs. Direct MCP Server Access

Without a gateway, each MCP client connects directly to each MCP server. Security controls are scattered -- some in the client configuration, some in server code, some in network policies. There's no single enforcement point, no unified audit trail, and no way to apply consistent policy across all agent-tool interactions.

A gateway centralizes enforcement. Every tool call passes through a single policy layer regardless of which client initiates it or which server handles it. This makes security auditable, policy changes atomic, and incident response possible.

How Agen Provides Gateway-Level Security for Every Tool Call

Agen operates as the governance layer between AI agents and the applications they access. For enterprise teams deploying MCP at scale, Agen provides:

• Identity-aware access control that extends existing IAM models into agent interactions. Define which users can use which agents to access which tools with which permissions.

• Agent identity and trust scoring. Every agent receives a unique identity. Trust scores degrade automatically when agents exhibit anomalous behavior, triggering progressive access restrictions.

• Data governance at the tool-call level. PII redaction, data masking, and scoped data access enforce data classification policies on every MCP interaction.

• Full observability. Every agent action is logged in real time with complete context -- who initiated it, which agent performed it, what system it accessed, what data it touched.

• Anomaly detection purpose-built for agent behavior patterns, distinguishing normal tool usage from compromised or rogue agent activity.

• Deployment flexibility. Runs in your VPC, on-premises, or as a managed cloud service. Your keys, tokens, and logs stay within your security boundary.

• On-device enforcement with Agen Shield. For local MCP servers running on developer workstations, Agen Shield enforces intent restrictions, skill quarantine, and egress controls at the OS level -- before data ever leaves the endpoint.

When other resources tell you to "be careful" with MCP security, Agen gives you the infrastructure to actually enforce it.

MCP Security Checklist for Enterprise Teams

Use this checklist to evaluate your organization's MCP security posture:

Authentication and Authorization

• [ ] All remote MCP servers require OAuth 2.1 authentication

• [ ] Per-client consent flows are implemented and enforced

• [ ] Token scopes follow the principle of least privilege

• [ ] Short-lived, auto-rotating credentials are used instead of long-lived API keys

• [ ] Per-tool authorization policies are defined and enforced

Execution Isolation

• [ ] Local MCP servers run in sandboxed environments (containers, chroot)

• [ ] Remote MCP servers are containerized with resource limits

• [ ] Network egress is restricted to approved endpoints

• [ ] MCP servers execute as non-root with minimal filesystem access

• [ ] Credential stores are isolated per-server

Supply Chain

• [ ] Only verified, audited MCP servers are approved for use

• [ ] Server versions are pinned by content digest

• [ ] Builds are cryptographically signed and signatures are verified

• [ ] MCP server dependencies are included in SAST/SCA pipelines

• [ ] Tool description changes trigger automated alerts and re-review

Monitoring and Observability

• [ ] Every tool call is logged with user, agent, server, tool, parameters, and result

• [ ] Logs export to your SIEM in real time

• [ ] Behavioral baselines are established for normal agent activity

• [ ] Anomaly detection alerts on deviations from baseline patterns

• [ ] Correlation IDs enable end-to-end tracing of multi-tool chains

Prompt Layer Defense

• [ ] Pre-call validators check parameter types, ranges, and formats

• [ ] Post-call filters redact PII, credentials, and sensitive data

• [ ] Content moderation classifiers are applied to inputs and outputs

• [ ] Tool availability is scoped by agent role and task context

Human-in-the-Loop

• [ ] Destructive and high-sensitivity actions require human approval

• [ ] Risk-scored routing is implemented (auto-approve, notify, block)

• [ ] Escalation workflows are defined for flagged actions

• [ ] Approval decisions are logged with full context

Governance

• [ ] A formal MCP server approval workflow exists (submit, scan, review, stage, deploy)

• [ ] Roles and responsibilities for MCP governance are defined

• [ ] Approved servers are re-validated on a defined schedule

• [ ] Governance controls map to your compliance frameworks (SOC 2, ISO 27001, GDPR)

• [ ] Executive reporting on AI agent risk posture is in place

Frequently Asked Questions

What is MCP security?

MCP security is the discipline of protecting the Model Context Protocol layer in agentic AI systems. It covers how AI agents authenticate with MCP servers, what tools they're authorized to invoke, how data flows through tool calls, how credentials are managed, and how every interaction is logged and governed. It spans supply chain integrity, runtime isolation, prompt-layer defense, and organizational governance.

What are the biggest MCP security risks?

The seven primary risks are: prompt injection attacks (malicious instructions embedded in consumed content), tool poisoning and rug pulls (deceptive or silently modified tool descriptions), token theft and credential compromise (MCP servers as high-value credential stores), supply chain attacks (unvetted or compromised MCP server packages), server-side request forgery (MCP servers as SSRF amplifiers), excessive permissions and scope creep (overly broad token scopes enabling lateral access), and session hijacking (impersonation through stolen session IDs).

How do I secure third-party MCP servers?

Source from verified providers. Pin versions by content digest, not tag. Require cryptographic signature verification. Run servers in sandboxed, containerized environments with restricted network access. Implement an MCP gateway that validates tool metadata, enforces scope policies, and logs every call. Monitor for tool description changes that could indicate a rug pull attack. Include MCP server dependencies in your existing vulnerability management program.

What encryption is recommended for MCP communications?

TLS 1.2 or higher for all remote MCP server communications. The MCP specification and OAuth 2.1 both mandate HTTPS for all protocol URLs in production environments, with exceptions only for loopback addresses during development. For high-security environments, mutual TLS (mTLS) provides bidirectional identity verification. Local MCP servers using stdio transport communicate through the operating system's process I/O, which doesn't traverse the network.

How often should MCP security be reviewed?

Continuously for runtime monitoring and anomaly detection. On every change for MCP server additions, version updates, or scope modifications. Quarterly for governance policy reviews and compliance control mapping. Annually for comprehensive security assessments, penetration testing, and framework re-evaluation. Any time a security advisory is published for an MCP server or its dependencies, an immediate re-assessment should be triggered.

What is the confused deputy problem in MCP?

The confused deputy problem occurs when an MCP server performs actions using its own elevated privileges on behalf of a user or agent that shouldn't have those privileges. For example, an MCP proxy server that uses a static OAuth client ID to connect to a third-party API can be exploited by an attacker who tricks the server into granting authorization without proper user consent. The MCP specification's security documentation describes this attack in detail and mandates per-client consent flows as the primary mitigation.

What tools exist for MCP security scanning?

MCP-Scan checks MCP servers for known vulnerabilities and security misconfigurations. Standard SAST tools (Semgrep, CodeQL) can analyze MCP server source code for injection vulnerabilities. SCA tools (Snyk, Dependabot, Grype) detect known vulnerabilities in MCP server dependencies. The OWASP GenAI Security Project publishes a practical guide with a comprehensive list of recommended scanning and monitoring tools for MCP deployments.