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’s newer platform controls are centered around understanding tool risk, requiring approvals for sensitive actions, and layering tenant-specific redaction rules on top of the built-in PII redaction engine.
In the live dashboard, these controls appear in the Platform tab when the matching feature flags are enabled. The default license-key dashboard session is owner-scoped. Deployments that add SSO or JWT-backed auth can expose narrower read-only views, while approval and redaction changes still require a session with management permission.

Tool Inventory

On successful tools/list responses, ThornGuard can persist a catalog of upstream tools per license and upstream origin. Stored data includes:
  • tool name
  • optional title
  • annotation metadata
  • input and output schema hashes
  • optional pinned input and output schema hashes plus pin timestamp
  • upstream target
  • computed risk level
  • first-seen and last-seen timestamps
Risk is derived from both MCP annotations and ThornGuard heuristics. For example:
  • destructiveHint pushes a tool toward high
  • readOnlyHint pushes a tool toward low
  • names like delete, exec, shell, deploy, or publish raise risk

Approval Workflows

Approval profiles let a tenant require explicit approval before ThornGuard will forward certain tools/call requests. Approvals can be triggered by:
  • matched policy context
  • high-risk tools
  • medium-risk tools when configured
When approval is required, ThornGuard creates an approval_requests record and returns a structured error payload containing an approval URL. If the client advertised URL-mode elicitation capability during initialize, ThornGuard can include a URL-mode approval hint in the response.

Approval API

  • 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

Approval Behavior Today

The current live approval flow is a single-decision queue:
  • ThornGuard pauses the request and records an approval_requests row
  • one approve action marks the request approved
  • one deny action marks the request denied
Quorum or multi-signature approval thresholds are not part of the current shipped dashboard flow. If you need dual authorization semantics today, treat that as planned work rather than a live guarantee.

Custom Redaction Rules

Built-in PII and secret detection is always on. Enterprise tenants can add custom regex rules on top. Each custom rule has:
  • a mode: audit or redact
  • a regex pattern
  • an optional replacement
  • an enabled flag
  • optional target_paths — JSON path selectors that scope the rule
Rules are stored in the redaction_rules table and applied after ThornGuard’s built-in redaction engine.

Path-Targeted Redaction

By default, custom redaction rules apply globally to all string values in request and response payloads. With target_paths, you can scope a rule to specific JSON paths:
{
  "pattern": "\\d{4}-\\d{4}-\\d{4}-\\d{4}",
  "mode": "redact",
  "replacement": "[CARD REDACTED]",
  "target_paths": ["$.payment.card_number", "$.billing.cc"]
}
This prevents over-matching — the rule above only applies to the payment.card_number and billing.cc fields, not to every string in the payload.
The live dashboard can create and edit path-targeted rules directly. The API remains the source of truth for automation and bulk management.

Redaction API

  • GET /api/redaction-rules
  • POST /api/redaction-rules
  • PATCH /api/redaction-rules/:id
  • DELETE /api/redaction-rules/:id

UI Status

The live backend and deployed dashboard both support tool inventory, the single-decision approval queue, and custom redaction today. The exact sections visible in the UI still depend on feature flags and current session permissions.