Skip to main content

Documentation Index

Fetch the complete documentation index at: https://qwady.wiki/llms.txt

Use this file to discover all available pages before exploring further.

ThornGuard is Qwady’s edge security gateway for the Model Context Protocol. It sits between AI clients and the MCP servers they use or operate, inspects every request, redacts sensitive data in both directions, and keeps a structured audit trail of what happened. The current product now has three visible layers:
  • a secure local launcher path through the ThornGuard CLI
  • the edge gateway on thorns.qwady.app
  • the dashboard and management surface on thorns.qwady.io
The public routing model is intentionally split:
  • https://thorns.qwady.app is the public landing page plus MCP/API host.
  • https://thorns.qwady.io is the live dashboard.
  • https://qwady.wiki/thornguard/* is the documentation source you are reading now.

​
Why It Exists

MCP makes AI clients dramatically more capable, but it also expands the blast radius of bad prompts, prompt injection, compromised upstream tools, and accidental data leakage. Without a gateway, an AI client can be tricked into:
  1. Sending destructive tool payloads or shell-like commands upstream.
  2. Exfiltrating secrets, PII, and credentials back into model context.
  3. Probing internal services or metadata endpoints through user-controlled target URLs.
  4. Overusing upstream tools through loops or runaway agent behavior.

​
What ThornGuard Does

Transport Hardening

Validates HTTPS targets, enforces Origin checks when enabled, and performs DNS-aware SSRF protection before proxying traffic upstream.

Ingress Blocking

Validates JSON-RPC structure, blocks malicious command signatures, honors tenant blocklists, and supports structured policy rules.

Egress PII Redaction

Redacts built-in PII and secret patterns from JSON and SSE responses, and can layer enterprise custom redaction rules on top.

Audit and Correlation

Writes structured audit logs with public log_id, trace_id, optional policy metadata, and response correlation headers.

Access Control

Supports Polar license keys, per-client license activations, and additive OAuth/JWT interoperability for HTTP clients when enabled.

Secure Local Launch

Generates stable MCP launcher configs so users do not need to paste raw bearer values into visible client arguments.

Platform Controls

Adds policy rules, webhook integrations, tool inventory, approval flows, and custom redaction rules as the platform matures.

Warn-First Advisories

Opt-in connection intelligence can surface availability, dependency, and vendor risk signal without auto-blocking on outside data in v1.

​
Deployment Modes

ThornGuard supports two common deployment patterns today:
  • Protect an AI client by routing a developer’s MCP client through ThornGuard before it reaches third-party or internal MCP servers.
  • Protect your own MCP server by putting ThornGuard in front of an MCP endpoint you operate so every client reaches your service through ThornGuard first.
Both modes use the same proxy and security pipeline. The difference is who controls the upstream service and how clients are onboarded.

​
Current Product Surface

Today, ThornGuard ships in three layers:
  • The public landing page plus gateway and management API on thorns.qwady.app, which owns marketing, proxying, auth, audits, policy rules, integrations, approvals, tool inventory, connection metadata, advisories, and redaction rules.
  • The local CLI launcher (thornguard), which stores profile metadata locally, keeps secrets out of visible client config, launches protected MCP bridges, and prints client-specific setup snippets.
  • The dashboard UI on thorns.qwady.io, which exposes login, telemetry, audit logs, settings, platform controls, and license activation management.
Some dashboard sections are feature-flagged and permission-gated. The Platform tab surfaces policies, outbound integrations (webhook, Slack, Teams, Datadog, Splunk HEC, S3), tool inventory, approvals, and custom redaction rules when those backend features are enabled for the current environment and session. License-key logins are owner-scoped; narrower roles only appear in deployments that layer SSO or JWT-based auth on top.

​
Edge Architecture

ThornGuard runs on Cloudflare’s edge stack:
  • Workers handle routing, proxying, auth, redaction, and SSE processing.
  • D1 stores audit logs, tenant settings, policies, integrations, tools, approvals, and redaction rules.
  • KV caches license validation, settings, DNS lookups, and approval/client capability hints.
  • Durable Objects provide the primary per-license rate limiter.
  • Queues deliver outbound webhook events asynchronously.
For bearer header mode (the default CLI and mcp-remote flow), ThornGuard does not store upstream bearer secrets server-side. Those remain local to the CLI or client machine, while server-side connection records stay non-secret and advisory-focused. When OAuth proxy mode is enabled (Phase 3), ThornGuard stores upstream OAuth tokens encrypted with AES-256-GCM in D1 via the oauth-crypto module. See Vault Architecture for the encryption design and planned migration to dedicated secret storage.

​
Where To Go Next