Meet Armor Detect: Detection Engineering Agent by Arambh Labs
The Problem
Every security team has seen the heat map. The MITRE ATT&CK matrix, color-coded red and green, hanging in a slide deck as evidence of where the organization stands. It is a useful artifact and, too often, a dead end. Teams know exactly what they should be detecting. The problem is everything that happens after the map is drawn.
Translating coverage gaps into production-ready detections is slow, manual, and dangerously dependent on a handful of senior detection engineers. Even when new rules ship, many teams discover a second, quieter problem: the detections they already have are drowning analysts in noise. And while they're busy fighting both battles, the threat landscape doesn't wait — new exploits and zero-days drop weekly, each one a race between the attacker's playbook and the defender's rule base.
Coverage without quality is a treadmill. Quality without coverage is a blindfold. And both without speed are a history lesson.
Modern detection engineering needs to stand on all pillars at once.
That’s why today we are excited to launch Arambh Labs’ Detection Agent - Armor Detect
Armor Detect
Product Principles
We have designed Armor Detect to stand on 3 product pillars.
The first is coverage — systematically closing the gaps in your ATT&CK map by generating, adapting, and deploying detections instead of just cataloguing what's missing.
The second is quality — continuously tuning the rule base so analysts trust what fires, cutting noise without cutting signal.
The third is speed — turning zero-days, new exploits, and fresh campaign intelligence from your threat intel tools into deployed detections while the window between disclosure and exploitation is still open.
Coverage answers "can we detect what's known?" Quality answers "can we trust what we detect?" Speed answers "can we detect what's coming — and did it already
Pillar One: Increase Detection Coverage
The traditional workflow for closing a coverage gap looks something like this: a detection engineer picks a technique, researches how adversaries execute it, studies the organization's log sources, writes a rule, tests it in a lab that only loosely resembles production, and deploys it hoping for the best. Multiply that by dozens of missing techniques and sub-techniques, and you understand why coverage maps stay red for quarters at a time.
Armor Detect starts in the same place, your ATT&CK coverage map, but treats it as an input to an automated pipeline rather than a to-do list for humans.
From gap to generated rule. Once you have identified the techniques and sub-techniques where coverage is missing, Armor Detect generates detection logic automatically. Critically, this doesn’t stop at single-event rules. Real attacks unfold as sequences, and the most valuable detections are correlated ones: a suspicious process spawn followed by an unusual network connection followed by credential access. Generating correlation logic, not just atomic signatures, is what makes Armor Detect valuable for real world environment.
Adapted to the environment, not copied from a repository. Generic rules fail in specific environments. A detection is only production-ready when it reflects the customer's actual data sources, log formats, field names, environmental quirks, and, importantly, the detections that already exist. Armor Detect automatically adjus the rules to customer’s environment while running logs exploration at the same time.
Proven before it ships. This is the step most teams skip, and it is the one that matters most. Before a detection touches production, Armor Detect backtest it against historical logs. Would it actually have fired on the telemetry this environment generates? Would it have caught the behavior it claims to catch, at a false-positive rate an analyst can live with? Backtesting turns "we think this works" into "we measured that this works."
Deployed, versioned, and watched. From there, detections deploy directly into production with full version control: every rule change tracked, reviewable, and reversible, the same way software teams treat code. And deployment is not the finish line. Detection performance and effectiveness get monitored continuously, because environments drift, log sources change, and a rule that worked in March can silently rot by August.
The principle underneath Armor Detect: do not just tell security teams what they are missing. Generate the detection, prove it against their data, and deploy it.
Pillar Two: Improve Detection Quality
Here is the uncomfortable truth about coverage: it is useless if the detections generate noise. A SOC receiving ten thousand alerts a day does not have more visibility than one receiving five hundred. It has less, because the real signal is buried under alert fatigue, and analysts learn to distrust the very tools meant to protect them.
Quality is where detection programs go to die, mostly because it is treated as an afterthought. It should be the second pillar, given equal weight to coverage.
Find the noise. Armor Detect starts by analyzing the existing rule base to identify which detections are noisy: the rules responsible for the bulk of alert volume with little or no true-positive yield. In most environments, a small fraction of rules produce a large majority of the noise, which means targeted tuning delivers outsized returns.
Learn what normal looks like. Effective tuning is not guesswork; it is grounded in the organization's actual behavior. By learning normal patterns from observed telemetry, which service accounts run which scripts, which admin tools appear on which hosts, what "typical" looks like at 2 a.m. versus 2 p.m., Armor Detect tuning recommendations is precise and adapted to customer’s environment
Tune without going blind. This is the tightrope. The lazy fix for a noisy rule is broad suppression, and broad suppression is how attacks slip through detections that technically "exist." This is what Armor Detect differentiates. The goal is to reduce false positives without blindly suppressing signal: better thresholds, sharper filters, smarter conditions. And where individual signals are too weak to alert on alone, it correlates multiple weak signals into a single correlated detection instead of discarding them.
Prune the overlap. Different engineers, different eras, different naming conventions, and the result is duplicate and overlapping rules that fire on the same behavior, doubling alert volume for zero added coverage. Armor Detect identify and consolidate them
Backtest every change, and measure the delta. We believe no tuning change should ship on intuition. Every modification gets backtested against historical data, with a rigorous before-and-after comparison across the metrics that actually matter: alert volume, true-positive rate, detection coverage, missed attacks, and mean time to investigate.
The principle here: detection engineering should not be a one-time rule-writing exercise. It should be a continuous optimization loop.
Pillar Three: Respond to Emerging Threats
The first two pillars deal with what's already known: the ATT&CK techniques on the map and the rules already in production. The third pillar deals with what dropped this morning.
A zero-day gets disclosed. A new exploit for a widely deployed product hits the wild. A threat intel report lands describing a fresh campaign, complete with TTPs nobody had catalogued last month. In most organizations, what follows is depressingly familiar: the advisory circulates in Slack, someone opens a ticket, a detection engineer gets to it when the queue allows — and the window between public disclosure and mass exploitation, which now often closes in hours rather than weeks, slams shut with nothing deployed.
Threat intelligence tools already deliver the raw material. The failure is in the last mile: intel that ends as a PDF instead of a production detection.
Ingest intel as a trigger, not a newsletter. New exploits, zero-day disclosures, vulnerability advisories, and campaign reports from threat intel feeds automatically kick off the same pipeline that Pillar One built — treated as detection requirements, not reading material.
Extract behaviors, not just indicators. IOC matching — hashes, IPs, domains — is the floor, and attackers rotate past it in hours. The valuable extraction is behavioral: what does exploitation of this vulnerability actually look like in telemetry? Which processes spawn, which paths get touched, which network patterns emerge? Armor Detect extracts these nuanced behavior and not just IOCs
Check relevance before you burn a cycle. Not every zero-day matters to every environment. Armor Detect cross-references intel against the environment's real asset and telemetry to ensure it is focusing on right threats for your environment
Generate, adapt, backtest — same discipline, compressed timeline. From there, the emerging-threat rule travels the same road as any other detection: generated automatically, adapted to the environment's data sources and field names, and backtested before deployment.
Retire intel-driven rules deliberately. Threat-intel detections age fast. Campaign infrastructure gets abandoned, exploits get patched out of relevance, and stale IOC rules quietly pile up as noise — feeding the exact problem Pillar Two exists to fight. Armor Detect create expiry review expiry for Emerging-threat rules from the day they ship.
The principle: when a new exploit drops, the race is between the attacker's weaponization and your detection pipeline. Intel should end as a deployed rule and a retro-hunt — not a bookmarked advisory.
Three pillars, one loop
Coverage, quality, and speed aren't sequential phases — they feed each other. Expanding coverage generates new rules that need quality monitoring from day one. Quality analysis reveals coverage gaps disguised as noise, where a badly written rule was masking a technique that was never really detected at all. Emerging-threat detections enter the rule base at speed and immediately inherit both disciplines: proven by the same backtesting, tuned by the same quality loop, retired by the same lifecycle management. And every new campaign that threat intel surfaces redraws a corner of the coverage map, sending the loop around again.
Armor Detect is designed to help with coverage, quality and speed at the same time.
See Armor Detect close coverage gaps and tune noisy rules against your own logs. Book a demo, or read how to evaluate an AI SOC platform if you are earlier in the process.
Frequently asked questions
What is detection engineering?
Detection engineering is the practice of turning knowledge of attacker techniques into rules that reliably fire in a specific environment at an acceptable noise level. It covers two jobs: increasing coverage by writing detections for techniques you cannot yet see, and improving quality by tuning, correlating, and pruning the ones you already have. Done well, it is a continuous loop, not a one-time exercise.
How does automated detection engineering work?
It treats the ATT&CK coverage map as an input to a pipeline rather than a to-do list. Gaps are identified, detection logic is generated (correlated rules, not just single-event signatures), adapted to the environment's real log sources and field names, backtested against historical logs, deployed under version control, and monitored continuously. Forge runs this loop end to end.
Why do MITRE ATT&CK coverage gaps stay open for so long?
Because closing each one is manual work bottlenecked on senior detection engineers: researching the technique, studying log sources, writing the rule, testing it in a lab that only loosely resembles production. Across dozens of techniques and sub-techniques, that keeps heat maps red for quarters. Automating generation, adaptation, and backtesting removes the bottleneck.
What is detection backtesting and why does it matter?
Backtesting runs a new or modified detection against historical logs to see whether it would have fired, what it would have caught, and at what false-positive rate. It is the step most teams skip and the one that matters most, because it catches regressions before production: a change that cuts alert volume but would have missed last quarter's real attack is not tuning, it is a blind spot.
How do you reduce false positives without missing real attacks?
Avoid broad suppression, which is how attacks slip through detections that technically exist. Instead, learn what normal looks like from your own telemetry, tighten thresholds and conditions precisely, correlate weak signals into higher-confidence detections, consolidate duplicate rules, and backtest every change, measuring the delta across volume, true-positive rate, coverage, and missed attacks.