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

MCPGate is a gateway, not a data store. We route tool calls and enforce rules — we never store the content of what your AI reads or writes.

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

OAuth Token Security#

MCPGate uses OAuth 2.0 with PKCE for all client authentication. Access tokens are short-lived JWTs and are never stored by MCPGate — they are validated on each request using the public keys published at /oauth/jwks.

  • PKCE enforced — all authorization flows require a code_challenge and code_challenge_method=S256. Authorization codes cannot be exchanged without the matching code verifier, preventing interception attacks.
  • Public clients, no secrets — MCPGate OAuth clients have no client_secret. Security relies on PKCE and short-lived tokens rather than long-lived shared secrets.
  • Short-lived JWTs — access tokens expire quickly, limiting the window of exposure if a token is compromised.
  • Per-app scope — tokens are scoped to a specific MCP App. A token for one app cannot access tools or data belonging to a different app.
  • Standard discovery — OAuth server metadata is published at /.well-known/oauth-authorization-server for interoperability with standard OAuth libraries.

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 security@cdmx.in. We aim to acknowledge all reports within 24 hours and resolve critical issues within 72 hours.