DOC-foundry: Adversarial Agents That Prove Sigma Rules Before You Ship Them DOC-foundry, a project by GitHub user mjha-arya, launched on Hacker News on November 13, 2026 with a pipeline that pairs LLM agents drafting Sigma detection rules against a deterministic engine that proves coverage and a fixed Red-Team adversary that must document two attacks in round one and re-throw them each round. Built on LangGraph, Pydantic, and FastMCP, the tool ingests threat strings such as CVE text, CISA KEV summaries, incident writeups, or ATT&CK techniques and outputs a Sigma rule, a threat report with convergence history, and a proof bundle with false-positive/false-negative counts and a hash. The repository had roughly two stars when explainx.ai cloned it, and its authors describe real-coverage as a bounded adversary set rather than an omniscient Blue Team. DOC-foundry showed up on Hacker News https://news.ycombinator.com/item?id=50491753&ref=explainx on November 13, 2026 with a sharp pitch: models can draft Sigma rules, but they cannot hand you a proof that the rule works, an adversary that provably evades the weak version, and an honest record of how the rule hardened until it held. The GitHub repository https://github.com/mjha-arya/DOC-foundry?ref=explainx ships two pipelines — one that proves coverage with a deterministic engine, and one that reviews like a SOC workflow — on top of LangGraph, Pydantic, and FastMCP. If you build detection-as-code or automate purple-team work with coding agents, this project is worth a weekend install. It is early — roughly two stars when explainx.ai cloned it — but the architecture is unusually explicit about agents propose, engines prove , the same split security teams need as ARTEX-style offensive agents https://explainx.ai/blog/cloudflare-modern-security-model-artex-pentest-orchestrators-2026 scale up parallel probing. TL;DR | Question | Answer | |---|---| | What do you feed it? | Any threat string: CVE text, CISA KEV summary, incident writeup, ATT&CK technique | | What do you get? | Sigma rule, threat report with convergence history, proof bundle with FP/FN and hash | | Offline demo? | python src/run.py --threat fixtures/certutil t1105.json | | Live authoring? | python src/run.py "T1218.011 rundll32..." with Gemini or Claude keys | | Review-only path? | python src/run.py --chain "..." plus optional uvicorn webui.server:app | | Honest limit? | real-coverage is a bounded adversary set, not omniscient Blue Team | Agents that act on your behalf need rules. See how explainx helps secure your agents → https://explainx.ai/agentbeam?src=blog note Why detection engineers care now Sigma rules are portable YAML, but production quality still depends on telemetry shape , benign baselines , and evasion creativity . Teams already feel pressure from two directions: 1. Offensive automation — LLM pentest orchestrators iterate exploits faster than humans can retune detections, a pattern FBI FLASH messaging on ARTEX https://explainx.ai/blog/fbi-artex-flash-warning-agentic-ai-cyberattacks-november-2026 and Cloudflare's 30× traffic spike both describe. 2. Generative drafting — models happily emit Sigma syntax that looks authoritative yet fails on rename tricks, shell obfuscation, or parent-process blind spots. DOC-foundry's response is not another chat wrapper. It runs a self-repair loop where Blue re-authors after a brittle or broken verdict, while Red commits to two documented attacks in round one and re-throws them every round so goalposts do not drift mid-run. Green and gray shields facing off, illustrating DOC-foundry Blue vs Red adversarial detection loop That fixed-adversary discipline mirrors how explainx.ai treats benchmark claims elsewhere: bounded tests, explicit labels, no silent passes when the engine cannot evaluate a construct. Architecture: propose vs prove The classic graph, documented in the README https://github.com/mjha-arya/DOC-foundry/blob/main/README.md?ref=explainx , looks like this in prose: 1. Ingest → extract → telemetry — Threat Analyst normalizes input; Telemetry agent fixes the test set. 2. Blue author — Detection Engineer drafts behavior plus command-line intent, not one brittle string match. 3. Evaluate → battery → red propose → red verify → verdict — Deterministic referee scores FP/FN, runs mutation battery, and only counts Red bypasses the engine confirms. 4. Repair or exit — If verdict is not real-coverage and rounds remain, Blue gets concrete evasions and false positives as evidence. 5. Kartikeya gate → bundle — Governance scores blast radius times capability delta; egress needs a human. Four LLM personas live in src/agents.py : Threat Analyst, Blue Detection Engineer, Telemetry, and Red-Team Adversary. Everything that decides truth — matching, adversarial mutations, coverage labels — sits in engine.py , evaluator.py , and graph.py with same input → same verdict → same hash . What the engine refuses to fake The README's honesty contract matters for builders who have been burned by evaluators that silently ignore hard clauses. engine.py raises on constructs it cannot truly evaluate — CIDR filters, aggregations, invented |in operators — rather than scoring them as covered. An un-evaluable rule costs a broken round, and Blue gets the engine's error text as repair evidence. That is the opposite of vibe-based "LGTM" reviews and closer to how serious teams treat schema validation and default deny https://explainx.ai/blog/cloudflare-modern-security-model-artex-pentest-orchestrators-2026 on APIs. Green probe pressing a crack in a shell, illustrating Red-team evasion testing against Sigma rules The two pipelines: proof vs stakeholder review DOC-foundry runs two workflows with the same cast but different deliverables. Confusing them would mislead your SOC. Classic proof loop default for python src/run.py Outputs land in Outputs/