Securing Model Context Protocol Servers: Security Assessment and a Lightweight Wrapper-Based Hardening Approach

1. Introduction

Large language models (LLMs) are increasingly being integrated into software systems that interact with external tools, application programming interfaces (APIs), files, and system functions. This changes the security profile of LLM based applications. In traditional text generation systems, the model mainly produces textual output, whereas in tool integrated systems, the model may become part of an execution workflow that accesses resources or triggers external actions. The Model Context Protocol (MCP), introduced by Anthropic, provides a standardized way for LLM based hosts and clients to connect with external tools, resources, and prompts [1]. Although MCP improves interoperability and extensibility, it also introduces a security sensitive boundary where exposed tools must be carefully controlled.

Existing LLM security guidance shows that tool integrated systems are exposed to risks such as prompt injection, sensitive data disclosure, insecure tool use, and excessive agency [2]. In MCP based deployments, these risks are combined with conventional software security issues such as weak authentication, missing authorization, insufficient input validation, poor logging, and lack of rate control. When an MCP server exposes tools such as file access, command execution, or API operations without sufficient security controls, an attacker may invoke restricted tools, access sensitive files, manipulate requests, replay tokens, or exhaust server resources. Current MCP focused studies highlight risks such as unsafe tool exposure, weak access control, and excessive permissions. However, less attention has been given to practical deployment level hardening that can be added in front of an existing MCP server without modifying the server implementation or changing the protocol. This gap motivates the wrapper-based approach evaluated in this paper.

This work addresses that practical deployment problem by evaluating whether a lightweight FastAPI-based wrapper placed in front of an MCP server can reduce common security risks while preserving legitimate functionality and maintaining acceptable overhead. The wrapper enforces security checks before requests reach the MCP server, including authentication, authorization, request validation, path and command restrictions, logging, and rate limiting. This work has three main contributions. Firstly, it presents a structured security assessment of an insecure MCP server using controlled test cases mapped to Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege (STRIDE) threat categories. Secondly, it designs and implements a modular security wrapper that can be positioned in front of an MCP server without modifying the original server. Thirdly, it evaluates the wrapper using controlled experimental scenarios, including attack cases, rate-limit and denial-of-service cases, false-positive checks, and legitimate-use validation cases. The results show a 96% reduction in successful security attacks while maintaining expected legitimate functionality and introducing limited overhead. Rather than proposing a new MCP protocol or a complete MCP security framework, this paper provides a practical, deployment-oriented hardening approach for MCP based AI systems. The findings are limited to the controlled experimental environment and should not be interpreted as proof of complete security against all MCP or LLM-agent attacks.

The remainder of this paper is organized as follows. Section 2 presents the related work and background on MCP, tool integrated LLM security, prompt injection, and existing MCP security approaches. Section 3 describes the methodology and system design, including the baseline MCP server, threat model, wrapper architecture, and security controls. Section 4 presents the experimental setup, test scenarios, metrics, and results. Section 5 discusses the interpretation of the results, practical implications, and limitations. Section 6 concludes the paper and outlines future work.

2. Related Work and Background

Elements of MCP architecture are a host, an MCP client, and an MCP server. Typically, the host is a user-facing application such as an integrated development environment or a chat interface. The MCP client creates a session with an MCP server, while the server connects the capabilities in the form of tools, resources, and prompts. Tools perform actions, resources provide data, and prompts guide behavior. Communication is performed through structured JSON-RPC messages over supported transports. This architecture gives LLM agents a standardized way to interact with external systems, but it also places the MCP server at an important security boundary because exposed tools may interact with sensitive files, commands, APIs, or data sources [1]. The security risks of tool integrated LLM systems differ from those of ordinary text generation systems. When an LLM is allowed to call tools or influence external actions, malicious instructions can have consequences beyond the generated text. Prompt injection demonstrates this problem clearly. A prompt injection attack attempts to override or manipulate the intended instruction hierarchy by placing adversarial instructions inside content processed by the model [3]. Indirect prompt injection extends this risk by hiding malicious instructions inside external or retrieved content, allowing the attacker to influence the system without directly controlling the user prompt [4]. These issues are relevant to MCP because tool descriptions, resource payloads, file contents, and user inputs may all become part of the context that influences tool selection or tool execution.

Recent MCP focused studies have identified risks such as weak authentication, unauthorized tool invocation, excessive tool permissions, unsafe file access, and command execution. Kumar et al. proposed MCP Guardian as a security first layer for MCP based AI systems and highlighted identity spoofing and invocation of unauthorized tools as important risks [6]. Hasan et al. studied MCP server implementations and reported inconsistencies in authentication and maintainability practices on open-source MCP servers [7]. Radosevich and Halloran analyzed MCP safety risks and showed that excessive tool capabilities can allow major security exploits when LLMs are connected to tools without adequate restrictions [8]. MCP Guard proposes a multistage defense-in-depth approach to secure MCP in agentic AI systems [9]. ETDI focuses on tool identity and policy based access control using OAuth enhanced tool definitions [10]. SAMOS focuses on information flow control for securing MCP based agent workflows [11]. Other studies such as MCPSecBench and systematic MCP security analyses provide benchmarking environments and vulnerability taxonomies for MCP security evaluation [12,13].

Most Critical MCP security risk is Weak or missing authentication. MCP server could exposes tools to unauthorized user without verifying caller identity, an unauthorized user may directly invoke privileged capabilities. Authentication weaknesses may include no token requirement, static tokens without expiration, missing claim validation, lack of role separation, or failure to prevent token replay. MCP Guardian and other MCP security studies highlight unauthorized tool invocation and identity spoofing as major risks in MCP based AI systems [6]. Empirical studies of MCP servers also indicate that authentication and security practices can vary across implementations, making deployment level enforcement important [7]. Over broad file access is another important vulnerability category. File related MCP tools may allow a caller to read or list files outside the intended directory if canonical path validation and sandboxing are not enforced. Traditional path traversal attacks can reappear in MCP deployments when file paths are accepted from tool arguments without strict validation [21,22]. In a tool integrated AI environment, this risk is particularly concerning because sensitive files such as environment variables, configuration files, credentials, logs, or key material may be reachable through exposed file tools. Prior MCP security analyses emphasize that excessive tool capabilities and insufficient file boundaries can result in sensitive data exposure [8,9]. Arbitrary command execution represents a higher impact class of vulnerability. If an MCP server exposes a shell execution tool without proper authentication, role enforcement, or command filtering, an attacker may execute operating system commands, chain commands, enumerate the system, modify files, or attempt broader compromise. Command injection is a well known software security weakness caused by unsafe handling of attacker controlled command strings [23,24]. In MCP deployments, the risk becomes more significant because command execution may be exposed through a tool interface that can be called by an agent workflow or by a malicious request. Prompt injection and response leakage create additional MCP specific concerns. Prompt injection can target natural language fields such as echo payloads, file contents, tool descriptions, or other text processed by an LLM workflow. Response leakage occurs when an MCP server returns sensitive information such as secrets, API keys, private key material, or configuration data to the caller. These risks show that MCP security cannot rely only on traditional perimeter defenses. It also requires request validation, response inspection, least privilege access, and logging.

Recent MCP security studies further show that MCP risks extend beyond individual server misconfiguration. Hou et al. analyze the MCP lifecycle and identify security risks across creation, deployment, operation, and maintenance phases, including malicious developers, external attackers, malicious users, and insecure implementations [26]. MCP Security Bench extends this line of work by evaluating attacks across the MCP tool use pipeline, including task planning, tool invocation, and response handling [27]. Huang et al. apply STRIDE and DREAD threat modeling to MCP implementations and identify tool poisoning and prompt injection as important risks across MCP clients, servers, external data stores, and authorization components [28].

Recent defense oriented works are especially relevant to the proposed wrapper. AgentBound introduces an access control framework for MCP servers using declarative policies and a runtime enforcement engine without requiring MCP server modification [29].AgentBound is especially close to this work because it also focuses on external security mechanism without MCP server modification; however, it emphasizes on declarative policies and a policy enforcement engine, whereas this paper evaluates a FastAPI wrapper combining authentication, validation, prompt filtering, response inspection, rate limiting, and audit logging. MCP Secure proposes a lightweight runtime access control layer that applies scoped access, read only defaults, and approval gated privilege elevation during tool invocation [30]. Protocol level solutions such as MCPSec and SMCP propose stronger identity, attestation, authentication, message verification, policy enforcement, and audit mechanisms at the protocol level [31,32]. These works are complementary to the present study. Unlike protocol level solutions, the proposed FastAPI wrapper focuses on deployment level hardening of an existing MCP server by combining authentication, role based tool allow listing, input validation, prompt filtering, response inspection, rate limiting, and audit logging without modifying the baseline MCP server.

Wrapper based hardening follows a gateway or proxy style security model. In such a model, security checks are placed between the client and the backend service, allowing authentication, authorization, validation, monitoring, and logging to be centralized [16,17]. For MCP, this is useful because many MCP servers may be rapidly developed or externally managed and may not include strong native security controls. A wrapper can intercept JSON-RPC requests before they reach sensitive tools, apply policy decisions, and inspect responses before returning them to the caller. This design does not replace deeper protocol level protections, but it provides a practical layer that can be added to existing deployments.

The research gap addressed in this paper is the lack of focused empirical evaluation of a lightweight, deployment level wrapper for MCP servers using controlled attack scripts, STRIDE mapping, and performance measurement. Existing work identifies several important MCP risks, but there is still a need to quantify how much protection can be achieved by an external wrapper and what operational cost it introduces. This paper addresses that gap by implementing and evaluating a FastAPI-based wrapper that enforces JWT authentication, role-based tool allow listing, path validation, command filtering, prompt injection filtering, threat scoring, response inspection, rate limiting, and audit logging.

To position the proposed wrapper within the current MCP security landscape, Table 1 compares the security capabilities of representative MCP security approaches. The comparison highlights that the proposed solution provides practical runtime protection without requiring modifications to the underlying MCP protocol.

3. Methodology and System Design

This study follows a controlled experimental design to evaluate the effectiveness of a lightweight security wrapper for Model Context Protocol (MCP) servers. Two environments were deployed under identical conditions. Environment A consisted of an insecure MCP server. Environment B used the same MCP server but placed a FastAPI-based security wrapper in front of it. Both environments ran on the same machine and used the same operating system, Python version, dataset directory, and attack scripts. The presence of the wrapper was the only experimental variable. This design allowed the security impact of the wrapper to be evaluated while minimizing the influence of external factors [14]. The experiments used simulated MCP request execution rather than live LLM agent interactions. This approach provided repeatable testing conditions and ensured consistent execution across all scenarios. It also allowed the evaluation to focus on request-level security enforcement without introducing variability from model behaviour. The results therefore reflect the effectiveness of the security controls applied to MCP requests rather than the behaviour of a specific language model.

3.1. Threat Model and STRIDE Mapping

The threat model was organized using the STRIDE framework[15], which classifies threats into spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege Shown in Table 2. Spoofing threats were represented through forged or missing authentication. Tampering threats included malicious input manipulation, command abuse, and prompt injection. Information disclosure focused on unauthorized file access and secret leakage. Denial-of-service threats were represented through request flooding and rate-limit exhaustion. Elevation of privilege involved low-privilege users attempting to invoke high-privilege tools. Repudiation was addressed through audit logging rather than direct attack simulation.

3.2. Baseline MCP Server and Tool Risk Model

The baseline MCP server was implemented using the MCP Python SDK and ran locally on port 8000. The server was intentionally left insecure to provide a clear baseline for comparison. It exposed five tools: read_file, list_directory, write_file, shell_exec, and echo. These tools represent common MCP capabilities and expose realistic attack surfaces related to file access, command execution, file modification, and prompt manipulation. The baseline server did not enforce authentication, role-based access control, path validation, command filtering, rate limiting, response inspection, or audit logging.

Table 3. Baseline MCP tools and associated security risks.

Tool	Function	Security Risk
read_file	Reads file contents	Unauthorized file access and information disclosure
list_directory	Returns directory listings	Directory enumeration and exposure of file structure
write_file	Writes data to files	Unauthorized file modification and data tampering
shell_exec	Executes system commands	Arbitrary command execution and privilege abuse
echo	Returns user input	Prompt injection and malicious payload reflection

Table 3. Baseline MCP tools and associated security risks.

Tool	Function	Security Risk
read_file	Reads file contents	Unauthorized file access and information disclosure
list_directory	Returns directory listings	Directory enumeration and exposure of file structure
write_file	Writes data to files	Unauthorized file modification and data tampering
shell_exec	Executes system commands	Arbitrary command execution and privilege abuse
echo	Returns user input	Prompt injection and malicious payload reflection

3.3. Proposed Wrapper-Based Security Architecture

The security wrapper was implemented using FastAPI and operated on port 8080. The wrapper acted as an external gateway between the caller and the MCP server. All requests were processed through a security pipeline before reaching the backend server. Requests that failed any security check were rejected immediately and were not forwarded to the MCP server. Requests that passed all checks were forwarded for processing, and the resulting responses were inspected before being returned to the caller.

Figure 1. High-level architecture of the proposed MCP security wrapper. Requests are routed through the FastAPI wrapper before reaching the MCP server.

Figure 1. High-level architecture of the proposed MCP security wrapper. Requests are routed through the FastAPI wrapper before reaching the MCP server.

3.4. Security Pipeline and Wrapper Components

The wrapper applies authentication, authorization, validation, threat assessment, and response inspection controls before forwarding approved requests and returning validated responses to the client Shown in Figure 2. The request-processing pipeline begins with JWT based authentication. The wrapper validates tokens supplied through the HTTP Authorization header before any request is processed. Validation includes token structure, signature integrity, expiration time, issued-at time, required claims, and replay status. The required claims include sub, role, iat, exp, and jti. Replay protection is implemented using token identifiers, which prevents previously used tokens from being accepted again. The wrapper also restricts validation to the configured signing algorithm to prevent algorithm-substitution attacks. Requests that fail any authentication check are rejected before reaching the MCP server [18].

After authentication, the wrapper applies rate limiting to protect against excessive request volumes and resource exhaustion attempts. A sliding-window mechanism tracks request frequency using caller identity and source address. Requests that exceed configured thresholds receive an HTTP 429 response [19]. The wrapper then enforces role-based access control through a policy engine that restricts tool usage according to assigned permissions [20]. Three roles are supported: user, analyst, and admin. Each role is granted access only to the tools required for its intended function, reducing unnecessary privileges and limiting exposure to high-risk operations.

Additional protection was provided through input validation, prompt filtering, threat scoring, and response inspection. File-related requests were validated through path normalization and sandbox enforcement to prevent unauthorized access outside approved directories. Command arguments were inspected for dangerous operators, chaining patterns, and high-risk execution attempts. A lightweight prompt guard identified common prompt injection and jailbreak patterns before requests reached sensitive tools. The threat-scoring component evaluated multiple request characteristics and assigned a cumulative risk score. Requests exceeding predefined thresholds were blocked before being forwarded to the MCP server.

Table 4. Role-based tool permissions.

Role	Tools	Purpose
User	read_file, list_directory, echo	Read access
Analyst	read_file, list_directory, echo, write_file	Data analysis
Admin	All tools	Administration

Table 4. Role-based tool permissions.

Role	Tools	Purpose
User	read_file, list_directory, echo	Read access
Analyst	read_file, list_directory, echo, write_file	Data analysis
Admin	All tools	Administration

The input validator protects file and command operations. For file-related tools, the supplied path is decoded, normalized, resolved, and compared against an allowed root directory. This is intended to prevent direct path traversal, encoded traversal, and access outside the configured sandbox. Path traversal is a known security weakness where attackers use path manipulation to access files outside the intended directory [21,22]. For shell execution, the validator checks command strings for dangerous operators, chaining patterns, and high-risk command keywords. This control addresses command injection risk, which occurs when attacker-controlled input is passed into a command interpreter [23,24]. The threat scorer assigns a cumulative risk score to each request based on suspicious features. High-risk tools, suspicious argument patterns, and combinations of warning signals increase the score. Requests above the blocking threshold are rejected, while requests above the alert threshold are logged for monitoring. The response inspector examines outgoing responses for secret-like patterns before they are returned to the caller. It searches for patterns such as AWS style key strings, private key headers, environment style key value assignments, database connection strings, and generic API key like values. If such content is detected, the wrapper blocks or redacts the response. The audit logger writes structured JSONL records for processed requests, including timestamp, caller identity, method or tool name, status code, triggered security rule, and threat score. This supports traceability and post-incident analysis, consistent with security log management guidance [25]. Table 5 summarizes the relationship between wrapper components, test cases, and STRIDE coverage. The components are designed as independent layers of defense. Authentication verifies identity, the policy engine restricts privileges, the input validator constrains file and command arguments, the prompt guard detects known prompt manipulation patterns, the threat scorer evaluates combined risk, the response inspector prevents leakage after tool execution, the rate limiter protects availability, and the audit logger records security-relevant events.

3.5. Dataset and Synthetic Sensitive Assets

The experimental dataset was designed to resemble realistic enterprise assets while avoiding the use of real sensitive information. The dataset included customer records, financial documents, configuration files, system logs, and simulated secrets. The simulated secrets included environment-style key-value pairs, credential-like values, and private-key-like content. These resources supported realistic file access, exfiltration, and response leakage scenarios during testing while ensuring that no real sensitive data were exposed.

3.6. Test Case Design

The evaluation used controlled scenarios grouped into nine test suites. The test suites covered authentication attacks, file access and exfiltration, command execution, evasion and obfuscation, prompt injection, response leakage, token replay and JWT abuse, denial-of-service behaviour, and legitimate use validation. Together, these test suites provided coverage across the STRIDE threat categories and represented realistic attack patterns that may be encountered in MCP deployments.The attack scripts used the httpx library to send MCP-style HTTP requests with JSON-RPC payloads. This approach provided direct control over request headers, authentication tokens, and payload contents. The same scripts were executed against both environments by changing only the target port. This ensured that both environments were evaluated using identical attack conditions.

Table 6. Test suite overview and evaluation purpose.

ID	Category	Attacks	Techniques Covered
TC1	Authentication Attacks	6	No token, garbage JWT, wrong secret, privilege escalation
TC2	File Access and Exfiltration	13	Path traversal, direct unauthorized reads, URL encoded traversal,
			secret file access, and 3 policy compliant sandboxed file reads
			used for allowed residual risk validation
TC3	Command Execution	10	Direct shell, chaining, RCE, log tampering, reconnaissance
TC4	Evasion and Obfuscation	10	URL encoding, Base64, Unicode, null byte, homoglyphs
TC5	Prompt Injection	13	Instruction override, DAN, SYSTEM tag, INST token, chained,
			Legitimate inputs flagged as malicious (keywords, patterns,
			prompt guard triggers)
TC6	Response Manipulation	10	Secret pattern detection, PEM keys, AWS keys, .env content
TC7	Token Replay and JWT Abuse	10	Expired, none-alg, jti replay, clock skew, aud mismatch
TC8	Denial of Service attack	10	Burst, rotation, concurrent, slow drain, large payload flood
TC9	Legitimate Use Validation	3	Normal user requests (echo, safe file read) to ensure functionality
			is not blocked

Table 6. Test suite overview and evaluation purpose.

ID	Category	Attacks	Techniques Covered
TC1	Authentication Attacks	6	No token, garbage JWT, wrong secret, privilege escalation
TC2	File Access and Exfiltration	13	Path traversal, direct unauthorized reads, URL encoded traversal,
			secret file access, and 3 policy compliant sandboxed file reads
			used for allowed residual risk validation
TC3	Command Execution	10	Direct shell, chaining, RCE, log tampering, reconnaissance
TC4	Evasion and Obfuscation	10	URL encoding, Base64, Unicode, null byte, homoglyphs
TC5	Prompt Injection	13	Instruction override, DAN, SYSTEM tag, INST token, chained,
			Legitimate inputs flagged as malicious (keywords, patterns,
			prompt guard triggers)
TC6	Response Manipulation	10	Secret pattern detection, PEM keys, AWS keys, .env content
TC7	Token Replay and JWT Abuse	10	Expired, none-alg, jti replay, clock skew, aud mismatch
TC8	Denial of Service attack	10	Burst, rotation, concurrent, slow drain, large payload flood
TC9	Legitimate Use Validation	3	Normal user requests (echo, safe file read) to ensure functionality
			is not blocked

3.7. Evaluation Metrics

Several evaluation metrics were collected during testing. These included attack success rate, vulnerability reduction, response-time overhead, evasion resistance, false-positive rate, rate-limit mitigation, legitimate-use pass rate, and residual risk. Attack success rate measured whether an attack achieved its intended objective. Vulnerability reduction measured the decrease in successful attacks after deploying the wrapper. Performance metrics focused on response-time and memory overhead, while false-positive analysis evaluated the impact of security controls on legitimate requests.

Table 7. Evaluation metrics used in the study.

Metric	Definition	Scope
Attack Success Rate	(Successful attacks / Total attacks) × 100	Per environment and per TC
Vulnerability Reduction	$(V_{\mathrm{before}}-V_{\mathrm{after}})/V_{\mathrm{before}}\times 100$	Overall and per STRIDE class
Response Time Overhead	$({\mathrm{AvgTime}}_{\mathrm{hardened}}-{\mathrm{AvgTime}}_{\mathrm{insecure}})/{\mathrm{AvgTime}}_{\mathrm{insecure}}\times 100$	Per TC and overall
Evasion Resistance Score	(Blocked evasion attempts / Total evasion attempts) × 100	TC4
False Positive Rate	(Incorrectly blocked legitimate requests / Total legitimate) × 100	Legitimate request suite

Table 7. Evaluation metrics used in the study.

Metric	Definition	Scope
Attack Success Rate	(Successful attacks / Total attacks) × 100	Per environment and per TC
Vulnerability Reduction	$(V_{\mathrm{before}}-V_{\mathrm{after}})/V_{\mathrm{before}}\times 100$	Overall and per STRIDE class
Response Time Overhead	$({\mathrm{AvgTime}}_{\mathrm{hardened}}-{\mathrm{AvgTime}}_{\mathrm{insecure}})/{\mathrm{AvgTime}}_{\mathrm{insecure}}\times 100$	Per TC and overall
Evasion Resistance Score	(Blocked evasion attempts / Total evasion attempts) × 100	TC4
False Positive Rate	(Incorrectly blocked legitimate requests / Total legitimate) × 100	Legitimate request suite

4. Experiments and Evaluation

4.1. Experimental Setup and Execution Procedure

The experiments were conducted on a Windows 11 machine with an Intel Core i7 processor, 16 GB RAM, and Python 3.12. Both environments were executed over the loopback interface to avoid external network variability. The insecure MCP server ran on port 8000, and the FastAPI wrapper ran on port 8080.

Figure 3. Experimental deployment setup

Figure 3. Experimental deployment setup

The same dataset and attack scripts were used for both environments. For each individual scenario, the experiment runner recorded the attack identifier, target environment, HTTP response status, result classification, and execution time. In the hardened environment, additional wrapper-specific information was recorded, including the security stage that rejected the request, authentication outcome, tool allow-list decision, path validation result, command filter result, and computed threat score.

4.2. Attack Success Rate and Vulnerability Reduction

The evaluation shows that the wrapper substantially reduced vulnerability exposure compared with the insecure baseline. Across the 69 attack cases, the verified vulnerability reduction is 96% Shown in Table 8. The 96% reduction was calculated by comparing successful attack outcomes in the insecure baseline with successful attack outcomes after wrapper enforcement; legitimate-use validation cases were excluded from this calculation. In the insecure environment, tested attacks succeeded across the evaluated attack categories because the baseline server did not enforce authentication, role based access control, path validation, command filtering, response inspection, rate limiting, or audit logging. In the hardened environment, the wrapper blocked all tested attacks in several categories, including authentication abuse, command execution, evasion and obfuscation, token replay and JWT abuse, response leakage, and rate-limit exhaustion.

File access risk was reduced through sandboxing and path validation, although some policy compliant operations were intentionally allowed. Prompt injection attacks were blocked against the tested patterns, but the strict rule-based prompt guard also produced false positives for benign inputs that resembled attack patterns.

4.3. STRIDE-Based Results

The STRIDE analysis showed that the wrapper provided coverage across all six threat categories evaluated in this study.Table 9 shows the STRIDE based results. Spoofing threats were addressed through JWT validation, token expiry checks, issued-at validation, algorithm restrictions, and replay protection. Tampering threats were mitigated using input validation, command filtering, prompt guard checks, and threat scoring. Information disclosure risks were reduced through file sandboxing and response inspection. However, policy-compliant file operations were intentionally allowed. Denial-of-service threats were mitigated through rate limiting, while elevation of privilege was addressed through role-based tool restrictions. Repudiation was not evaluated through a dedicated attack scenario. Instead, the wrapper supported traceability through comprehensive audit logging of requests and outcomes.

4.4. Denial of Service and Rate Limiting Evaluation

The rate limiting evaluation demonstrated a clear difference between the two environments. The insecure server accepted all request flooding attempts without restriction. In contrast, the hardened environment returned HTTP 429 responses once the configured threshold was exceeded. All TC8 scenarios were successfully mitigated. This corresponds to 100% mitigation for the tested denial-of-service cases. However, this should not be interpreted as complete protection against all forms of DoS attacks. A small number of requests may still be processed before the threshold is reached, which is expected behaviour in threshold-based rate-limiting systems.

4.5. Evasion Resistance

The evasion and obfuscation results showed that the input validator successfully blocked all TC4 attack variants. These included encoded path traversal attempts, Unicode-based variations, null-byte payloads, and other bypass techniques used in the test suite. This suggests that the wrapper relies on input normalization and validation rather than simple string matching. However, the result should be interpreted only within the scope of the evaluated attacks. It does not guarantee protection against future or previously unseen obfuscation techniques.

4.6. False Positive Analysis

The false positive analysis revealed a limitation of the rule-based filtering approach. Three legitimate requests were incorrectly blocked. These included an academic discussion of prompt injection, an OWASP reference URL used for learning purposes, and a sample credential string used for demonstration. The purpose of these tests was to determine whether strict filtering rules could affect normal usage. The results indicate that pattern-based detection is effective against known attack indicators, but it may also flag benign security-related content that resembles malicious input.

Table 10. False-positive scenarios and wrapper outcome.

Scenario	Input Description	Insecure Result	Hardened Result
TC5.11 Academic prompt-injection discussion	Benign educational sentence: “ignore previous instructions” used only as a classroom/example phrase. Tests whether the prompt guard over-blocks academic security discussion	Passed (no guard)	Blocked
TC5.12 Legitimate security-learning URL	Benign URL: https://owasp.org used for security learning. Tests whether URL filtering is too broad.	Passed (no guard)	Blocked
TC5.13 Dummy credential example	Benign placeholder text: password=sample123. Tests whether the response inspector over-redacts non-real secrets	Passed (no guard)	Blocked

Table 10. False-positive scenarios and wrapper outcome.

Scenario	Input Description	Insecure Result	Hardened Result
TC5.11 Academic prompt-injection discussion	Benign educational sentence: “ignore previous instructions” used only as a classroom/example phrase. Tests whether the prompt guard over-blocks academic security discussion	Passed (no guard)	Blocked
TC5.12 Legitimate security-learning URL	Benign URL: https://owasp.org used for security learning. Tests whether URL filtering is too broad.	Passed (no guard)	Blocked
TC5.13 Dummy credential example	Benign placeholder text: password=sample123. Tests whether the response inspector over-redacts non-real secrets	Passed (no guard)	Blocked

4.7. Performance Overhead

The performance results indicate that the wrapper introduced only a small operational overhead. The average response time increased from approximately 272 ms in the baseline environment to 275 ms in the hardened environment. This represents an increase of about 3 ms, corresponding to 1.1%. Memory consumption increased from 51.0 MB to 55.3 MB, resulting in an overhead of 4.3 MB or 8.4%. Despite these additional security controls, normal system functionality was preserved. TC8 was excluded from the latency comparison because rate limiting intentionally alters request timing by rejecting requests that exceed the configured threshold.

Table 11 summarizes performance overhead.

4.8. Residual Risk Analysis

The residual risk assessment showed that the wrapper did not indiscriminately block all requests. Several policy compliant operations were successfully allowed. These included authenticated access within assigned roles, file reads within the approved sandbox directory, and standard echo requests. Such actions represent acceptable residual risk under the defined security policy rather than a failure of the wrapper. TC9 also confirmed that legitimate user activities remained functional in the hardened environment. This shows that the wrapper reduced the threat exposure while preserving normal MCP functionality. Audit logs also provided traceability for permitted operations, supporting monitoring and investigation in practical deployments.

Table 12. Residual risk scenarios allowed by policy and Legitimate Usecase

Scenario	Insecure (Allowed)	Hardened (Allowed)	Policy Reason/ Validation Outcome
Low-risk authenticated access	1 / 1	1 / 1	Permitted by RBAC: complies with user role
Benign file read within sandbox	1 / 1	1 / 1	Path inside ALLOWED_ROOT: no violation
Safe command under policy	1 / 1	1 / 1	Command passes all validator checks
Valid auth and echo call	1 / 1	1 / 1	Request processed normally end to end
Safe file read within sandbox	1 / 1	1 / 1	Path accepted : within ALLOWED_ROOT
Normal user request	1 / 1	1 / 1	No pipeline stage triggered a block

Table 12. Residual risk scenarios allowed by policy and Legitimate Usecase

Scenario	Insecure (Allowed)	Hardened (Allowed)	Policy Reason/ Validation Outcome
Low-risk authenticated access	1 / 1	1 / 1	Permitted by RBAC: complies with user role
Benign file read within sandbox	1 / 1	1 / 1	Path inside ALLOWED_ROOT: no violation
Safe command under policy	1 / 1	1 / 1	Command passes all validator checks
Valid auth and echo call	1 / 1	1 / 1	Request processed normally end to end
Safe file read within sandbox	1 / 1	1 / 1	Path accepted : within ALLOWED_ROOT
Normal user request	1 / 1	1 / 1	No pipeline stage triggered a block

5. Discussion

5.1. Interpretation of Security Findings

The results highlight that an insecure MCP server can have serious security risks when high impact tools are connected without authentication, authorization, validation, rate limiting, or logging. The insecure baseline allowed attacks to succeed across the tested categories, confirming that deployment level misconfiguration can turn MCP tool exposure into a significant attack surface. The FastAPI based wrapper reduced vulnerability exposure by 96% in the controlled evaluation and blocked all tested attacks in several categories. These findings support the argument that an external wrapper can provide meaningful runtime hardening without modifying the underlying MCP server.

5.2. Security–Usability Trade-Off

The results highlight the tradeoff of the security mechanism with usability. The prompt guard blocked the tested prompt injection patterns, but it also blocked benign inputs that resembled malicious payloads. This demonstrates the limitation of static pattern matching. A more semantically aware detector could reduce false positives by considering context, but it would likely introduce additional latency, complexity, and dependency on an external model or classifier. The current wrapper deliberately favors lightweight and interpretable controls, which makes it easier to deploy but less capable of understanding subtle semantic attacks.

5.3. Comparison with Existing MCP Security Approaches

Compared with existing MCP security work, the proposed wrapper occupies a practical deployment level position. Benchmarking studies and systematic analyses are valuable because they identify vulnerabilities and provide evaluation frameworks, but they do not necessarily enforce runtime protection [12,13]. Protocol level or cryptographic approaches can provide stronger trust guarantees, but they may require changes to the protocol or wider ecosystem support. Detection focused frameworks such as MCP Guard provide stronger multi stage analysis for runtime threat detection, but deployment complexity and enforcement focus differ from the lightweight wrapper design [9]. ETDI strengthens tool identity and authorization, while SAMOS addresses data-flow restrictions in MCP-based workflows [10,11]. The wrapper in this paper is not a replacement for these approaches. Instead, it complements them by providing a deployable external security layer that combines authentication, authorization, input validation, prompt filtering, response inspection, rate limiting, and logging. The practical value of the wrapper comes from its ability to protect an existing MCP server without requiring changes to the server implementation. This is useful when the MCP server is legacy, externally managed, rapidly developed, or difficult to modify.

5.4. Scalability and Deployment Considerations

The modular design allows individual controls to be tuned according to deployment needs. For low risk tools, authentication and logging may be sufficient. For high risk tools stronger controls such as role based access control, path validation, command filtering, response inspection, and rate limiting can be additionally enabled. This makes the wrapper suitable as a first line defense in a defense in depth architecture.

5.5. Limitations

The study has several limitations. The evaluation is conducted in a controlled laboratory environment rather than a production deployment. The dataset is synthetic, the tool set is intentionally small, and the experiment uses simulated MCP requests instead of live LLM agent reasoning. This means the results measure request level enforcement and do not fully capture the behavior of real LLM agents interacting with external context. The prompt injection evaluation measures pattern filtering effectiveness rather than semantic prompt injection resilience. The attack scenarios are based on documented vulnerability classes, but they do not cover every possible adaptive attack technique.

The current implementation also has engineering limitations. Token replay protection and rate limiting use local state, which means that state would not automatically be shared across multiple wrapper instances. Production deployment would require distributed state management, such as a shared cache or database, to support horizontal scaling. The JWT implementation uses a shared secret, which is suitable for a controlled prototype but should be replaced or strengthened in production through centralized identity management, secure key rotation, and mechanisms such as OAuth2 or OpenID Connect. The response inspector and prompt guard rely on patterns and heuristics, which means they may miss novel variants or block benign inputs that resemble attacks.

The internal validity of the experiment is strengthened by the controlled design. Both environments use the same machine, dataset, scripts, and underlying MCP server, and the main variable is the presence of the wrapper. Automated execution reduces human error and ensures that attack scenarios are applied consistently. External validity is more limited because real deployments may involve different MCP servers, larger tool ecosystems, multiple users, variable network latency, live LLM reasoning, and attackers who adapt their strategies over time. Construct validity is also limited because attack success rate and blocking rate do not capture every dimension of security. For example, blocking prompt injection like text is not the same as proving robust semantic prompt injection defense.

5.6. Practical Value of Wrapper Based Hardening

The strongest results were observed in authentication enforcement, JWT abuse prevention, command execution blocking, evasion resistance, response leakage prevention, and rate limit exhaustion mitigation. Authentication and policy enforcement are especially important because they determine whether a caller can reach high risk tools. Input validation is also central because file access and command execution tools can become dangerous if user-provided arguments are not constrained. Response inspection adds a protection layer by preventing sensitive content from being returned. Rate limiting reduces denial of service attack by controlling excessive request patterns before they exhaust server resources. From a practitioner perspective, the results suggest that MCP servers should not expose high risk tools directly without security controls. Authentication should be enforced before tool invocation, and role-based access control should restrict tools according to least privilege. File access should be constrained using sandboxing and canonical path validation. Shell execution should be avoided where possible or strictly controlled when required. Responses should be inspected for secret leakage, rate limiting should be applied to reduce request flooding risks, and audit logging should be enabled for traceability and incident response. A wrapper-based architecture provides a practical way to apply these controls externally, but it should be deployed as part of a broader defense-in-depth strategy.

6. Conclusions

This paper presented a security assessment and lightweight hardening approach for MCP servers. An intentionally insecure MCP server was evaluated using 85 controlled scenarios across nine test suites, and a FastAPI-based wrapper was implemented to enforce authentication, role-based access control, input validation, prompt injection filtering, threat scoring, response inspection, rate limiting, and audit logging. The wrapper reduced attack exposure by 96% across the attack cases used for vulnerability reduction calculation, achieved 100% scenario level mitigation for the tested rate limit exhaustion cases, preserved the legitimate-use validation cases, and introduced low overhead, with an average latency increase of approximately 3 ms and memory overhead of 4.3 MB. The evaluation also revealed three false positives in strict rule-based filtering, showing the need to balance security and usability.

The main conclusion is that a lightweight external wrapper can provide measurable deployment-level hardening for MCP servers without modifying the underlying MCP implementation. This is valuable in practical settings where MCP servers may be externally managed, legacy, or difficult to change. However, the wrapper should be viewed as a complementary defense layer rather than a complete solution for all MCP security risks. Future work should evaluate the wrapper in real LLM-agent workflows, larger MCP ecosystems, and production-like network environments. Further improvements should include distributed state management for rate limiting and replay protection, OAuth2 or OpenID Connect integration, secure key rotation, fuzzing and red-team testing, semantic prompt-injection detection, and broader false-positive evaluation.