Security Model
MCPGate is built around a single principle: your credentials and your data should never be accessible to the AI systems you use. This page explains how MCPGate enforces that guarantee at every layer of the stack.
Note
Credential Vault#
OAuth tokens and API keys are stored using envelope encryption with AES-256-GCM. Each user has a unique data encryption key (DEK) that encrypts their credentials. The DEK itself is encrypted by a key encryption key (KEK) held in a separate key provider.
- Encryption algorithm: AES-256-GCM (authenticated encryption — protects both confidentiality and integrity)
- Per-user DEKs:a breach of one user's key does not compromise any other user's credentials
- Swappable key providers: local (development), AWS KMS (production), GCP KMS (available on request)
- At-rest encryption: all stored credentials are encrypted before being written to the database
- In-transit encryption:all connections use TLS 1.3 via Caddy's automatic certificate management
Zero Credential Exposure#
The core security guarantee of MCPGate is that your OAuth tokens and API keys can never reach an AI model, regardless of what prompts it receives:
- Never in API responses — credential values are never returned in any MCPGate API response, even to authenticated requests
- Never in LLM context — MCPGate executes tool calls server-side. The LLM receives the result (e.g., a list of emails), not the credentials used to fetch them
- Never in tool arguments — MCP tools exposed by MCPGate do not accept or return credential parameters; authentication is handled transparently
- Prompt injection resistance— because credentials are never in the AI's context window, a successful prompt injection attack has nothing sensitive to exfiltrate
API Key Security#
MCP App API keys (the keys you paste into Claude Desktop, Cursor, etc.) are handled with the same rigor as passwords:
- Argon2id hashing — keys are hashed with Argon2id before storage. The raw key value is never stored. Comparison is done with a timing-safe function to prevent timing attacks.
- Shown once — the full key is displayed only at creation time. MCPGate cannot show it again. If you lose a key, regenerate it.
mgw_prefix — all MCPGate keys start withmgw_for easy identification in config files and secret scanners- Immediate invalidation — regenerating a key immediately revokes the old one. Any client using the old key will be rejected on the next request.
Infrastructure Security#
MCPGate's backend is hardened at the infrastructure level:
- Docker containers with explicit CPU and memory resource limits; no container runs as root
- Caddy reverse proxywith automatic TLS certificate provisioning and renewal via Let's Encrypt
- SSH hardening — key-only authentication, password login disabled, running on a non-standard port
- UFW firewall — only ports 80, 443, and the SSH port are open; all other ingress is blocked
- PostgreSQL with Row-Level Security — database-level enforcement ensures queries can only access rows belonging to the authenticated user
What MCPGate Does Not Store#
MCPGate is intentionally minimal in what it retains. We store:
- Encrypted OAuth tokens (required to make API calls on your behalf)
- Audit log entries — tool name, arguments the AI sent, guardrail decision, latency, timestamp
- Your account information (email, plan) via Clerk authentication
We do not store:
- Email content, subject lines, or sender information
- Slack message text or channel contents
- File contents from Google Drive, Dropbox, or GitHub
- Any data returned by tool calls — API responses pass through to the AI and are not persisted
Tool call arguments are stored in the audit log (so you can see what parameters the AI sent), but the full response payload is never written to disk.
Security Reporting#
If you discover a security issue, please report it by email to [email protected]. We aim to acknowledge all reports within 24 hours and resolve critical issues within 72 hours.