Closed-Loop Signature Distribution

Detection to fleet-wide prevention in 30 seconds — design, format, and engineering plan

Closed-Loop Signature Distribution

How Quint turns a single detected attack into fleet-wide prevention in under 30 seconds.

Industry Patterns

Six systems informed this design. Each solves the same problem differently.

System	Detection Source	Distribution	Latency	Tenant Isolation
CrowdStrike Falcon	Cloud ML + threat graph	Lightweight agent pulls from CrowdStrike Security Cloud	Minutes (IoC push via channel files)	Per-tenant CID scoping; shared threat graph
SentinelOne	On-agent Behavioral AI + cloud Threat Intel engine	Cloud pushes blocklist hash updates; agent pulls on miss	Seconds (local AI) / hours (cloud reputation)	Per-console blocklists; shared reputation feeds
F5 AI Remediate	Red Team findings (adversarial prompts)	Generates guardrail packages; human approves; runtime deploy	Hours (human-in-loop by design)	Per-customer guardrail bundles
Suricata / ET Rules	Community + Proofpoint ET research	suricata-update pulls rulesets; reload via SIGHUP	Daily (cron pull) to minutes (commercial feeds)	N/A (on-prem, operator manages)
Sigma Rules	Community YAML rules	Git pull + pySigma backend compilation	Manual (git sync)	N/A (open format, operator compiles)
YARA Rules	Analyst-authored or ML-extracted patterns	File distribution or EDR push	Varies (manual to automated)	Per-org rule sets

Key takeaways:

• CrowdStrike’s speed comes from a centralized threat graph that compresses ML output into lightweight IoC updates distributed via a persistent agent-cloud channel. Same architecture Quint already has (daemon heartbeat + NATS/SNS).
• SentinelOne proves local-first AI + cloud-pushed signatures is the right hybrid. Their Behavioral AI runs on-agent (like Quint’s proxy gates), cloud updates supplement it.
• F5 AI Remediate is the closest analogy to Quint’s domain: AI model security. Their loop is Red Team finding -> guardrail package -> deploy. Quint’s is divergence detection -> FlowMatrix signature -> push. The difference: F5 requires human approval. Quint auto-confirms above 0.95 confidence, human-confirms below.
• Sigma/YARA prove that a vendor-neutral rule format with metadata (MITRE tags, severity, provenance) is table stakes. Quint’s ThreatSignature already has this shape.

Architecture

                                    CLOUD
 +------------------------------------------------------------------+
 |                                                                  |
 |  Divergence       BI Service         Signature        SNS/NATS   |
 |  Detector    -->  5-Stage     -->    Distiller   -->  Publish     |
 |  (SQS)           Pipeline            (GNN)          |            |
 |                   |                   |              |            |
 |                   v                   v              |            |
 |              Memgraph            Analyst UI          |            |
 |              (graph DB)          (confirm/reject)    |            |
 |                                                      |            |
 +------------------------------------------------------+------------+
            |                                           |
            | quint.signatures.{org_id}                 | quint.signatures.global
            |                                           |
 +----------v---------+                    +------------v-----------+
 |    Daemon A         |                    |    Daemon B            |
 |  ThreatSigRegistry |                    |  ThreatSigRegistry    |
 |  JSD match <1us    |                    |  JSD match <1us       |
 |  Gate 1 enforcement |                    |  Gate 1 enforcement   |
 +---------------------+                    +-----------------------+
       Org: Acme                                  Org: Acme
                                                  (or: all orgs for global)

The Pipeline: Detection to Prevention

Step 1: Detection

Three sources produce candidate detections:

1. Divergence Detector — intent vs truth mismatch (phantom intent, shadow action, target mismatch). Confidence-scored per session.
2. GNN Scorer — multi-level ensemble (VGAE + GAT + Mahalanobis + node-max) flags structurally anomalous sessions. AUROC 1.000 on synthetic data.
3. Analyst escalation — security team marks a session as malicious from the dashboard.

Step 2: Confirmation Gate

Confidence	Action
>= 0.95	Auto-confirm. Signature distilled immediately.
0.70 - 0.95	Queue for analyst review. Dashboard shows detection with context.
< 0.70	Log only. Feeds training data for Stage 3 (XGBoost).

Auto-confirmation is the speed advantage. CrowdStrike and SentinelOne both auto-push high-confidence IoCs. F5 explicitly does not — their threat model requires human sign-off because they’re modifying guardrails on production AI models. Quint’s signatures are additive (they add a match pattern, not modify existing policy), so auto-push at high confidence is safe.

Step 3: Distill

The SignatureDistiller extracts the attack shape:

1. Query the session’s action graph from Memgraph
2. Build the 12x12 capability transition matrix (same 12 capabilities used across the platform)
3. Normalize to a probability distribution
4. Compute max_jsd threshold — tighter for higher GNN confidence (0.20 at confidence 0.99, 0.30 at confidence 0.95)
5. Assign MITRE ATT&CK mapping from the GraphReasoner’s fired rules
6. Package as ThreatSignature JSON

Step 4: Sign and Version

Every signature is:

• Signed with the BI Service’s Ed25519 key. Daemons verify before loading.
• Versioned with a monotonic sequence number per org. Daemons reject out-of-order or replayed signatures.
• Idempotent by id — re-publishing the same signature is a no-op on the daemon.

Step 5: Distribute

Two channels, two scopes:

Channel	Scope	Use Case
quint.signatures.{org_id}	Single tenant	Org-specific attack patterns. Full fidelity.
quint.signatures.global	All tenants	Anonymized universal signatures. FlowMatrix only — no tool names, no resource paths.

Distribution uses the existing SNS->SQS fan-out for cloud-to-daemon delivery (same path as policy sync on heartbeat). For latency-critical push, NATS quint.signatures.> subject hierarchy with per-org ACLs.

Step 6: Daemon Receives

The daemon’s CorrectionReceiver:

1. Validates Ed25519 signature
2. Checks version monotonicity
3. Validates schema (MaxJSD in (0, 0.5], weight in [0.1, 1.0], non-empty flow shape)
4. Adds to ThreatSignatureRegistry
5. Immediately active for all subsequent Gate 1 evaluations

End-to-end latency: ~30 seconds (GNN inference + NATS publish + daemon poll).

Step 7: Block

Next matching flow triggers the configured enforcement action:

• Shadow mode: log the match, do not block. (Current state.)
• Alert mode: log + fire alert to dashboard/SIEM.
• Block mode: reject the tool call at the proxy. Agent receives an error.

Signature Format

{
  "id": "QT-GNN-7F3A9E12",
  "version": 42,
  "name": "GNN-learned: credential relay via sub-agent",
  "provenance": "ml-distilled",
  "source_session_id": "sess-a1b2c3d4",
  "source_detection_id": "det-e5f6g7h8",
  "created_at": "2026-05-03T14:22:00Z",
  "flow_shape": [
    [0.00, 0.00, 0.00, 0.02, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00],
    [0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00],
    [0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00],
    [0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.45, 0.00, 0.00, 0.00, 0.00, 0.00],
    [0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00],
    [0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00],
    [0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.40, 0.00, 0.00, 0.00],
    [0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00],
    [0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00],
    [0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.13],
    [0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00],
    [0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00]
  ],
  "max_jsd": 0.25,
  "severity": "critical",
  "weight": 0.90,
  "agent_types": ["claude-code", "cursor"],
  "min_depth": 2,
  "mitre_attack": ["T1003", "T1041"],
  "mitre_tactics": ["credential-access", "exfiltration"],
  "compliance_refs": ["SOC2-CC6.1", "NIST-800-53-SI-4"],
  "tags": ["credential-relay", "sub-agent", "auth-to-upload"],
  "ttl_hours": 720,
  "ed25519_signature": "base64-encoded-sig"
}

Field Reference

Field	Type	Description
id	string	Unique identifier. QT-SIG- prefix for hand-authored, QT-GNN- for ML-distilled, QT-IMP- for imported.
version	int	Monotonic per-org version. Daemon rejects version <= current.
provenance	enum	analyst-authored, ml-distilled, auto-confirmed, imported, federated
flow_shape	float[12][12]	Capability transition probability matrix. Rows = source capability, columns = target.
max_jsd	float	Maximum Jensen-Shannon Divergence for a match. Lower = stricter. Range (0, 0.5].
severity	enum	critical, high, medium, low
weight	float	Scoring weight [0.1, 1.0]. ML-distilled signatures start at 0.85, analyst-authored at 1.0.
agent_types	string[]	Empty = universal. Populated = match only these agent platforms.
min_depth	int	0 = any nesting depth. >0 = only match sub-agents at that depth or deeper.
mitre_attack	string[]	MITRE ATT&CK technique IDs. Mapped from GraphReasoner fired rules.
compliance_refs	string[]	Compliance framework references (SOC2, NIST, ISO, etc.)
ttl_hours	int	Signature expires after this many hours. 0 = permanent. Default 720 (30 days).
ed25519_signature	string	Cryptographic signature over all fields except this one.

Capability Indices (the 12x12 axes)

Index	Capability	Examples
0	read	file reads, DB queries, API GETs
1	write	file writes, DB inserts
2	delete	file deletes, DB drops
3	auth	credential access, token generation
4	execute	process exec, bash, shell
5	search	grep, find, code search
6	send	HTTP POST, email, upload, outbound
7	receive	download, fetch, inbound data
8	configure	env vars, settings, config writes
9	monitor	log reads, metric queries
10	delegate	sub-agent spawn, tool chaining
11	escalate	sudo, privilege elevation, scope expansion

Cross-Tenant Signatures

The hardest design decision. Customer A’s detection becoming Customer B’s prevention is the network effect that makes fleet intelligence valuable. But it creates privacy and competitive risk.

Quint’s approach: anonymize at the FlowMatrix level.

What crosses tenant boundaries:

• The 12x12 capability transition matrix (percentages only — no tool names)
• Severity and MITRE mapping
• provenance: federated

What never crosses:

• Tool names, resource paths, agent IDs, arguments
• Session IDs, customer identity, org metadata
• Raw embeddings (only 64-dim compressed, non-invertible latent vectors if needed for clustering)

Flow: Tenant A detection -> anonymize (strip tool names, resource paths, agent IDs) -> Global BI Service clusters with other tenant detections -> universal ThreatSignature -> publish to quint.signatures.global -> all tenants receive within ~5 minutes.

A customer can opt out of federated intelligence entirely. Their signatures never leave their org scope. They still receive global signatures unless they also opt out of receiving.

Fleet Learning Rate

The metric that matters: Mean Time to Fleet Protection (MTTFP) — from first observation of a novel attack pattern to every daemon in the fleet being able to block it.

Component	Latency	Bottleneck
Event ingestion (edge -> cloud)	~10s	Heartbeat batch sync
BI pipeline (5 stages)	~5s	GNN inference
Distillation + signing	~2s	Ed25519 sign
Distribution (NATS publish)	~1s	Network
Daemon receive + validate	~2s	Heartbeat poll or NATS subscription
Total MTTFP	~20-30s

Fleet learning curve: Each confirmed detection either produces a new signature or refines an existing one (tighter max_jsd, broader agent_types). The signature registry grows monotonically. False positive rate is bounded by the validation constraints (MaxJSD <= 0.5, corroboration from multiple GNN levels).

Observable metric: signatures_matched_per_hour / detections_created_per_hour. When this ratio approaches 1.0, the fleet is catching known patterns at the edge before they reach the cloud pipeline. That is the steady state.

What is Built vs What Remains

Component	Status	Notes
5 built-in FlowMatrix signatures	Shipped	QT-SIG-001 through QT-SIG-005. Shadow mode.
JSD matching in proxy Gate 1	Shipped	<1us per match, production.
ThreatSignatureRegistry on daemon	Shipped	Validates and stores signatures.
quint update-signatures --file CLI	Shipped	Air-gapped manual loading.
BI Service 5-stage pipeline	Shipped	780K events/sec. Memgraph + GNN scoring.
SignatureDistiller (GNN -> FlowMatrix)	Shipped	Extracts 12x12 matrix, packages as ThreatSignature.
NATS quint.signatures.{org_id} publish	Designed, not wired	BI Service publishes; daemon does not yet subscribe.
Daemon NATS subscriber (CorrectionReceiver)	Designed, not wired	Code path exists in docs; needs NATS client in daemon.
Ed25519 signature signing/verification	Not built	Needed before any auto-push to fleet.
Version monotonicity enforcement	Not built	Daemon needs to track per-org signature version.
Auto-confirm gate (confidence >= 0.95)	Not built	Currently all detections require analyst review.
Analyst confirm/reject UI in dashboard	Not built	Detection list exists; confirm->distill->push flow does not.
quint.signatures.global channel	Not built	Cross-tenant anonymization + global publish.
TTL expiry on daemon signatures	Not built	Signatures currently persist until restart.
MITRE ATT&CK mapping on signatures	Partially built	GraphReasoner has MITRE tags; not yet wired to distilled signatures.
provenance field on signatures	Not built	All current signatures are implicitly analyst-authored.

Engineering Effort Estimate

Phase 1 — Intra-org push (1-2 weeks):

• Daemon NATS subscriber for quint.signatures.{org_id}
• Ed25519 signing in BI Service, verification in daemon
• Version monotonicity check
• TTL expiry goroutine
• Wire MITRE tags from GraphReasoner into distilled signatures

Phase 2 — Analyst workflow (1 week):

• Dashboard: confirm/reject detection -> trigger distill -> push
• Auto-confirm gate for confidence >= 0.95
• Provenance tracking on signature records

Phase 3 — Cross-tenant federation (2-3 weeks):

• Anonymization layer (strip tool names, paths, agent IDs from FlowMatrix)
• Global BI Service clustering of anonymized signatures
• quint.signatures.global channel with opt-in/opt-out
• Federated signature dedup (same shape from 3 tenants = higher confidence)

Phase 4 — Observability (1 week):

• signatures_matched_per_hour metric
• MTTFP tracking per signature
• Signature efficacy dashboard (match rate, false positive rate, TTL utilization)