{/* FEATURED IMAGE PLACEHOLDER: Hero image for resource exhaustion article - AI Prompt: "Create a high-quality featured image for an article about resource exhaustion in AI systems. Style: Modern technical illustration using Garnet brand colors: deep garnet red (#C32131), rich navy blue (#0A1A4C), and dark background (#111111). Show computing resources being overwhelmed by excessive requests with visual metaphors for system strain such as overheating elements or resource meters at maximum. Create a professional, visually striking design that would attract technical readers. No text elements or diagram components." */} # MCP Security Top 10 - Part 7: Resource Exhaustion This is the seventh article in our series about the top 10 security risks associated with the Model Context Protocol (MCP). This post focuses on **Resource Exhaustion**, which occurs when MCP servers or client systems are driven to consume excessive computational resources, potentially leading to performance degradation, denial of service, or excessive costs. ## Introduction Resource exhaustion is a class of attack where systems are forced to consume computational resources (CPU, memory, disk space, network bandwidth) beyond their capacity or intended allocation. In MCP contexts, these attacks can be particularly impactful because: 1. AI systems often trigger complex, resource-intensive operations 2. MCP tools might lack proper resource constraints 3. AI-driven automation can amplify resource consumption through recursive or repeated operations 4. Cloud-based systems might incur significant costs from excessive resource usage While traditional security concerns often focus on unauthorized access or data breaches, resource exhaustion attacks target availability and can lead to significant operational disruptions or unexpected costs. ## MCP Security Top 10 Series This article is part of a comprehensive series examining the top 10 security risks when using MCP with AI agents: 0. [MCP Security Top 10 Series: Introduction & Index](/blog/mcp-security-top-10-series-introduction) 1. [MCP Overview](/blog/mcp-security-overview) 2. [Over-Privileged Access](/blog/mcp-security-over-privileged-access) 3. [Prompt Injection Attacks](/blog/mcp-security-prompt-injection) 4. [Malicious MCP Servers](/blog/mcp-security-malicious-mcp-servers) 5. [Unvalidated Tool Responses](/blog/mcp-security-unvalidated-tool-responses) 6. [Command Injection](/blog/mcp-security-command-injection) 7. [Resource Exhaustion](/blog/mcp-security-resource-exhaustion) (this article) 8. [Cross-Context Data Leakage](/blog/mcp-security-cross-context-data-leakage) 9. [MITM Attacks](/blog/mcp-security-mitm-attacks) 10. [Social Engineering](/blog/mcp-security-social-engineering) 11. [Overreliance on AI](/blog/mcp-security-overreliance-on-ai) ## What is Resource Exhaustion in MCP? Resource exhaustion in MCP contexts occurs when: 1. An MCP server or client is driven to consume excessive resources 2. The consumption affects system stability, performance, or availability 3. Normal operations are disrupted or costs increase significantly 4. The exhaustion might be triggered intentionally or as a side effect of poorly designed tools Unlike some security vulnerabilities that are binary (either exploitable or not), resource exhaustion issues often manifest gradually as systems scale, making them particularly challenging to detect during testing. ## Types of Resource Exhaustion in MCP ### 1. Computational Exhaustion When MCP tools perform excessive CPU-intensive operations: ```typescript // VULNERABLE: Unbounded computational complexity import { MCPServer, createTool } from 'mcp-sdk-ts'; const computeFactorialTool = createTool({ name: "compute_factorial", description: "Compute the factorial of a number", inputSchema: { type: "object", properties: { number: { type: "number" } }, required: ["number"] }, handler: async ({ number }) => { // VULNERABLE: No bounds checking on input size if (typeof number !== 'number') { throw new Error('Input must be a number'); } // Recursive factorial function with no upper limit function factorial(n) { if (n <= 1) return 1; return n * factorial(n - 1); } // This will cause stack overflow or excessive CPU usage for large inputs const result = factorial(number); return { result }; } }); ``` ### 2. Memory Exhaustion When MCP tools consume excessive memory: ```typescript // VULNERABLE: Unbounded memory allocation import { MCPServer, createTool } from 'mcp-sdk-ts'; import * as fs from 'fs'; const readAndProcessFileTool = createTool({ name: "read_and_process_file", description: "Read and process a file", inputSchema: { type: "object", properties: { filePath: { type: "string" } }, required: ["filePath"] }, handler: async ({ filePath }) => { // VULNERABLE: No file size checks or streaming const fileContent = fs.readFileSync(filePath, 'utf8'); // Store the entire file in memory const lines = fileContent.split('\n'); // Process each line (potentially with large files) const processedLines = lines.map(line => { // Some processing logic return line.toUpperCase(); }); return { lineCount: lines.length, processedContent: processedLines.join('\n') }; } }); ``` ### 3. Recursive Exhaustion When MCP tools call themselves or other tools recursively without proper limits: ```typescript // VULNERABLE: Unbounded recursion import { MCPServer, createTool } from 'mcp-sdk-ts'; let traverseDirectoryTool; const processFileTool = createTool({ name: "process_file", description: "Process a file", inputSchema: { type: "object", properties: { filePath: { type: "string" } }, required: ["filePath"] }, handler: async ({ filePath }) => { // Some file processing logic return { processed: true }; } }); traverseDirectoryTool = createTool({ name: "traverse_directory", description: "Process all files in a directory recursively", inputSchema: { type: "object", properties: { directoryPath: { type: "string" } }, required: ["directoryPath"] }, handler: async ({ directoryPath }, context) => { const { fs } = require('fs/promises'); const { join } = require('path'); // VULNERABLE: No recursion depth limit const entries = await fs.readdir(directoryPath, { withFileTypes: true }); for (const entry of entries) { const entryPath = join(directoryPath, entry.name); if (entry.isDirectory()) { // Recursive call without depth tracking await context.invokeTool("traverse_directory", { directoryPath: entryPath }); } else { await context.invokeTool("process_file", { filePath: entryPath }); } } return { processed: true }; } }); ``` {/* IMAGE PLACEHOLDER: Visual showing resource monitoring and limits - AI Prompt: "Create a conceptual illustration depicting resource monitoring and limitation in computing systems. Style: Clean, technical aesthetic with visual clarity. Show a visualization of computing resources (CPU, memory, storage represented by different colored glowing elements) with clear boundaries/containment structures around them (representing resource limits). Include visual meters or gauges showing resource utilization levels. Use a dark background with blue and purple elements that create a modern tech feel. Include subtle visual elements representing automated scaling or throttling mechanisms. No text labels or diagram elements. The image should communicate the concept of monitored and controlled resource usage in technical systems." */} Conceptual illustration of resource monitoring and limitation showing bounded computing resources with utilization meters

Conceptual illustration of resource monitoring and limitation showing bounded computing resources with utilization meters

## Real-World Impact Resource exhaustion attacks can have several severe consequences: 1. **Denial of Service**: Systems become unresponsive or crash 2. **Excessive Costs**: Cloud-based systems incur unexpected charges 3. **Performance Degradation**: Services slow down, affecting user experience 4. **Resource Contention**: Other critical systems are affected by resource starvation 5. **Battery Drain**: Mobile or IoT devices experience rapid power depletion ## Detection Methods ### 1. Resource Monitoring Implement comprehensive monitoring of resource usage: - Track CPU, memory, disk, and network utilization - Set baseline expectations for normal operations - Configure alerts for sudden increases or anomalies - Monitor resource usage patterns by tool and operation ### 2. Static Analysis Use code analysis to identify potential resource issues: - Look for unbounded loops or recursion - Identify missing resource limits or timeouts - Detect algorithms with potentially exponential complexity - Check for proper error handling that releases resources ### 3. Load Testing Perform specific testing for resource boundaries: - Test with edge case inputs (very large, complex, or nested) - Simulate high concurrency scenarios - Gradually increase load to identify breaking points - Test resource release during error conditions ## Mitigation Strategies ### 1. Implement Resource Limits Add explicit constraints on resource usage: ```typescript // IMPROVED: With proper resource limits import { MCPServer, createTool } from 'mcp-sdk-ts'; const MAX_FACTORIAL = 1000; // Set a reasonable upper limit const computeFactorialTool = createTool({ name: "compute_factorial", description: "Compute the factorial of a number (up to ${MAX_FACTORIAL})", inputSchema: { type: "object", properties: { number: { type: "number", maximum: MAX_FACTORIAL } }, required: ["number"] }, handler: async ({ number }) => { // Validate input is within acceptable range if (typeof number !== 'number' || number < 0) { throw new Error('Input must be a non-negative number'); } if (number > MAX_FACTORIAL) { throw new Error(`Input exceeds maximum allowed value (${MAX_FACTORIAL})`); } // Use an iterative approach instead of recursion for better performance let result = 1; for (let i = 2; i <= number; i++) { result *= i; // Additional check for numeric overflow if (!isFinite(result)) { throw new Error('Result too large to represent'); } } return { result }; } }); ``` ### 2. Use Streaming for Large Data Process large data incrementally rather than loading it entirely in memory: ```typescript // IMPROVED: Using streams for large files import { MCPServer, createTool } from 'mcp-sdk-ts'; import * as fs from 'fs'; import { createReadStream } from 'fs'; import { createInterface } from 'readline'; const MAX_FILE_SIZE = 100 * 1024 * 1024; // 100MB limit const readAndProcessFileTool = createTool({ name: "read_and_process_file", description: "Read and process a file (streaming large files)", inputSchema: { type: "object", properties: { filePath: { type: "string" } }, required: ["filePath"] }, handler: async ({ filePath }) => { // Check file exists and size is reasonable const stats = await fs.promises.stat(filePath); if (stats.size > MAX_FILE_SIZE) { throw new Error(`File too large: ${stats.size} bytes exceeds limit of ${MAX_FILE_SIZE} bytes`); } // Use streams for efficient processing const lineCount = await new Promise((resolve, reject) => { let count = 0; let sampleLines = []; const readStream = createReadStream(filePath, { encoding: 'utf8' }); const lineReader = createInterface({ input: readStream }); lineReader.on('line', (line) => { count++; // Store just a sample of processed lines (not the entire file) if (count <= 10) { sampleLines.push(line.toUpperCase()); } }); lineReader.on('close', () => { resolve({ count, sampleLines }); }); lineReader.on('error', (err) => { reject(err); }); // Set a timeout for the entire operation setTimeout(() => { readStream.destroy(); reject(new Error('Processing timeout exceeded')); }, 30000); // 30 second timeout }); return { lineCount: lineCount.count, processedSample: lineCount.sampleLines.join('\n') }; } }); ``` ### 3. Implement Recursion Controls Add explicit limits on recursion depth: ```typescript // IMPROVED: With recursion depth limits import { MCPServer, createTool } from 'mcp-sdk-ts'; import * as fs from 'fs/promises'; import { join } from 'path'; const MAX_RECURSION_DEPTH = 5; const MAX_FILES_PROCESSED = 1000; let traverseDirectoryTool; let processedFileCount = 0; const processFileTool = createTool({ name: "process_file", description: "Process a file", inputSchema: { type: "object", properties: { filePath: { type: "string" } }, required: ["filePath"] }, handler: async ({ filePath }) => { processedFileCount++; if (processedFileCount > MAX_FILES_PROCESSED) { throw new Error(`Maximum file processing limit reached (${MAX_FILES_PROCESSED})`); } // Some file processing logic return { processed: true }; } }); traverseDirectoryTool = createTool({ name: "traverse_directory", description: `Process files in a directory (max depth: ${MAX_RECURSION_DEPTH})`, inputSchema: { type: "object", properties: { directoryPath: { type: "string" }, currentDepth: { type: "number", default: 0 } }, required: ["directoryPath"] }, handler: async ({ directoryPath, currentDepth = 0 }, context) => { // Check recursion depth if (currentDepth >= MAX_RECURSION_DEPTH) { return { processed: true, limitReached: true, message: `Maximum recursion depth (${MAX_RECURSION_DEPTH}) reached` }; } // Reset file counter if this is the top-level call if (currentDepth === 0) { processedFileCount = 0; } try { const entries = await fs.readdir(directoryPath, { withFileTypes: true }); for (const entry of entries) { if (processedFileCount > MAX_FILES_PROCESSED) { return { processed: true, limitReached: true, message: `Maximum file limit (${MAX_FILES_PROCESSED}) reached` }; } const entryPath = join(directoryPath, entry.name); if (entry.isDirectory()) { // Pass the incremented depth to track recursion await context.invokeTool("traverse_directory", { directoryPath: entryPath, currentDepth: currentDepth + 1 }); } else { await context.invokeTool("process_file", { filePath: entryPath }); } } return { processed: true, filesProcessed: processedFileCount }; } catch (error) { return { processed: false, error: error.message }; } } }); ``` ### 4. Implement Timeouts Add timeouts for long-running operations: ```typescript // IMPROVED: With operation timeouts import { MCPServer, createTool } from 'mcp-sdk-ts'; const DEFAULT_TIMEOUT = 5000; // 5 seconds const executeComplexOperationTool = createTool({ name: "execute_complex_operation", description: "Execute a potentially long-running operation", inputSchema: { type: "object", properties: { operationType: { type: "string" }, parameters: { type: "object" }, timeout: { type: "number", default: DEFAULT_TIMEOUT } }, required: ["operationType", "parameters"] }, handler: async ({ operationType, parameters, timeout = DEFAULT_TIMEOUT }) => { // Enforce reasonable timeout limits const actualTimeout = Math.min(Math.max(timeout, 1000), 30000); // Between 1-30 seconds try { // Create a promise that rejects after the timeout const timeoutPromise = new Promise((_, reject) => { setTimeout(() => { reject(new Error(`Operation timed out after ${actualTimeout}ms`)); }, actualTimeout); }); // The actual operation const operationPromise = new Promise(async (resolve) => { // Complex operation implementation // ... // Simulate a complex operation setTimeout(() => { resolve({ result: "Operation completed successfully" }); }, Math.random() * 10000); // Random time up to 10 seconds }); // Race the operation against the timeout return await Promise.race([operationPromise, timeoutPromise]); } catch (error) { return { success: false, error: error.message }; } } }); ``` ### 5. Rate Limiting and Throttling Implement rate limits to prevent excessive tool usage: ```typescript // IMPROVED: With rate limiting import { MCPServer, createTool } from 'mcp-sdk-ts'; // Simple rate limiter implementation class RateLimiter { constructor(maxRequests, timeWindowMs) { this.maxRequests = maxRequests; this.timeWindowMs = timeWindowMs; this.requestTimestamps = []; } async acquirePermission() { const now = Date.now(); // Remove expired timestamps this.requestTimestamps = this.requestTimestamps.filter( timestamp => now - timestamp < this.timeWindowMs ); // Check if we're under the limit if (this.requestTimestamps.length < this.maxRequests) { this.requestTimestamps.push(now); return true; } // We're at the limit, calculate wait time const oldestTimestamp = this.requestTimestamps[0]; const waitTime = this.timeWindowMs - (now - oldestTimestamp); return new Promise(resolve => { setTimeout(() => { this.requestTimestamps.shift(); this.requestTimestamps.push(Date.now()); resolve(true); }, waitTime); }); } } // Create rate limiters for different tools const fileAccessLimiter = new RateLimiter(10, 60000); // 10 requests per minute const apiRequestLimiter = new RateLimiter(5, 10000); // 5 requests per 10 seconds const readFileTool = createTool({ name: "read_file", description: "Read a file with rate limiting", inputSchema: { type: "object", properties: { filePath: { type: "string" } }, required: ["filePath"] }, handler: async ({ filePath }) => { // Apply rate limiting await fileAccessLimiter.acquirePermission(); // Now proceed with the actual operation try { const fs = require('fs/promises'); const content = await fs.readFile(filePath, 'utf8'); return { content }; } catch (error) { throw new Error(`Failed to read file: ${error.message}`); } } }); ``` Rate limiting is particularly important for MCP servers that might be shared across multiple users or AI instances. Without proper rate limits, one user's actions could impact others. ## Design Patterns for Resource-Efficient MCP When developing MCP tools, consider these design patterns: 1. **Progressive Processing**: Start with minimal resources and scale up only when necessary 2. **Circuit Breaker Pattern**: Automatically disable functions that repeatedly cause resource issues 3. **Bulkhead Pattern**: Isolate components so failures in one don't affect others 4. **Backpressure Mechanisms**: Signal when systems are approaching capacity limits 5. **Resource Pooling**: Share and reuse expensive resources rather than creating them on demand ## Conclusion Resource exhaustion vulnerabilities in MCP implementations can lead to system instability, denial of service, or unexpected costs. By implementing proper resource limits, using streaming for large data, controlling recursion, adding timeouts, and applying rate limiting, you can significantly reduce the risk of these issues. Remember that resource constraints should be considered from the earliest stages of design, as they're often difficult to retrofit into existing systems. Always consider the "worst case" scenarios when planning resource usage, and design with scalability and resilience in mind. In the next article in this series, we'll explore the risks of cross-context data leakage in MCP implementations and strategies for protecting sensitive information. ## Prevent Resource Exhaustion with Garnet As we've explored in this article, resource exhaustion in MCP implementations can lead to system instability, performance degradation, and unexpected costs. Traditional security measures often focus on unauthorized access rather than resource availability. Garnet provides specialized runtime security monitoring designed to detect and prevent resource abuse in AI-powered systems. Unlike simple resource monitors, Garnet's approach focuses on identifying suspicious behavioral patterns that might indicate resource-based attacks. With Garnet's Linux-based Jibril sensor, you can protect your environments against resource exhaustion: - **Process Resource Monitoring**: Track CPU, memory, and I/O usage by MCP servers - **Abnormal Behavior Detection**: Identify unusual resource consumption patterns - **Recursive Call Analysis**: Detect potentially harmful recursive patterns - **Runtime Intervention**: Automatically terminate processes exceeding resource thresholds The Garnet Platform provides centralized visibility into resource usage patterns, with real-time alerts that integrate with your existing security and operations workflows. Learn more about securing your AI-powered development environments against resource exhaustion at [Garnet.ai](https://www.garnet.ai).

Garnet Blog

MCP Security Top 10 Series: Introduction & Index