Skip to main content
ThornGuard is built on a Zero-Trust model. It treats the AI client, the target MCP server, and any user-controlled routing inputs as potentially hostile until proven otherwise.

​
Security Pipeline

Every request passes through these checks in order. A failure at any step immediately terminates the request and logs the action.
StepCheckAction on Failure
1Transport GuardrailsReject non-HTTPS targets (BLOCKED_INSECURE_TARGET)
2Origin ValidationReject disallowed browser origins when enabled (BLOCKED_ORIGIN)
3DNS-Aware SSRF CheckReject private, metadata, or non-resolvable targets (BLOCKED_SSRF)
4AuthenticationValidate license key, team token, or OAuth bearer token (BLOCKED_AUTH)
5IP WhitelistEnterprise per-license IP restrictions (BLOCKED_IP_WHITELIST)
6Rate LimitingEnforce per-license limits (BLOCKED_RATE_LIMIT)
7Structured Policy RulesAudit or block matching request policy rules (POLICY_AUDIT, BLOCKED_POLICY)
8Built-in BlocklistsReject blocked domains or malicious/custom command matches (BLOCKED_CUSTOM_*, BLOCKED_MALICIOUS)
9Approval ChecksRequire approval for matched high-risk tool calls (BLOCKED_APPROVAL)
10PII Redaction (Outbound)Scrub sensitive request data (PII_REDACTED, CUSTOM_REDACTION_AUDIT)
11Proxy to UpstreamForward to target MCP server
12PII Redaction (Inbound)Scrub JSON and SSE response data (PII_REDACTED, CUSTOM_REDACTION_AUDIT)
13Audit and CorrelationEmit structured D1 logs plus correlation headers
Built-in transport, auth, SSRF, and malicious-signature checks are never overridable. Customer policy rules are layered on top of those controls, not instead of them.

​
Ingress Protection (Command Filtering)

When an AI assistant uses an MCP tool, the request arrives as a JSON-RPC 2.0 payload over HTTP. ThornGuard validates that payload before it ever reaches the upstream tool. Core ingress checks include:
  1. Schema Validation: Uses Zod to ensure the payload is perfectly formatted JSON-RPC. Malformed requests are dropped immediately.
  2. Structured Policy Evaluation: Optional tenant rules can inspect RPC method, target domain, client IP CIDR, selected headers, JSON paths, content patterns, tool names, and risk level.
  3. Signature Scanning: The payload is stringified and scanned against built-in malicious command signatures.
  4. Tenant Blocklists: Enterprise settings can block specific domains or substring command patterns.

​
Blocked Signatures

Currently, ThornGuard automatically drops any payload containing the following patterns:
  • rm -rf (Recursive forced deletion)
  • sudo (Privilege escalation)
  • nc -e (Netcat reverse shell)
  • /etc/passwd (System credential access)
  • eval( (Code execution evaluation)
  • chmod 777 (Unrestricted file permissions)
If a built-in signature is matched, ThornGuard returns 400 Bad Request with "ThornGuard Security: Malicious command detected." and records a BLOCKED_MALICIOUS audit entry.

​
Egress DLP (Data Loss Prevention)

If an AI tool successfully executes, the upstream server returns data. Often, this data contains PII (Personally Identifiable Information) or system credentials that should never be fed into a third-party LLM’s context window.

​
The SSE Streaming Challenge

Modern MCP servers use Server-Sent Events (SSE) to stream data back to the client. This means data arrives in fragmented, unpredictable network chunks. Standard regex fails on streams because a secret (like an SSN) might be split in half across two network packets (e.g., 000-00- and 0000).

​
Buffered SSE Redaction

ThornGuard implements an advanced TransformStream buffer:
  1. It holds incoming network packets in memory until it detects a complete SSE event boundary (\n\n).
  2. It parses complete data: events as JSON when possible.
  3. It rewrites upstream origin references back to ThornGuard’s public origin.
  4. It redacts built-in PII and can apply enterprise custom regex rules.
  5. It streams the scrubbed event back to the client without buffering the full response.

​
Supported Redactions

ThornGuard actively scrubs the following patterns from both outbound request params and inbound server responses:
PatternReplacement TagDetails
Email addresses[THORNGUARD REDACTED EMAIL]Standard email format detection
Social Security Numbers[THORNGUARD REDACTED SSN]XXX-XX-XXXX format
Phone numbers[THORNGUARD REDACTED PHONE]Requires separators (e.g., 555-123-4567) to avoid false positives on numeric IDs
Credit cards[THORNGUARD REDACTED CC]IIN prefix validation (Visa, Mastercard, Amex, Discover, JCB, UnionPay, Diners Club) + Luhn checksum — not naive digit matching
AWS Access Keys[THORNGUARD REDACTED AWS_KEY]Detects AKIA and ASIA prefixed keys
GCP API Keys[THORNGUARD REDACTED GCP_KEY]Google Cloud credential patterns
GitHub Tokens[THORNGUARD REDACTED GITHUB_TOKEN]ghp_, gho_, ghs_, ghr_ prefixed tokens
Slack Tokens[THORNGUARD REDACTED SLACK_TOKEN]xoxb-, xoxp-, xoxs- prefixed tokens
Private Keys[THORNGUARD REDACTED PRIVATE_KEY]-----BEGIN ... PRIVATE KEY----- blocks
JWTs[THORNGUARD REDACTED JWT]eyJ... three-segment Base64 tokens

​
Custom Redaction Rules

Enterprise redaction packs can add tenant-owned regex rules in one of two modes:
  • audit records a match but leaves the content intact.
  • redact replaces matches with a configured replacement string.
Built-in PII redaction is always enabled and cannot be disabled by custom rules. Custom rules layer on top of the built-in redactors.

​
SSRF Prevention

Because clients control x-mcp-target-url, ThornGuard treats that value as untrusted input. The gateway blocks:
  • Literal loopback, RFC1918, link-local, metadata, and other private IP targets.
  • Private-looking hostnames such as .internal, .local, and .localhost.
  • Public hostnames that resolve to private or metadata addresses through DNS.
  • Targets that fail DNS resolution entirely when DNS-aware SSRF enforcement is enabled.
ThornGuard resolves hostnames through DNS-over-HTTPS, follows CNAME chains to a bounded depth, and fails closed if it cannot prove the target is safe.

​
Origin Validation

For browser-based or HTTP clients that send an Origin header, ThornGuard can enforce an allowlist of approved origins. This is primarily useful when exposing Streamable HTTP MCP traffic to web-based clients. Allowed origins normally include:
  • The public proxy origin making the request.
  • The live dashboard origin on https://thorns.qwady.io.
  • Any additional origins explicitly configured by deployment.

​
Correlation Headers

Every ThornGuard-generated error response and successful proxied response includes:
  • x-thornguard-log-id
  • x-thornguard-trace-id
Use these headers to connect client-visible failures back to the Audit Logs and any webhook deliveries.