Question 1

An AI agent touching my infra, isn't that dangerous?

Accepted Answer

That's the right question. ThreatClaw was designed around this constraint: several defense layers are compiled directly into the binary, not configurable, not bypassable, not removable post-deploy. In default mode, the agent observes and proposes: it never acts without explicit human approval (HITL via Slack/Telegram/email/Signal). The code is open source under AGPL v3, so you can audit every line before deploying.

Question 2

What if the LLM hallucinates or proposes an absurd action?

Accepted Answer

The AI can never trigger an action on its own. Every proposed action goes through a static filter compiled into the binary, which only recognizes known, reversible operations with validated targets. A suggestion that doesn't match any expected action is rejected before execution. In default mode, the operator receives the full proposal (analysis + indicators + expected impact) and validates with one click in chat, or refuses.

Question 3

Local AI or cloud AI, which one to choose?

Accepted Answer

Our default recommendation is local AI (LLM via Ollama on your server): 100% of your data stays with you, zero leakage possible. Cloud AI can be added as a second opinion on complex or ambiguous cases, in which case, all sensitive data is automatically substituted by reversible tokens before sending. The cloud LLM never sees an identifier, IP, or credential. The restoration mapping lives in memory only, never on disk.

Question 4

How does anonymization work, and what if it misses something?

Accepted Answer

Before any external LLM call, data goes through a Rust-written anonymizer that automatically detects common sensitive identifiers (technical, financial, personal) and replaces them with reversible tokens. On response, tokens are restored locally. The mapping lives in memory only.

The residual risk of any pattern-based anonymizer exists, and we acknowledge it. Three mitigations: (1) you can enrich coverage with your own business-specific rules (internal project names, naming conventions), (2) the default option remains sovereign local AI that doesn't exfiltrate anything, (3) the anonymizer code is open source AGPL, you can audit and extend it.

Question 5

Concretely, what does ThreatClaw do?

Accepted Answer

ThreatClaw is an autonomous cybersecurity agent that runs continuously on your infrastructure. It ingests the signal sources you connect (syslog, IDS alerts, SIEM events, scans, CTI), correlates events through multiple detection layers, and produces for each incident a complete dossier: verdict with confidence level, indicators of compromise, blast radius, and 1 to 3 corrective actions ready to execute. Depending on mode: it notifies you for validation (HITL), or executes low-risk actions directly (autonomous).

Question 6

What actions can it execute on my system?

Accepted Answer

All possible actions are defined in the open source code, no arbitrary shell, no dynamic commands. Broadly: isolate a compromised endpoint, block an IP at the firewall, lock a suspicious user account, quarantine a malicious file, stop a Docker container, capture forensic evidence. Every action is recorded in a cryptographically-signed audit log, and any destructive action requires human approval in default mode.

Question 7

Which observation sources can ThreatClaw consume?

Accepted Answer

19+ signal sources are natively supported: SIEM (Wazuh, FortiGate, OPNsense), enterprise firewalls, EDR agents (Velociraptor), Linux/Windows server logs via syslog, vulnerability scans, threat intelligence (CrowdSec), IDS/IPS alerts, and any equipment that speaks standard syslog. A typical SMB generates 4,500 alerts/day of noise; ThreatClaw consolidates that into a handful of qualified, actionable incidents.

Question 8

How do I collect my logs?

Accepted Answer

ThreatClaw includes an integrated syslog collector listening on the standard port 514. Point your Linux servers (auth.log, syslog), Windows (Event Log via syslog), firewalls and Docker containers at that endpoint. Logs are stored in local PostgreSQL and flow through the detection layers (Sigma rules, IDS, ML) which generate prioritized alerts. No external SaaS log management needed, everything stays on your server.

Question 9

Why did you choose Rust for the agent core?

Accepted Answer

A security agent runs with elevated privileges on the customer's infrastructure. If the agent itself has memory bugs, it's a nightmare. Rust eliminates at compile time the most exploited classes of bugs (buffer overflow, use-after-free, race conditions, null pointer deref). It's a non-negotiable prerequisite, not an aesthetic choice.

Question 10

Is ThreatClaw NIS2 / GDPR / ISO 27001 compliant?

Accepted Answer

Honest answer: compliance is an organizational process that depends on your context, not a checkbox in a tool. What ThreatClaw brings concretely: cryptographic audit trail usable as evidence, 11 pre-filled regulatory reports (NIS2, GDPR, ISO 27001, EU AI Act, ISO 42001, NIST AI RMF, NIST CSF 2.0, EU CRA, SOC 2, HDS, PCI-DSS), per-table data retention, anonymization of personal data before any cloud send. The tool documents your process, it doesn't replace it.

Question 11

What happens if the agent itself is compromised?

Accepted Answer

This is exactly the scenario the binary-baked defense layers are designed for. Without going into specifics (a defensive agent doesn't publicly publish its defense map, anti-evasion policy), broadly: binary integrity verified at startup with refusal to start if tampered, action surface limited to compile-time-known operations an attacker can't extend, signed audit trail for forensic reconstruction, automatic shutdown on suspicious behavior. The AGPL v3 source remains available if you want to audit details.

Question 12

How many CVEs in ThreatClaw?

Accepted Answer

Policy: zero critical CVE tolerated in the release binary. The binary is analyzed by cargo audit in CI at every build, and the SBOM (software bill of materials) is published at every release tag. Any reported CVE opens a public GitHub ticket with a 72-hour patch window for critical CVEs. You can verify the binary state yourself by retrieving the SBOM and scanning it with your usual tooling (Trivy, Grype, etc.).

Question 13

What do I need to deploy ThreatClaw?

Accepted Answer

A Linux server with Docker installed. Minimum 8 GB RAM (16 GB recommended if you enable the local LLM). 20 GB disk (50 GB with downloaded AI models). One install command: `curl -fsSL https://get.threatclaw.io | sudo bash`. An onboarding wizard then configures AI, communication channels, autonomy level and log sources. Count 30 minutes for a first working deployment.

Question 14

Is ThreatClaw really free?

Accepted Answer

The code is open source under AGPL v3, free and auditable on GitHub (every feature is identical across all tiers. The Free tier lets you monitor a limited number of assets (ideal for very small businesses / SMBs / labs). For larger fleets, the paid Starter / Pro / Business tiers unlock higher caps. See the Pricing page for details. Human onboarding (deployment, calibration, CISO training) is offered separately by CyberConsulting.fr) that's the service business that funds development.

Question 15

Can I monitor multiple servers / sites?

Accepted Answer

Yes. Define each target in the configuration with a mode (HITL by default / autonomous) and access type (SSH, WinRM, exposed API, or local agent on the target). The ThreatClaw instance centralizes analysis and executes approved actions on the right target. Multi-site setups support regional collectors + central aggregator architecture.

Question 16

How am I alerted on an incident?

Accepted Answer

Via the channels you configure: email, Slack, Telegram, Discord, Signal, or custom webhook to your internal tool. In HITL mode, approval is done directly in chat (with anti-replay nonce to prevent reuse of a past approval). A real-time web dashboard is also available for centralized view and compliance reports.

Question 17

What are the ThreatClaw rule packs?

Accepted Answer

A subscription to ready-to-use detection rule packs, continuously updated and signed. They cover 8 engines, Sigma (SIEM/EDR), YARA (files/memory), NIDS Suricata (network), Falco (container/cloud), Nuclei (vulnerabilities), OPA (IaC compliance), osquery and Velociraptor (DFIR), plus IOC and LLM red-team feeds. Every rule ships with its investigation playbook. Full catalog: 6,400+ Sigma and 12,000+ YARA rules.

Question 18

Aren't these just repackaged open-source rules?

Accepted Answer

No. We forge our own in-house rules (malware families, offensive tools, LOLBins, vulnerable drivers, brand typosquatting…) you won't find anywhere else. For the community sources we do include, we genuinely curate them: per-file license verification, deduplication, validation on the real engine (a rule that doesn't compile doesn't ship), anti-false-positive testing on a large corpus. We don't resell scraped rules, we deliver proven detection.

Question 19

Is there a free demo pack?

Accepted Answer

Yes. A free sample of our in-house rules across every engine we run (Sigma, YARA, osquery, Velociraptor, Falco, network, policy), each detection with its CACAO 2.0 investigation playbook. The Sigma rules come already converted for 6 SIEMs (Splunk, Sentinel, Elastic, QRadar, CrowdStrike, Panther), and a NIS2 compliance sample is included. Downloadable directly from the "Rules" menu or the feed pages, no signup required.

Question 20

Do the Sigma rules come converted for my SIEM?

Accepted Answer

Yes. Every Sigma rule ships already converted for Splunk (SPL), Microsoft Sentinel (KQL), Elastic (Lucene), QRadar (AQL), CrowdStrike (LogScale) and Panther (SDYAML), paste straight into your SIEM. When a rule doesn't map cleanly to a SIEM (a field missing from its schema), we ship what genuinely converts rather than a broken query.

Question 21

What is an "investigation playbook"?

Accepted Answer

For every rule, a step-by-step sheet the analyst follows when the rule fires: confirm the alert, find the origin, scope the impact, remediation leads. In the CACAO 2.0 standard (OASIS), importable into your SOAR. Generated deterministically, without AI: each step derives from a fact the rule carries (ATT&CK, known false positives, MITRE D3FEND), nothing is invented, and the playbook is read-only (never an executable command; response stays a human decision).

Question 22

How often are the packs updated?

Accepted Answer

Continuously. Packs are rebuilt and published daily; your sync script picks up the new version on its next run. Each release is signed (Ed25519) and passes an anti-poisoning gate that refuses suspicious changes (mass detection removal, dangerous capability appearing without review).

Question 23

Can I use the rules without the ThreatClaw agent?

Accepted Answer

Yes. The rule subscription is decoupled from the agent: it's a standalone feed you plug into your own stack (SIEM, YARA engine, Suricata, osquery, etc.). The ThreatClaw agent consumes them natively, but it is not required.

Question 24

You aggregate several sources: how do you handle duplicates?

Accepted Answer

By similarity comparison between rules, not by matching names or hashes, which would let variants through. Near-duplicates are removed from the shipped pack, and the grey zone, rules that are close without being identical, is set aside for human review rather than shipped by default. It is an invisible part of the work and yet the first reason a raw aggregate is unusable in production.

Question 25

What format do the packs arrive in?

Accepted Answer

In the native format of the engine concerned, ready to load: nothing to convert on your side. Alongside it comes an index describing every rule with its security references, and thematic groupings by category, by attack technique or by compliance requirement. That is what lets you load a targeted subset rather than the whole pack, and evidence coverage to an auditor.

Question 26

How do I know the pack was not tampered with in transit?

Accepted Answer

Every release is signed with Ed25519, and your sync script verifies the seal before extracting anything: without a verifiable seal it refuses and stops, there is no fallback path. What matters is where the private key lives: never on the continuous-integration machine, the one that downloads third-party content and runs engines on it. It never leaves our own machine. The rule is simple: the machine that ingests untrusted content never holds the key.

Question 27

What stops someone from quietly weakening a rule upstream?

Accepted Answer

This is the real threat model for a detection feed, and it is not malware: nobody needs to execute code, adding one exclusion or breaking one condition is enough to blind every subscriber at once, silently. Two safeguards. Sources are pinned to an exact revision, so taking an upstream change is a deliberate act rather than something time does to you. And every release goes through a gate that compares it with the previous one: an abnormal delta quarantines the version and the feed you receive stays untouched.

Question 28

Is there any executable code in your packs?

Accepted Answer

No, never. A pack contains text only: rules, YAML, JSON, SQL. The scenario where you download and run a booby-trapped binary does not exist here. For the vulnerability-template pack, an extra filter drops anything that could act rather than observe, along with intrusive and denial-of-service categories.

Question 29

How do you keep a rule from drowning my SOC in false positives?

Accepted Answer

Two stages. At build time, every rule must compile on the real engine you actually run, not on a linter, and that check is blocking: what fails does not ship. Then the whole pack is audited against a corpus of real legitimate activity, not synthetic traffic, and rules that fire on it are dropped or moved to monitor-only. We do not claim zero false positives in your environment, which is not ours: we guarantee that a rule which is noisy on normal activity does not reach you unexamined.

Question 30

How is it licensed and priced?

Accepted Answer

The rule feed subscription is separate from the agent license (open source, AGPL v3). Part of the in-house rules is proprietary (not redistributable); community sources keep their original license, verified per file and documented. For subscription pricing, see the Pricing page or contact us.

Question 31

Are your detection feeds mapped to regulatory requirements (NIS2, ReCyF)?

Accepted Answer

Yes. Every feed subscription ships with a per-requirement coverage map: for each NIS2 requirement (ENISA annex) and ReCyF, we show which of your rules address it, plus the list of gaps. The chain is traceable and public (Sigma to ATT&CK to NIST 800-53 to CSF 2.0 to NIS2). This is design coverage: it evidences that the catalogue addresses the requirement, it is neither a certification nor a real-time measurement. Many requirements are purely organizational and cannot be covered by rules; we show them honestly as gaps. The map ships as a readable report and in OSCAL (the machine-readable standard).

Question 32

I use a GRC (CISO Assistant, etc.). Can I import your coverage into it?

Accepted Answer

Yes, through a connector. It creates or updates your audit in the GRC and, for each requirement your rules cover, attaches a ThreatClaw evidence and control, then sets the requirement to "to review". You, or your CISO, validate and assert the final "compliant": the connector never ticks your compliance on its own, it just saves you the pre-fill. We also provide a loadable mapping library and the OSCAL export for other tools. Technical note: CISO Assistant does not ingest OSCAL, so our connector uses its REST API.

Question 33

Do you cover DORA?

Accepted Answer

Partially, and we say so plainly. Unlike NIS2, there is no official EU DORA crosswalk. So we back our rules to the DORA articles they directly support: detection (art. 8, 10), protection (art. 9), resilience testing (art. 24 to 27). Our red-team pack is a testing tool that supports the TLPT article; it is not the authority-scoped certified TLPT engagement. The crosswalk to ISO or NIST goes through a recognized third-party framework (SCF), cited as such. We do not claim governance, incident reporting, third-party risk management or continuity.

Question 34

Can I deploy your rules for my own clients?

Accepted Answer

Yes for the aggregated part, which comes exclusively from permissively licensed sources and stays redistributable, including for MSSP use. Copyleft components are isolated in their own bundle, under their own licence, with attribution. Our in-house forged rules are proprietary and reserved for your own subscriber use: they are not redistributable. Every pack ships a NOTICE file spelling out exactly what falls under what.

Question 35

What happens if I cancel my subscription?

Accepted Answer

You keep what you have already downloaded, we disable nothing remotely. What you lose is the flow: no new rules, no false-positive corrections, no coverage of threats that appear after you leave. That is the key thing to understand about this product: the value is not in today’s bundle, it is in the fact that it changes every week.

Your questions. Our honest answers.

AI and your data