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 now includes structured policies and outbound integrations in the management API, with webhook delivery as the fully surfaced dashboard path.
In the live dashboard, these controls live under the Platform tab when the relevant feature flags are enabled. Mutating actions require a license-owner session or a role-scoped admin-capable credential.

​
Structured Policy Rules

Policy rules let you match on request context without relying only on coarse substring blocklists. Each rule has schema fields for:
  • a scope: request, response, or both
  • a mode: allow, audit, or block
  • a priority
  • a conditions_json payload describing what should match
Today, the active enforcement path is request-focused, with audit and block being the meaningful operational modes. Supported condition types include:
  • RPC method patterns
  • target domains
  • client IP CIDR ranges
  • selected header matches
  • JSON selector checks
  • substring or regex content patterns
  • tool name patterns
  • tool risk levels

​
Evaluation Order

Customer policies run after ThornGuard’s non-overridable checks — HTTPS enforcement, origin validation, DNS-aware SSRF, authentication, IP allowlisting, and rate limiting — but before built-in malicious command scanning and blocklist evaluation. That means:
  • policies can narrow what is allowed beyond the built-in checks
  • policies cannot disable built-in safety controls (transport, SSRF, rate limiting, blocklists all still apply)
  • audit-mode policies generate telemetry without blocking traffic

​
Policy API

The management API exposes:
  • GET /api/policies
  • POST /api/policies
  • PATCH /api/policies/:id
  • DELETE /api/policies/:id
Rules are tied to the authenticated license and stored in the policy_rules D1 table.

​
Outbound Integrations

ThornGuard can push security and audit events to external systems. Events are queued asynchronously and recorded in integration_deliveries for traceability.

​
Integration Types

The dashboard and management API both support creating and managing all integration types.
TypeDelivery shape
webhookGeneric HTTP POST with HMAC-SHA256 signature and ThornGuard correlation headers
slackSlack incoming webhook with formatted message blocks (secret optional)
teamsMicrosoft Teams incoming webhook with MessageCard format (secret optional)
datadogDatadog Events API with DD-API-KEY header
splunk_hecSplunk HTTP Event Collector with Authorization: Splunk <token>
s3S3-compatible object storage (one JSON file per event)

​
OCSF Event Format

Integration deliveries use a stable ThornGuard event payload with correlation headers. Several sink adapters map that event through Open Cybersecurity Schema Framework (OCSF) v1.3.0 structures inside the backend. Key OCSF fields included in every delivery:
  • metadata.version — OCSF schema version (1.3.0)
  • metadata.product.name — ThornGuard
  • category_name — Security Findings for threat events, Network Activity for operational events
  • severity_id — mapped from ThornGuard action type
  • action — the original ThornGuard audit action
  • unmapped.logId, unmapped.traceId, unmapped.licenseHash — ThornGuard-specific correlation fields
Platform-specific adapters exist in the current backend for Slack, Teams, Splunk HEC, Datadog, and S3, but the dashboard-guided path today remains the generic webhook flow.

​
Integration API

The current backend routes are:
  • GET /api/integrations
  • POST /api/integrations
  • PATCH /api/integrations/:id
  • DELETE /api/integrations/:id
  • POST /api/integrations/:id/test
  • GET /api/integrations/:id/deliveries
  • Use Custom Blocklists for simple tenant-owned block patterns.
  • Use policy rules when you need method-aware, JSON-aware, or risk-aware decisions.
  • Use webhook integrations for the stable live dashboard flow into your broader security tooling.