Your team adopted MCP last month so an AI agent could query your CRM, read internal docs, and file Jira tickets. This week, a developer pulled a third-party MCP server from npm, granted it broad OAuth scopes, and pointed it at production data. No security review. No logging. No scope validation at the tool level.
You now have an LLM with write access to sensitive systems, making autonomous decisions based on natural-language tool descriptions that your WAF can't inspect and your API gateway wasn't built to govern.
That's the gap. MCP servers expose an attack surface that traditional API security controls don't cover, because the consumer is an LLM that reads tool descriptions, makes autonomous decisions, and maintains stateful sessions where one stolen token inherits the full scope of every tool granted at session start.
This guide covers the practical controls security teams need at every layer: authentication, authorization, runtime hardening, supply chain vetting, and detection.
Key Takeaways:
MCP servers expose an attack surface that traditional API controls don't cover, because the consumer is an LLM that reads tool descriptions, makes autonomous decisions, and maintains stateful sessions. MCP needs additional controls beyond traditional API gateways and WAFs.
Use OAuth 2.0 with PKCE and short-lived tokens, with per-tool scope validation at every
tools/calldispatch, not just at session initialization.Defend against prompt injection by hash-pinning tool definitions, requiring human approval for high-impact actions, and never co-loading exfiltration-capable tools with untrusted-content-reading tools.
Log every tool call with identity, parameters, and a correlation ID that propagates into downstream audit logs for end-to-end tracing.
Why MCP servers need a dedicated security model
MCP needs a dedicated security model because it connects AI agents to your tools, databases, and APIs through three primitives:
Each one expands the attack surface in ways your existing API controls weren't built for.
The attack surface looks different from a traditional API
MCP changes the attack surface because the consumer is an LLM that reads natural-language tool descriptions and decides what to call, when to call it, and with what arguments.
Three attack vectors stand out.
Tool poisoning embeds malicious instructions in tool descriptions, schemas, metadata, or outputs, which the LLM then processes as trusted directives.
Prompt injection bypasses signature-based inspection entirely because the payloads are syntactically valid natural language. Researchers tested this across 45 live MCP servers with 1,312 malicious test cases and saw attack rates up to 72.8%.
Rug pull attacks exploit
notifications/tools/list_changed, a designed protocol feature, to push tool changes after deployment. A server passes your initial review, then silently changes its behavior.
The first confirmed malicious MCP server, postmark-mcp, exfiltrated emails by automatically BCC'ing them to an attacker-controlled address, and it was downloaded more than 1,600 times before being removed.
MCP sessions are also stateful: authentication occurs once at initialize, and a stolen session token's blast radius equals the full scope of every tool the session was granted.
Why standard API security alone falls short
Standard API security alone falls short because MCP's policy-relevant information lives above the HTTP layer.
Standard API security controls miss MCP's policy-relevant information because that information lives in tool descriptions and LLM reasoning chains, above the HTTP layer where WAFs and gateways operate. WAF signature matching fails because prompt injection payloads are syntactically valid natural language.
Standard HTTP audit logging misses tool invocations entirely. The most important security events on an MCP server happen in a layer your existing logs don't see, which OWASP ranks as a top-10 MCP risk. Existing controls don't go away. MCP just adds a layer above them.
Authenticate and authorize every MCP connection
Authentication and authorization determine the blast radius of every MCP session. The controls below cover session setup, token scope, and server identity so you can decide what to enforce at connection time versus tool execution time.
Use OAuth or scoped tokens, never long-lived secrets
A long-lived shared secret in an MCP server is a credential waiting to leak into an LLM context window.
For MCP authorization, the specification mandates OAuth 2.0 Authorization Code Flow with PKCE, with PKCE required broadly via OAuth 2.1 rather than only for HTTP connections. For service-to-service scenarios like CI/CD pipelines or backend agents, use OAuth 2.0 Client Credentials with JWT-based client authentication rather than shared secrets.
Keep access tokens short-lived for sensitive tool access, and consider refresh token rotation so newly issued tokens can replace prior ones.
Scope permissions to use cases, not just users
Scope permissions to the tool or use case, not to a broad session-wide entitlement.
The most dangerous MCP pattern is granting broad scopes like files:*, db:*, and admin:* at session start. If any prompt injection succeeds, the attacker inherits everything that session was granted.
Instead, use scoped grants per-tool or per-use-case to match what's actually needed. Scope validation must happen at two layers: at session initialization and at every tools/call dispatch. If you only validate at session start, a hijacked session can invoke any tool the token covers.
Begin sessions with minimal scopes and trigger a new authorization request when elevated access is needed, then revoke the token after the action completes.
Verify server identity before clients connect
A misconfigured TLS chain or a spoofed server endpoint can compromise the client before any tool is ever called.
Before your client connects, check TLS certificates by checking chain, hostname, and expiry. For service-to-service deployments, mutual TLS lets the server cryptographically verify client identity too. In cloud-native environments, service meshes like Istio can enforce mTLS transparently using SPIFFE/SVID workload identity.
Constrain what your MCP server can actually do
Capability constraints limit damage when authentication fails or a session is hijacked. The next sections cover narrowing tool access, adding approval gates for sensitive actions, and reducing prompt-injection-driven misuse.
Apply least privilege to tools, resources, and prompts
Enforce least privilege at the tool, resource, and prompt level, not just at the user identity layer.
Maintain allowlists of permitted (tool_name, permitted_arguments, permitted_value_ranges) tuples. For resources, restrict URI access to specific paths. Block localhost, RFC 1918 ranges, and cloud metadata endpoints (169.254.169.254) to prevent SSRF.
The documentation references security best practices and access controls, but does not explicitly enumerate these patterns. Run MCP servers containerized, with restricted filesystem and network access, and no secrets baked into images.
Require human approval for high-impact actions
A delete_user call from an LLM should not execute on its own.
Tool invocations in MCP deployments are often paired with explicit approval and other safeguards, depending on the implementation and operational guidance. As Stephen Gubenia, Head of Detection Engineering for Threat Response at Cisco Meraki, says, "You have to have that human in the loop early and often." Classify actions by impact:
High-impact (file deletion, credential access, admin commands): mandatory explicit approval with a timeout that defaults to deny.
Medium-impact (database mutations, outbound messages): asynchronous approval channels.
Low-impact reads: autonomous execution with logging only.
Defend against prompt injection and tool poisoning
Defending against prompt injection and tool poisoning requires integrity checks and session design.
Hash-pin all tool definitions (name, description, input schema) at registration. On session start, verify tool integrity before proceeding. Use human oversight and analyst approval for high-impact actions before execution resumes.
For cross-server injection, follow one structural rule: never co-load exfiltration-capable tools (email, HTTP POST, file upload) with untrusted-content-reading tools (web search, URL fetch) in the same agent session. Enforce per-server tool namespacing or scoping for all tools to help prevent cross-server shadowing.
Harden the transport, runtime, and supply chain
Once authentication is in place, infrastructure becomes the next control layer. Transport, runtime isolation, secrets handling, and package vetting each affect how much damage a compromised MCP server can do.
Match your transport choice to your threat model
Transport choice is the difference between a local subprocess attack surface and an internet-exposed one.
MCP defines two transports. stdio launches the server as a child subprocess with JSON-RPC over stdin/stdout; use it for local, single-user workloads. Streamable HTTP supports remote, multi-tenant deployments but requires Origin header validation, localhost-only binding when running locally, and HTTP authentication.
Transport-layer vulnerabilities are real, and they're invisible to tool-level analysis. CVE-2026-27826 is an SSRF flaw in mcp-atlassian that no amount of tool schema validation would catch; CVE-2026-27825 is an arbitrary file write vulnerability in the same project.
Manage secrets, sandbox the runtime, and rate-limit connections
Secrets handling, runtime isolation, and rate limiting matter because tool-level controls do not contain a compromised process by themselves.
Never hardcode credentials in MCP server source code or container images. Inject secrets at runtime from a vault service (HashiCorp Vault, AWS Secrets Manager, or similar). For architectures aiming to avoid static secrets, SPIFFE/SPIRE workload identity can remove the need to co-deploy authentication secrets with workloads and replace many stored credentials with attested, short-lived identities.
Sandbox every MCP server runtime. gVisor provides user-space kernel isolation; Kata Containers provide VM-level isolation. Both can be used as alternative container runtimes. Apply network egress restrictions to permit only approved destinations.
Rate-limit MCP connections and tool invocations to contain runaway agents and brute-force abuse. Set per-identity caps on tools/call frequency, cap concurrent sessions per client, and throttle expensive tool categories (outbound HTTP, database writes, file operations) more aggressively than read-only tools.
Vet third-party MCP servers before you install them
Treat third-party MCP servers as supply chain risk, not convenience packages.
The postmark-mcp case is a reminder to vet package publishers and update practices before installing anything. Pin to a specific verified version hash. Check the OpenSSF Scorecard for branch protection, required code review, and signed releases. Vetting at install time isn't enough because rug pull attacks modify behavior after initial approval, so monitoring must be continuous.
Detect and respond to MCP-driven activity
Detection verifies that your preventive controls are working and catches the cases they miss. The next sections cover what to log, which threat patterns to watch for, and how to connect MCP telemetry with identity and SaaS evidence.
Log every tool call with full context
If you can't reconstruct a tool call end to end, you can't investigate it.
Every MCP tool call event should capture identity, tool name, full parameters, response status, and a correlation_id that propagates as X-Request-ID in all outbound HTTP calls made by MCP tools. Include a schema_hash field (SHA-256 of the tool schema at registration) for rug pull detection and a contains_base64 boolean flag for encoded payloads that may obscure exfiltrated content.
As Jason Craig of Remitly explains, "Once you have observable data and an understanding of your environment, you can more easily build your detection and response strategies."
The native MCP log format lacks identity, correlation IDs, and policy decisions. You need all three for any meaningful detection or investigation workflow, and a proxy or gateway layer is what adds them. These specific gaps are well-documented.
Build detections for anomalous tool use and privilege abuse
Build detections around MCP-specific abuse patterns, not just generic API anomalies:
Data harvesting: Abnormally high volumes of identical tool calls from a single identity.
Reconnaissance: Repeated
tools/listcalls beyond the one legitimate call at session start.Prompt injection: Linguistic patterns in tool parameters like "ignore previous instructions" or "SYSTEM:" alongside encoded payloads paired with outbound tools.
Rug pulls: Tool schema changes on servers in use for more than seven days, especially when the diff introduces capabilities like
read,send,execute, oreval.Tool shadowing: Cross-server tool name collisions, the mechanism behind tool shadowing attacks.
Panther can handle these patterns through real-time stream processing rules for acute threats, Scheduled Rules for behavioral drift, and correlation rules for multi-step attack path detection.
Correlate MCP activity with identity and SaaS logs
Correlating MCP telemetry with identity and SaaS logs turns isolated tool events into an investigation trail.
Use correlation_id to trace an MCP tool call through to the downstream action it triggered. Join on identity.user_id to verify IdP session state and device posture. Flag OAuth token reuse after MCP session termination and cross-application data movement within the same session.
Centralizing MCP gateway logs, Okta events, and SaaS audit logs in a single queryable store makes this kind of correlation possible. Docker faced a similar cross-source correlation challenge and centralized everything into one platform for the visibility they needed. That same approach applies directly to MCP monitoring.
PantherFlow functions support this workflow: query MCP gateway logs, use extend to isolate the tool name and calling identity, join with Okta enrichment data, and pivot to SaaS audit logs using the correlation ID as the join key.
Treat MCP security as an evolving discipline
MCP security needs periodic review because the protocol and its guidance are still changing. The protocol transferred to the Agentic AI Foundation under the Linux Foundation in December 2025, and the auth specification is under active revision with multiple open SEPs. Treat your current auth implementations as provisional and monitor the ext-auth repository.
The OWASP MCP Top 10, SAFE-MCP framework, and CSA MCP resources are useful ongoing references.
Anthropic reports Claude Sonnet 4.5 prevents 94% of prompt injection attacks in MCP-related evaluations and shows a 10.8% successful attack rate against earlier safeguards in one evaluation. Those numbers confirm what every detection team already knows: model guardrails are one layer, not a substitute for runtime controls, audit logging, and behavioral detection.
Start with logging, then layer on authentication, least privilege, supply chain vetting, and behavioral detection. Version-pin everything. Re-evaluate quarterly.
If you're building MCP detection capabilities, Panther's combination of log ingestion with automatic schema inference, detection rules in Python, SQL, or YAML, and cross-source correlation through its Security Data Lake can help you bring MCP telemetry into existing investigative workflows.
See it in action
Most AI closes the alert. Panther closes the loop.
Share:
RESOURCES
