Skip to main content
Use this pattern when you operate an MCP server and want ThornGuard to sit in front of it as a managed security layer. Examples:
  • an internal MCP server shared with your team
  • a vendor-operated remote MCP server exposed to customers
  • an MCP endpoint that needs auditing, approvals, or DLP before client traffic reaches it

​
Current Supported Pattern

Today, ThornGuard protects an existing upstream MCP endpoint by having clients connect to ThornGuard first and identify the real upstream with x-mcp-target-url. 
MCP Client -> ThornGuard -> Your MCP Server
At a high level:
  1. Your MCP server keeps running at its existing upstream URL.
  2. Clients connect to https://thorns.qwady.app/mcp.
  3. Clients authenticate to ThornGuard with a ThornGuard-issued credential.
  4. Clients tell ThornGuard which upstream MCP server to reach through x-mcp-target-url.
  5. ThornGuard enforces auth, policy, rate limits, approvals, redaction, and audit logging before the request reaches your service.

​
What You Get Today

  • a managed security layer in front of an existing MCP service
  • audit visibility for every client request
  • data loss prevention on responses
  • policy controls and approval flows
  • team auth and rate limiting

​
Example Client Configs

​
Direct HTTP Client

{
  "servers": {
    "myProtectedServer": {
      "type": "http",
      "url": "https://thorns.qwady.app/mcp",
      "headers": {
        "x-thornguard-license": "Bearer THORN-YOUR_LICENSE_KEY",
        "x-mcp-target-url": "https://mcp.your-company.com/mcp"
      }
    }
  }
}

​
Claude Desktop via mcp-remote

{
  "mcpServers": {
    "myProtectedServer": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://thorns.qwady.app/mcp",
        "--header",
        "x-thornguard-license: Bearer THORN-YOUR_LICENSE_KEY",
        "--header",
        "x-mcp-target-url: https://mcp.your-company.com/mcp"
      ]
    }
  }
}
  • Use HTTPS-only upstream MCP endpoints
  • Keep your upstream MCP server protected even if ThornGuard sits in front of it
  • Scope ThornGuard credentials per team or environment
  • Rotate upstream credentials and ThornGuard credentials on a schedule
  • Avoid long-lived copied secrets in client configs whenever OAuth or managed secret storage is available
  • Treat audit export destinations and webhook consumers as sensitive systems

​
What Still Needs Product Work

The current flow works, but it is not yet the ideal onboarding experience for MCP service owners. Current gaps:
  • server registration in the dashboard instead of raw x-mcp-target-url
  • stable protected URLs per upstream connection
  • better native support for OAuth-based remote connector platforms
  • first-class storage and rotation for upstream credentials