MCP Guard
Get an API keyGet a key
Hosted in SwitzerlandChecks run on our GPUs in Switzerland. Request payloads are not stored.
ProductTry it liveQuickstartMCP serverPricingStatusAPI reference
LearnExplainersUse casesGlossaryCompareSecurity
ResourcesDocsFAQBlogBrand
Pricing
Log in

Trust & security

Security at MCP Guard: what we keep, and what we don’t

The short version: we don’t store the tool calls you send, we can’t read your keys, inference servers are not reachable from the internet directly, and the guard reduces risk but does not guarantee safety.

Where it is hostedReport a vulnerability

Last updated September 25, 2026

In one glance

Four promises, in plain words

  • Payloads are not stored

    The action, intent, context and conversation you send are held in memory only while the check runs. We keep request metadata (ids, verdict, latency, credits) for 30 days.

  • We can’t read your keys

    Keys are shown once at creation. We store only a SHA-256 hash and a short display prefix.

  • GPUs are not on the open internet

    Inference servers accept requests only from our gateway, authenticated with a shared secret.

  • No card data here

    Payments are handled by Stripe; card data never touches our systems.

API keys

The life of an API key

From the moment you create a key to the moment you revoke it, nobody at MCP Guard can read it.

  1. 1

    Created

    You see the full key exactly once, at creation.

  2. 2

    Hashed

    We keep only its SHA-256 hash and a short display prefix.

  3. 3

    Scoped

    Each key belongs to one workspace, always derived from the key, never from the request body.

  4. 4

    Revoked

    Revocation takes effect within 30 seconds across the edge.

Try typing anything. Hashing happens in your browser; nothing is sent.

SHA-256

What our database stores

…

A hash only goes one way: we can check a key you send, but we cannot turn the hash back into your key.

Infrastructure

Layers between the internet and your data

Each layer only talks to the one next to it.

  1. Layer 1

    TLS on every hop

    All traffic is TLS-encrypted.

  2. Layer 2

    Cloudflare edge gateway

    The public API terminates on Cloudflare’s edge, which forwards requests encrypted and does not store their content.

  3. Layer 3

    Isolated GPU servers

    GPU inference servers accept requests only from our gateway, authenticated with a shared secret over Cloudflare Tunnel or the cloud provider’s authenticated endpoint.

  4. Layer 4

    Row-level security

    Dashboard data is protected by Postgres row-level security; privileged operations run server-side only.

Payments are handled by Stripe; card data never touches our systems.

Hosting

Where each part runs

Three providers, each with one job.

  • Inference in Switzerland

    Checks run on our own GPUs in Switzerland.

  • Edge on Cloudflare

    The public API and the website run on Cloudflare’s edge network, which forwards requests to the GPUs over TLS.

  • Account data in Zurich

    Users, workspaces, API key hashes, usage metadata and billing records live in Supabase, EU region (Zurich).

More on hosting

Limits

What the guard does not promise

MCP Guard reduces the risk of an agent running a harmful tool call. It does not guarantee safety.

  • It is a model: it will miss some unsafe calls and flag some safe ones. Scores are probabilities, not proofs.
  • It judges only what you send. Missing or misleading intent and context lead to weaker answers.
  • It is one layer. Keep deterministic rules for known-bad patterns, least-privilege credentials and human approval for irreversible actions.
  • We hold no SOC 2 or ISO 27001 certification today, and self-serve plans carry no uptime SLA.

Responsible disclosure

Reporting a vulnerability

Email support@mcp-guard.ai with the details and steps to reproduce. Please do not test against other customers’ data.

Email the security team

See also our privacy policy and subprocessors.