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 exposes its MCP proxy and management API from https://thorns.qwady.app.

​
Hosts

  • https://thorns.qwady.app/mcp — public MCP proxy endpoint
  • https://thorns.qwady.app/mcp/:connection-id — managed MCP proxy endpoint for a saved protected connection
  • https://thorns.qwady.app/api/* — management and telemetry API
  • https://thorns.qwady.io — live dashboard

​
Default Authentication

The default auth path remains:
  • License keys: THORN-...
For MCP traffic, pass the credential in:
  • x-thornguard-license: Bearer THORN-...
  • x-thornguard-activation-id: <activation-id>
  • x-thornguard-activation-proof: <activation-proof>
  • x-thornguard-session-id: <runtime-session-id>
For dashboard/API traffic, the current UI uses:
  • Authorization: Bearer THORN-...
  • x-thornguard-activation-id: <activation-id>
  • x-thornguard-activation-proof: <activation-proof>

​
Current Public Routing Model

For MCP traffic, the preferred public setup path is now the managed connection route:
  • x-thornguard-license authenticates the request to ThornGuard
  • x-thornguard-activation-id identifies the active browser / CLI / device instance
  • x-thornguard-activation-proof binds that activation to the current client instance
  • x-thornguard-session-id binds runtime/session-local enforcement state for the protected launch
  • x-upstream-auth optionally forwards a separate bearer token to the upstream service
  • /mcp/:connection-id resolves the saved protected connection and becomes the canonical remote address
Legacy compatibility path:
  • /mcp still works for clients that are not migrated yet
  • x-mcp-target-url tells ThornGuard which upstream MCP endpoint to protect on that legacy path
ThornGuard strips its own credentials and internal session/routing headers before forwarding the request upstream.

​
OAuth / JWT Interoperability

ThornGuard also supports additive OAuth-style bearer authentication for HTTP clients when that deployment enables it. Protected Resource Metadata is served from:
  • /.well-known/oauth-protected-resource
  • /.well-known/oauth-protected-resource/mcp
License keys plus activation IDs remain the default documented path. OAuth/JWT is additive and deployment-configured.

​
Secret Handling Notes

  • ThornGuard sanitizes sensitive values such as auth headers, ThornGuard credentials, and upstream bearer tokens before they are written into ThornGuard-controlled audit rows or webhook deliveries.
  • Local client tools or bridge commands may still expose CLI-passed headers in local logs before the request reaches ThornGuard.
  • Prefer managed secret inputs, environment variables, or keychain-backed storage over hardcoding bearer tokens into shared config files.

​
Correlation Headers

ThornGuard returns these headers on successful proxied responses and ThornGuard-generated error responses:
  • x-thornguard-log-id
  • x-thornguard-trace-id
  • x-thornguard-session-id
  • x-thornguard-session-expires-at
  • x-thornguard-connection-id on managed routes
  • x-thornguard-route-mode (managed or legacy)
Use them to trace a client-visible request back to D1 audit logs and webhook deliveries.

​
Management API Surface

Core routes:
  • GET /api/logs
  • GET /api/logs/export
  • GET /api/stats
  • GET /api/settings
  • PUT /api/settings
  • POST /api/license/activations/ensure
  • GET /api/license/activations
  • DELETE /api/license/activations/:id
License activation routes are managed with the primary THORN-... license key. They are not an OAuth-managed surface, even when OAuth/JWT support is enabled for other ThornGuard routes.
Platform routes:
  • GET /api/policies
  • POST /api/policies
  • PATCH /api/policies/:id
  • DELETE /api/policies/:id
  • GET /api/connections
  • POST /api/connections
  • PATCH /api/connections/:id
  • DELETE /api/connections/:id
  • GET /api/connections/:id/advisories
  • POST /api/connections/:id/advisories/refresh
  • GET /api/integrations
  • POST /api/integrations
  • PATCH /api/integrations/:id
  • DELETE /api/integrations/:id
  • POST /api/integrations/:id/test
  • GET /api/integrations/:id/deliveries
  • GET /api/tools
  • POST /api/tools/:id/repin
  • POST /api/tools/:id/unpin
  • GET /api/approval-profiles
  • POST /api/approval-profiles
  • PATCH /api/approval-profiles/:id
  • DELETE /api/approval-profiles/:id
  • GET /api/approval-requests
  • POST /api/approval-requests/:id/approve
  • POST /api/approval-requests/:id/deny
  • GET /api/redaction-rules
  • POST /api/redaction-rules
  • PATCH /api/redaction-rules/:id
  • DELETE /api/redaction-rules/:id
The tools API can now include trust metadata such as:
  • drift_status
  • drift_detected_at
  • drift_details_json

​
Upstream Credentials

If your upstream MCP server needs its own bearer token, pass it separately:
  • x-upstream-auth: Bearer ...
ThornGuard uses that value as the upstream Authorization header and does not forward your ThornGuard credential upstream.

​
Advisory Metadata

The connections API is the management surface behind ThornGuard’s opt-in advisory intelligence.
  • connections hold non-secret metadata such as target URL, vendor name, repo URL, status page URL, whether intelligence is enabled, the preferred protected_path / protected_url, connection drift policy, and session TTL.
  • connections are saved inventory records for advisory management; they are separate from Polar activation seats.
  • advisories expose warn-first findings for availability, dependency, and vendor-risk signal.
  • Upstream bearer tokens remain local to the CLI or client machine in this milestone and are not stored server-side in the connection record.