MCP-Servers connect AI assistants to tools and data sources and thereby become an attack target themselves. We support architecture, Tool design, authentication, and deployment along established security guidelines.
MCP-Servers are the bridge between AI assistants and external tools or data sources. Any security gap can be exploited to manipulate assistants, siphon off data, or compromise downstream systems. Unlike classic APIs, MCP-Servers often operate with delegated user rights, load Tools dynamically, and chain multiple calls, which amplifies the impact of a single vulnerability. The guide from the OWASP GenAI Security Project, "A Practical Guide for Secure MCP Server Development" (Version 1.0, February 2026), describes this threat picture and defines an "MCP Security Minimum Bar" as a review checklist. The following six points summarize the server-specific threats and the associated core measures.
Manipulated Tool descriptions or metadata can contain hidden instructions that lure the model into unintended actions or data exfiltration. Countermeasures include signed Tool manifests, a formal approval process, and reconciling the advertised function against the actual runtime behavior. Only the minimally necessary fields are exposed to the model.
Because Tool definitions are loaded dynamically and rarely strictly versioned, a previously reviewed definition can later be swapped out for malicious behavior. Cryptographic signatures and version pinning, with verification of signature and hash at load time, prevent such unnoticed changes.
If model-supplied inputs are passed unchecked into system commands, APIs, or database queries, injection and unintended code execution become a risk. Enforce JSON-Schema validation for inputs and outputs, structured JSON Tool calls instead of free text, as well as sanitization and size limits. For high-risk actions, Human-in-the-Loop approvals apply in addition.
MCP-Servers often manage API keys and OAuth tokens; insecure storage, cleartext logging, or overly long caching enable theft and identity takeover. Secrets belong in secrets vaults, never in environment variables, logs, or within the LLM's reach. In addition, short-lived, tightly scoped tokens apply, along with avoiding Token Passthrough to downstream services.
Over-privileged Tools and broad access scopes increase the damage of a single compromised Tool and violate the Least Privilege principle. The guide calls for OAuth 2.1/OIDC with short-lived, tightly scoped tokens, token delegation (RFC 8693) instead of passthrough, and central policy enforcement via a dedicated gateway layer.
Shared sessions, shared identities, or a common execution environment lead to cross-tenant leaks, identity confusion, and resource conflicts. Isolate user, session, and compute contexts strictly, avoid shared state for user data, and enforce per-session quotas with deterministic cleanup. Operation is containerized, as non-root, and network-segmented.
The content on this page is based on the following publicly available guides and studies.
Core source (February 2026, CC BY-SA 4.0): the section "Current Vulnerability Landscape" with the server-specific threats as well as the review checklist "MCP Security Minimum Bar".
Basis for token delegation and on-behalf-of flows; referenced in the OWASP guide as an alternative to Token Passthrough.
Foundation of the OAuth 2.1/OIDC authentication that the guide requires for remote MCP-Servers.
We review the architecture, Tool design, authentication, and deployment of your MCP-Servers along the OWASP guidelines, from threat analysis through assessment to penetration test. Get in touch.
