Enkrypt AI Secure MCP Gateway

# MCP Server-Level Guardrails vs LLM Guardrails: Executive Comparison ## Three Layers of AI Security AI security requires multiple complementary layers. This comparison shows the progression from basic LLM safety to comprehensive MCP tool-level protection: **Layer 1:** Basic LLM Model Safety (no external guardrails) **Layer 2:** LLM Endpoint Security (Enkrypt AI Deployments + Secure AI Proxy) **Layer 3:** MCP Tool Execution Security (Enkrypt Secure MCP Gateway) --- ## Security & Enforcement Capabilities | Capability | Basic LLM Safety Only | **LLM Endpoint Guardrails**<br>(Enkrypt Deployments + Proxy) | **MCP Gateway Guardrails**<br>(Enkrypt MCP Gateway) | Key Advantage | |------------|----------------------|--------------------------------------------------------------|-----------------------------------------------------|---------------| | **Security Model** | Probabilistic (86% bypass rate via prompt injection) | ✓ Real-time detection + blocking at LLM endpoint | ✓✓ **Deterministic enforcement at tool execution point** | MCP: Cannot be bypassed even if LLM compromised | | **Prompt Injection Defense** | ❌ Vulnerable (#1 OWASP risk) | ✓ Detects and blocks at LLM level | ✓✓ **Validates even if LLM was tricked** - blocks malicious tool calls | MCP: Assumes LLM is compromised, validates independently | | **Authentication** | ❌ No cryptographic verification | ✓ API key authentication to proxy endpoint | ✓✓ **Gateway key + per-project authentication** | Both provide auth; MCP adds project-level isolation | | **PII Protection** | ❌ May detect but can be tricked | ✓ Server-side redaction at LLM endpoint | ✓✓ **Second layer of redaction before tool access** | Both provide PII protection at different layers | | **Input Validation** | Probabilistic detection | ✓ Detects threats (injection, toxicity, NSFW) | ✓✓ **MCP parameter validation** (path traversal, schema enforcement) | MCP: Tool-specific validation LLM endpoint cannot provide | | **Tool Execution Control** | ❌ Cannot prevent tool execution | ❌ Cannot control MCP tools | ✓✓ **Blocks actual tool execution** via allowlisting, sandboxing | **MCP ONLY**: Critical gap in LLM-only security | | **Tool Allowlisting** | ❌ No control | ❌ No control | ✓✓ **Per-user/per-project tool permissions** | **MCP ONLY**: Controls which tools each user can access | | **Tool Authorization** | ❌ No control | ❌ No control | ✓✓ **Role-based access to specific MCP servers** | **MCP ONLY**: Fine-grained authorization at tool level | | **Rate Limiting** | ❌ No control | ✓ At LLM endpoint | ✓✓ **Per-tool and per-user quotas at execution layer** | Both provide rate limiting; MCP adds tool-specific limits | | **Monitoring & Audit** | ❌ Limited visibility | ✓ Comprehensive LLM request/response logs | ✓✓ **Full MCP lifecycle**: tool calls, parameters, results | Both provide audit; MCP adds tool execution visibility | | **Policy Enforcement** | ❌ No centralized policies | ✓ Custom policies for LLM inputs/outputs | ✓✓ **Tool-specific policies + execution plan validation** | MCP: Policies for what tools can do, not just what LLM generates | | **Observability** | ❌ Limited | ✓ Detailed logs of all LLM calls | ✓✓ **OpenTelemetry: Jaeger, Loki, Prometheus, Grafana** | Both provide observability; MCP adds distributed tracing | --- ## Deployment & Practical Advantages | Aspect | Basic LLM Only | **LLM Endpoint Guardrails** | **MCP Gateway Guardrails** | Key Advantage | |--------|----------------|----------------------------|----------------------------|---------------| | **Client Flexibility** | Uses default model | Requires custom model config with proxy endpoint | ✓ **Works with native models** (keeps Cursor/Claude defaults) | **MCP ONLY**: No client reconfiguration needed | | **Cost Efficiency** | Subscription cost only | Additional proxy service cost | ✓ **No extra LLM API needed** - secures existing models | **MCP ONLY**: Pay for gateway, keep subscription benefits | | **Locked Client Environments** | ❌ No security options | May not work if client locks model config | ✓ **Only option when clients don't allow custom models** | **MCP ONLY**: Security without client modification | | **Multi-Client Management** | Separate config per client | Proxy works across clients | ✓ **One gateway secures all clients** (Cursor, VS Code, Claude Desktop) | MCP: Centralized management for entire org | | **Scope of Protection** | LLM responses only | LLM endpoint security | ✓ **MCP tool execution security** - protects backend systems | **MCP**: Different attack surface than LLM endpoint | | **Backend Integration** | N/A | N/A | ✓ **No modification to MCP servers** - transparent security layer | **MCP**: Protects legacy/3rd party MCP servers | --- ## What Each Layer Protects Against | Threat | Basic LLM Safety | LLM Endpoint Guardrails | **MCP Gateway Guardrails** | |--------|------------------|------------------------|----------------------------| | **Prompt Injection** | ❌ Vulnerable | ✓ Detects at LLM input | ✓✓ **Blocks tool execution even if LLM compromised** | | **Jailbreaking** | ❌ Vulnerable | ✓ Detects patterns | ✓✓ **Validates tool calls independently** | | **PII Leakage** | ❌ Can leak | ✓ Redacts at LLM level | ✓✓ **Second redaction layer before tools** | | **Tool Poisoning** | N/A | N/A | ✓✓ **Cryptographic signing validates tool integrity** | | **Command Injection** | N/A | N/A | ✓✓ **Parameter sanitization blocks OS command injection** | | **Path Traversal** | N/A | N/A | ✓✓ **Schema validation prevents directory traversal** | | **OAuth Confused Deputy** | N/A | N/A | ✓✓ **Validates OAuth flows for MCP servers** | | **Data Aggregation Risk** | N/A | N/A | ✓✓ **Token isolation per project/user** | | **Unauthorized Tool Access** | N/A | N/A | ✓✓ **Tool allowlisting enforces permissions** | | **Rate Limit Bypass** | ❌ No protection | ✓ At LLM endpoint | ✓✓ **Per-tool quotas prevent abuse** | --- ## Real-World Scenarios Requiring Each Layer ### When LLM Endpoint Guardrails (Enkrypt Deployments) Are Essential: - Need to secure LLM API calls with authentication, PII redaction, and prompt injection detection - Want unified guardrails across multiple LLM providers (OpenAI, Azure, AWS Bedrock) - Require monitoring and audit trails for LLM usage - Need to enforce organizational policies on LLM inputs/outputs - Want to detect hallucinations, ensure adherence, and validate relevancy ### When MCP Gateway Guardrails Are Essential (Additional Requirements): | Scenario | Why MCP Gateway Required | |----------|-------------------------| | **Cursor Subscription Users** | Keep included models (GPT-4, Claude) without adding custom API keys. Use native models + MCP Gateway for tool-level security. | | **Locked Enterprise Clients** | Corporate policies prevent model configuration changes. MCP Gateway is **the only way** to add tool security. | | **Tool Execution Control** | Need to prevent actual tool calls (file deletion, database access, API invocations) - LLM endpoint cannot block these. | | **Per-User Tool Permissions** | Different users need access to different MCP tools. Only MCP Gateway provides tool-level authorization. | | **High-Value Tool Access** | Tools accessing production databases, financial systems, customer data need cryptographic authentication at execution layer. | | **Command Injection Risk** | 43% of MCP servers vulnerable to RCE. Only MCP Gateway validates tool parameters and sanitizes inputs. | | **Tool Poisoning Prevention** | Need cryptographic signing to verify tool descriptions haven't been tampered with. | | **Multi-Project Isolation** | Each project/team needs separate MCP configurations with isolated tool access. | | **Compliance Requirements** | HIPAA, GDPR, SOX demand tamper-proof audit trails of tool execution that LLM logs alone cannot provide. | --- ## The Complete Security Architecture ``` ┌─────────────────────────────────────────────────────┐ │ User Query (potentially malicious) │ └────────────────────┬────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────┐ │ Layer 1: Basic LLM Safety (Built-in) │ │ • Model alignment training │ │ • Refusal training │ │ ⚠️ Bypassable via prompt injection │ └────────────────────┬────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────┐ │ Layer 2: LLM Endpoint Guardrails ✓ │ │ (Enkrypt AI Deployments + Secure AI Proxy) │ │ • Authentication & rate limiting │ │ • Prompt injection detection │ │ • PII redaction at LLM level │ │ • Policy enforcement for LLM I/O │ │ • Monitoring & audit logs │ └────────────────────┬────────────────────────────────┘ │ ▼ LLM decides tool + parameters │ ┌─────────────────────────────────────────────────────┐ │ Layer 3: MCP Gateway Guardrails ✓✓ │ │ (Enkrypt Secure MCP Gateway) │ │ • Gateway authentication (project-level) │ │ • Tool allowlisting (per-user authorization) │ │ • Parameter validation (command injection blocking) │ │ • Second PII redaction layer │ │ • Tool execution control (blocks malicious calls) │ │ • Cryptographic tool signing │ │ • Per-tool rate limiting │ │ ✓ Blocks execution even if LLM compromised │ └────────────────────┬────────────────────────────────┘ │ ▼ Only if all validation passes │ ┌─────────────────────────────────────────────────────┐ │ MCP Server → Tool Execution │ │ (Protected by both LLM and MCP layers) │ └─────────────────────────────────────────────────────┘ ``` --- ## Key Takeaways ### ✓ LLM Endpoint Guardrails (Enkrypt Deployments) Provide: - **Detection and prevention** at the LLM API level - Authentication, PII redaction, prompt injection detection - Monitoring and policy enforcement for LLM inputs/outputs - Protection against LLM-specific threats (hallucination, toxicity, bias) - **Essential first layer** of defense ### ✓✓ MCP Gateway Guardrails (Enkrypt MCP Gateway) Add: - **Enforcement at the tool execution point** - blocks malicious actions - Tool-level authorization and allowlisting per user/project - Parameter validation preventing command injection, path traversal - Tool integrity verification through cryptographic signing - Protection against MCP-specific threats (tool poisoning, OAuth bypass) - **The only security layer that can actually prevent tools from executing** ### Bottom Line: **Both layers are essential and complementary:** - **LLM Endpoint Guardrails** secure what the LLM generates and processes - **MCP Gateway Guardrails** secure what tools actually execute - You need **both** because they protect different attack surfaces - **LLM guardrails detect threats; MCP guardrails enforce prevention** **In locked/subscription environments (Cursor with included models):** - Cannot add custom LLM endpoints → LLM endpoint guardrails may not be an option - **MCP Gateway becomes the ONLY way to add security without losing subscription benefits** - Works transparently with native models while adding comprehensive tool-level protection **Research shows:** 86% of LLM apps compromised despite guardrails, 43% of MCP servers vulnerable to RCE. Defense-in-depth with both layers is not optional—it's mandatory for production security.