Threat Signatures

Known-dangerous structural shapes matched via JSD — not hardcoded capability pairs

Status: shipped — Stage 1 in shadow mode. The registry matches in production; outputs feed telemetry. Signature distillation from the GNN is roadmap.

Threat Signatures

Some structural flow patterns are dangerous regardless of the agent’s history. An exfiltration shape is dangerous whether it’s the agent’s first session or its thousandth. Threat signatures provide this shape-based detection without hardcoding specific tool combinations.

Signatures Are Shapes, Not Patterns

A signature is NOT “if read_file then curl = exfiltration.”

A signature IS “the flow matrix has 80%+ of its mass in the read→outbound quadrant.” This catches read_file→curl, query→send_message, fetch→upload, and any other combination that produces the same structural shape.

How Matching Works

Matching uses the same JSD math as the rest of the system, but inverted:

Comparison	HIGH JSD means	LOW JSD means
Baseline (envelope)	Anomalous — session deviates from learned pattern	Normal
Signature (threat)	Normal — session doesn’t match threat shape	Match — structurally similar to known threat

Session flow vs exfiltration signature:
  JSD = 0.12 → LOW → matches exfiltration shape
  Similarity = 1.0 - 0.12 = 0.88 → 88% structurally similar

Built-in Signatures

5 structural shapes shipped with the binary:

ID	Name	Shape	MaxJSD	Severity
QT-SIG-001	Exfiltration	read→send/upload concentrated	0.30	Critical
QT-SIG-002	Credential Relay	auth→send/upload concentrated	0.25	Critical
QT-SIG-003	Staging + Execution	write→execute concentrated	0.30	High
QT-SIG-004	Reconnaissance	read fan-out to many capabilities	0.35	Medium
QT-SIG-005	Cover Tracks	read→delete concentrated	0.25	High

Scoped Matching

Signatures can be scoped by agent type and nesting depth:

{
  "id": "QT-SIG-006",
  "name": "Sub-agent privilege escalation",
  "agent_types": ["claude-code", "cursor"],
  "min_depth": 2,
  "flow_shape": [[...]]
}

• agent_types: empty = universal (all agents). Populated = only for those types.
• min_depth: 0 = any depth. Populated = only match at that depth or deeper.

A staging signature with min_depth: 2 only fires for sub-agents, not root agents. This differentiates “code agent compiling” (depth 0-1, normal) from “sub-agent privilege escalation” (depth 3+, suspicious).

Signature Validation

All signatures (built-in, loaded from JSON, or pushed by BI Service) are validated:

• MaxJSD must be in (0, 0.5] — prevents universal false positives
• Weight must be in [0.1, 1.0] — prevents invisible signals
• FlowShape must have at least one non-zero entry
• ID and Name must not be empty

Signature Updates

Tier 0 (Local)

5 built-in signatures in the binary. For air-gapped deployments, load from JSON file:

quint update-signatures --file /path/to/signatures.json

Tier 2 (Enterprise)

BI Service pushes learned signatures via CorrectionReceiver. The GNN detects structural invariants from real attack data and distills them into FlowMatrix signatures.

Tier 3 (Global)

Quint Global aggregates anonymized attack shapes from all orgs. New signatures propagate to all tenant BIs within ~2 minutes. Only FlowMatrix shapes are shared — no customer data.

Known Limitation: Uniform Flow Evasion

An attacker who distributes actions uniformly across all capability pairs produces high JSD against every concentrated signature (evading all 5). This is by design — concentrated signatures detect concentrated attacks.

Defense-in-depth: The baseline divergence check (flow:structural_divergence) fires when a session’s flow deviates from the agent’s normal pattern. An agent that normally does read→read would trigger this signal even with uniform flow. Signatures are the belt; the envelope is the suspenders.

Signature Levels (Future)

Level	Scope	Source
Universal	All agents, all orgs	Quint Global + built-in
Agent-type	Per platform (claude-code, cursor)	BI Service group analysis
Per-agent	Individual baseline	The fingerprint’s FlowMatrix (existing envelope)

Currently only Level 1 (universal) is implemented. Agent-type signatures will be generated by the BI Service (QDEV-152). Cross-org federated signatures are planned for Tier 3 (QDEV-153).